[DonaldFisk]

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."

And don't get me started on AI.

[kibwen]

  > 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.

[DonaldFisk]

"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.

[dbaupp]

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.

[kibwen]

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).