Yes, the world would be a better place if young minds all stopped dreaming and accepted the wisdom of the elders. There's nothing left to explore. </sarcasm>
I'm getting older now (40), and let me tell you one thing:
It's really saddening to look at all the wasted effort made to solve the same problems, over and over again.
Mainframes were shit (in most contexts), but have been reinvented and reinvented again and again. The browser is the new 3270 terminal, but are getting more and more capabilities, becoming the new PC. Most it-departments are enforcing rules and practices of the mainframes - the same rules that caused the PC revolution, ie you are not allowed to manage your own computer, and run your own programs.
RPC and IPC has been reinvented and reinvented again and again, but no real progress. The few things learned along the way have been lost. (Abstract syntax notation, separating message definition and encoding for one.)
So we get this new protocols that does not (or did not) use a message definition language, because parsing text is "easy."
We run all protocols on top of HTTP because it was impossible to get the firewall guys to open up the firewall.
Now the firewall guys have caught up and can close down specific http applications, so we are back at square one but with shitty protocols instead.
There is STILL no (real) language with intrinsic relational support, ie two-way-relations as a first class language feature, instead we are mucking around with (one way) arrays and maps (using monads though!), but in another cooler language.
(I happen to believe that an entity-relation model typically is a reasonable representation of the real world and the abstract concepts in it.)
Javascript and PHP. Nothing learned at all. 50 years of computer science down the drain.
Functional programming: well lisp and scheme are not exactly new, and to be honest, clojure is not that much of an improvement over scheme. Everyone should know a bit of scheme or clojure though.
The only thing that's getting better and better at quite some velocity is the hardware.
Possibly also the "agile" movement, since it's effectively about claiming back the control to the ones that know how to build stuff from the checkbox-guys and process-followers.
Boy, are you a pessimist! That's not at all the message. The message is about working towards progress rather than jumping from one fad to the next with blind faith that something will "save" us. It's a call for technological progress rather than an alchemist's semi-religious search for a way to turn lead into gold.
My first reaction after reading the paper was similar to yours. That I had fallen for the OOP hype train. Later when my boss cited it as an excuse to iterate our aging platform instead of attempting a redesign, my view of it began to change.
It's true many technologies have been overhyped, but it's far too early to throw in the towel. A little over optimistic youth fueled zeal, has let to some of our greatest advances. I think Bret Victor sums my views up best here:
Great talk. Alan Kay and others have said similar things.
We've squandered all the gains the hardware people have made on slower, more bloated software, resulting in computers whose response times are no faster - and sometimes actually slower - than their equivalents were 30 years ago.
And I don't see much youth fuelled zeal going into solving the problem, or even coming out with much in the way of innovation which might help. Instead, people are excited about "new" languages like Golang and Rust (which doesn't even have a garbage collector!), and rebranded copies of BSD and Linux.
People are incredulous when I tell them that while the trailing edge - people entering COBOL into IBM mainframes on punched cards - has advanced considerably, the leading edge has regressed. As Philip Greenspun put it: " These days, most former Lisp programmers are stuck using Unix and Microsoft programming environments and, not only do they have to put up with these inferior environments, but they're saddled with the mournful knowledge that these environments are inferior."
> Rust (which doesn't even have a garbage collector!)
I think you need to take an actual look at Rust if you think that the lack of garbage collection is somehow a design flaw. :P You're free to deride the language as "just" an improvement on the state of the art of systems programming instead of attacking the fundamental underlying problem (which is that the underlying systems themselves are tremendous clusterfucks), but not only is that outside of the domain of a programming language, it is also the case that merely ignoring the status quo out of personal dissatisfaction does not succeed in moving the world forward.
"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." -- George Bernard Shaw
AIUI Rust grew out of a dissatisfaction with C++, and it does have a few good features, such as type inference. But since Java was released, it's been unthinkable for a high level language to require programmers to do their own memory management. If Rust is aimed solely at systems programming, to be used the way Algol 60 was used to implement MCP, PL/1 Multics, C Unix, and Oberon Oberon, then the lack of a garbage collection is understandable. But you can never guarantee your product will be used as intended: I've encountered people who think C is an acceptable choice for everything.
I'm not merely dissatisfied with the current status quo: I'm actively doing something about it. IMO we're doing practically everything wrong, from hardware upwards. Fixing it requires systems very different from those in widespread use today.
As you say, Rust is aimed at being a C++ replacement mainly for systems programming, and having a garbage collector is a hinderance there. Sure people will use it for not-strictly-systems-programming things, but that's on their head: they evaluate the trade-offs (e.g. if they can do without a GC) and choose Rust. Compromising the core goal (memory safety without garbage collection) by including a pervasive GC just because some people might make a slightly silly choice and use Rust where some other tools is better is just wrong. It would make Rust inappropriate for the places where there is essentially no other choice like it, putting in into a class with many other alternatives (e.g. Haskell, OCaml, D etc.).
In any case, on one hand you complain about slow, bloated software, and on the other about Rust not having a GC. The unpredictability of a GC being a major component of bloat in a lot of software. Don't get me wrong: it is possible to write sleek software in a managed languages with GCs, but for many tasks this generally requires fighting against the GC, with things like object pools and buffers (basically reimplementing the standard techniques from non-GC'd languages), and, of course, it is definitely possible to write bloated software without one.
Rust is designed to make it easier to write code without a GC, by adopting many of the advantages that garbage collectors/managed languages bring to table (and more, e.g. static protection against iterator invalidation). There's been a lot of people from Ruby, Python, JavaScript (etc.) backgrounds adding lower-level/more-control programming to their toolbox via Rust, something that was too daunting previously. This means that they can write software (or at least, sensitive parts of their code) that doesn't suffer from the overhead/bloat of the managed languages.
Lastly, Rust's memory management is nothing like "manual memory management" in C (or historical C++), I mean, it compiles down to be essentially the same thing at runtime, but what the programmer writes is very different. The combination of lifetimes, destructors and generics mean that it is difficult to do it wrong: memory leaks are rare, and the compiler will tell you about any dangling pointers, etc.
Given that you list "type inference" as the headline feature of Rust, I continue to think that you haven't actually taken a look at the language in the slightest. :P Guaranteed memory safety with neither the bloat of a garbage collector nor managed runtime is nothing to sneeze at, and is something that no other language (no, not Ada, or Oberon, or...) has ever done on an industrial scale (and only Cyclone has attempted it on a non-industrial scale).
I think your boss' reading of No Silver Bullet was mistaken. He probably misread the paper as something that supported his own conservative preconceptions, and probably disregarded everything else the paper says, like, you know, "grow your designers, they are as important as managers", which includes accepting when one of them says "you should consider using this new tools, it will help us because of X, Y and Z".
It's really saddening to look at all the wasted effort made to solve the same problems, over and over again.
Mainframes were shit (in most contexts), but have been reinvented and reinvented again and again. The browser is the new 3270 terminal, but are getting more and more capabilities, becoming the new PC. Most it-departments are enforcing rules and practices of the mainframes - the same rules that caused the PC revolution, ie you are not allowed to manage your own computer, and run your own programs.
RPC and IPC has been reinvented and reinvented again and again, but no real progress. The few things learned along the way have been lost. (Abstract syntax notation, separating message definition and encoding for one.) So we get this new protocols that does not (or did not) use a message definition language, because parsing text is "easy."
We run all protocols on top of HTTP because it was impossible to get the firewall guys to open up the firewall. Now the firewall guys have caught up and can close down specific http applications, so we are back at square one but with shitty protocols instead.
There is STILL no (real) language with intrinsic relational support, ie two-way-relations as a first class language feature, instead we are mucking around with (one way) arrays and maps (using monads though!), but in another cooler language. (I happen to believe that an entity-relation model typically is a reasonable representation of the real world and the abstract concepts in it.)
Javascript and PHP. Nothing learned at all. 50 years of computer science down the drain.
Functional programming: well lisp and scheme are not exactly new, and to be honest, clojure is not that much of an improvement over scheme. Everyone should know a bit of scheme or clojure though.
The only thing that's getting better and better at quite some velocity is the hardware.
Possibly also the "agile" movement, since it's effectively about claiming back the control to the ones that know how to build stuff from the checkbox-guys and process-followers.