Not wrong. Kernels usually have their own memory management schemes, tied to the lifetime of i/o ops and so on. It would make more sense to somehow integrate that into the driver programing language.

It makes some things easier, and some things harder, or more complex.

So I can deny that most development becomes easier with GC. At least if you also intend to actually run the thing. Running Java means forever fighting the GC, needing to do runtime and development to reduce impact of inherent GC problems.

But it's a Java issue: Java relies on Heap Objects way too much. C# and the CLR behind it has a much better support for value types and stack allocations, where some optimization can even be done by the JIT compiler.

While I don't have much experience with C#, and I agree that Java is the worst, this at least applies to Go as well. Though to a lesser degree.

You are right that I was talking about delivering a first working version, not about tuning performance. It could be argued that optimizing for memory (de)allocation so early in the development is a case of premature optimization. Sadly, I don't know a (good) path from gc-based development to safe manual memory management, so I'll keep that counter-argument for the day I see one such path :)

Yeah, the problem with that kind of thing is that GC languages disincentivizes thinking about ownerships, and tacking ownership on after the fact is basically a rewrite.

Now that Haskell has linear types, perhaps we'll see some new ideas emerge?

I wrote a bit about this. After years of having move semantics and borrow checking I don't really agree. I find that GCs are way way harder to reason about. They make it very hard to know when I'm sharing something or not, when something can be mutated, when it will be copied, etc. And then I still have to clean up other resources with a whole other, separate system.

At the end of the day I find languages like Java much harder to reason about and actually a bit harder to write.

https://insanitybit.github.io/2023/06/09/Java-GC-Rust

You're not wrong, but I believe that we're talking of different properties.

Move semantics and borrow checker shine when you don't want your data structure to be shared and when you want to control mutation. In some domains, that brings you an unequaled level of safety and Rust is the obvious choice.

Move semantics and borrow checker slow you down when you sharing and mutation are properties you don't care about (or at least not enough to prove them to the compiler). In such cases, I'd rather code in OCaml (or Haskell, or TypeScript, ...)

I hope that one day we'll be able to have the best of both worlds, but I don't see a path forward at the moment.

Xerox PARC and ETHZ workstations were fully written in GC enabled languages, including the device drivers.

Smalltalk, Interlip-D, Mesa/Cedar, Oberon, Oberon-2, Active Oberon

Source code is available for some of them, many home made OSes in non GC enabled languages are far from meeting the capabilities of any of those systems.

"Eric Bier Demonstrates Cedar" - Computer History Museum

https://www.youtube.com/watch?v=z_dt7NG38V4

https://people.inf.ethz.ch/wirth/ProjectOberon/Sources/Kerne...

Very interesting, thanks!

Do these include subsystems with fairly high-performance requirements (GUIs, high-volume network services, etc.)?

In what concerns Xerox PARC, enough stuff on Bitsavers, about how everything run on top of those graphical workstations, in a distributed computing environment.

Likewise ETHZ IT department during the late 1990's used several Oberon workstations.

Thanks!

Don't those systems have substantially less capabilities? In particular, swap/paging, virtual memory, multi-processor support, and low-ish latency?

GC is easy if you don't have to worry about those problems.

The Xerox systems were more modern and demanding than UNIX, for their time.

For their time, sure.

But that doesn't help with today's devices. Even $10 boards are multicore now and come with hundreds megs of RAM.

At least in garbage collected OS design, the lessons from 1970's and 1980's are interesting, but do not directly apply to modern systems.