4 ms·

I'm not aware that C# has security or reliability advantages over Rust. It may be better integrated into the Microsoft ecosystem but from the point of view of a

I'm not aware that C# has security or reliability advantages over Rust. It may be better integrated into the Microsoft ecosystem but from the point of view of a driver developer who has to support more than one OS, Rust would seem to be a good tradeoff between security, performance, and reliability vs. C/C++.

Yoric 3y ago
I'm a big fan of Rust (and a minor contributor), but one can't deny that a garbage-collector makes most developments much easier. Now, I'm not convinced that a gc makes much sense in driver development, but I could be wrong.
- deleted 3y ago
  [deleted]
- dboreham 3y ago
  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.
- knorker 3y ago
  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.
  - shanoaice 3y ago
    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.
    - knorker 3y ago
      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.
  - Yoric 3y ago
    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 :)
    - knorker 3y ago
      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.
      - Yoric 3y ago
        Now that Haskell has linear types, perhaps we'll see some new ideas emerge?
- insanitybit 3y ago
  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 https://insanitybit.github.io/2023/06/09/Java-GC-Rust
  - Yoric 3y ago
    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.
- pjmlp 3y ago
  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://www.youtube.com/watch?v=z_dt7NG38V4 https://people.inf.ethz.ch/wirth/ProjectOberon/Sources/Kernel.Mod.txt https://people.inf.ethz.ch/wirth/ProjectOberon/Sources/Kerne...
  - theamk 3y ago
    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.
    - pjmlp 3y ago
      The Xerox systems were more modern and demanding than UNIX, for their time.
      - theamk 3y ago
        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.
  - Yoric 3y ago
    Very interesting, thanks! Do these include subsystems with fairly high-performance requirements (GUIs, high-volume network services, etc.)?
    - pjmlp 3y ago
      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.

Yoric 3y ago

I'm a big fan of Rust (and a minor contributor), but one can't deny that a garbage-collector makes most developments much easier. Now, I'm not convinced that a gc makes much sense in driver development, but I could be wrong.

deleted 3y ago
[deleted]
dboreham 3y ago
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.
knorker 3y ago
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.
- shanoaice 3y ago
  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.
  - knorker 3y ago
    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.
- Yoric 3y ago
  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 :)
  - knorker 3y ago
    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.
    - Yoric 3y ago
      Now that Haskell has linear types, perhaps we'll see some new ideas emerge?
insanitybit 3y ago
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 https://insanitybit.github.io/2023/06/09/Java-GC-Rust
- Yoric 3y ago
  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.
pjmlp 3y ago
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://www.youtube.com/watch?v=z_dt7NG38V4 https://people.inf.ethz.ch/wirth/ProjectOberon/Sources/Kernel.Mod.txt https://people.inf.ethz.ch/wirth/ProjectOberon/Sources/Kerne...
- theamk 3y ago
  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.
  - pjmlp 3y ago
    The Xerox systems were more modern and demanding than UNIX, for their time.
    - theamk 3y ago
      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.
- Yoric 3y ago
  Very interesting, thanks! Do these include subsystems with fairly high-performance requirements (GUIs, high-volume network services, etc.)?
  - pjmlp 3y ago
    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.