4 ms·

If a "systems" program can afford GC, then I would consider it mischaracterized. The whole premise of "systems" programming IMO is that you need the code to beh

If a "systems" program can afford GC, then I would consider it mischaracterized. The whole premise of "systems" programming IMO is that you need the code to behave exactly in the way specified, without unexpected preemption (i.e., preemption can only occur at controlled locations and/or for controlled durations). I think a lot of "embedded" software really isn't "systems" software, though the two get conflated a lot. Note that GC cannot possibly promise "time-boxed pauses" in the general case; either allocations are allowed to outpace collections, in which case a longer collection pause will eventually be required to avoid memory exhaustion, or else allocations must be throttled, which just pushes an unbounded pause forward to allocation time.

pjmlp 2y ago
Xerox PARC, ETHZ, DEC Olivetti, Microsoft Research, Genera, and even Bell Labs had another understanding of systems programming.
- kbolino 2y ago
  Do tell
  - pjmlp 2y ago
    Xerox PARC => Smalltalk, Mesa/Cedar, Interlisp-D ETHZ => Oberon, Oberon-2, Active Oberon, Component Pascal (via Oberon Systems, a startup spinoff out of ETHZ), Oberon-07. DEC Olivetti => Modula-2+, Modula-3 Microsoft Research => Singularity, Midori Genera and TI => Lisp Machines Bell Labs => C@+ (really confusing name, one of the few sources are a couple of DDJ articles), Limbo
    - kbolino 2y ago
      I am quite ignorant about how these systems actually worked. I have heard of Lisp Machines before; the Alto and Lilith seem similar in that they're purpose-built hardware focused on running particular languages (or families of languages). The others are kind of hard to find relevant information about. My cursory understanding of these environments is that the hardware did a lot "more" than modern micros and so the system software could enjoy many luxuries that a typical modern operating system has to build for itself. They also didn't work well with languages they weren't designed for.
      - pjmlp 2y ago
        Doesn't change the fact that they were full stack OS experiences written in those languages, covering most scenarios that everyone keeps claiming only C can do. The way they ended up not gaining traction had more to do with management decisions, company acquisitions and hardware costs, than the technology stacks themselves. The "C" for systems programming isn't only pure C as defined by K&R C, or ANSI/ISO C, rather C + Assembly, or compiler specific extensions for inline Assembly, pragmas, intrinsics, and keywords not part of any standard. D and C# are two modern examples of GC based languages with similar capabilities in intrinsics.
        kbolino 2y ago
        I think with modern hardware you could significantly reduce the amount of C code but I'm not sure you could eliminate it entirely. Rust is trying to do just that but IMO isn't really comparable to the languages you mentioned. Maybe if microkernels had taken off and/or hardware drivers were written with more abstract interfaces, things might have been different even on the much cheaper hardware that won out.
        pjmlp 2y ago
        There are plenty of OS written in C++, already that is an improvement over bare bones C. For example, Meadow uses a C++ mikrokernel, with everything else written in C#. https://www.wildernesslabs.co/ https://www.wildernesslabs.co/
        kbolino 2y ago
        I'd be surprised if they can use all of C++'s advantages in a freestanding environment. Even Rust struggles there though at least it's a first-class option.
        yencabulator 2y ago
        > significantly reduce the amount of C code but I'm not sure you could eliminate it entirely Theseus is a research OS written in Rust that seems to include C purely to show how to support programs written in C (libc and a demo app). https://github.com/theseus-os/Theseus https://github.com/theseus-os/Theseus It contains some 1000+ lines of ASM for the early boot from BIOS, that look like they originate from https://os.phil-opp.com/minimal-rust-kernel/ https://os.phil-opp.com/minimal-rust-kernel/ -- I think UEFI boot would have been doable in pure Rust (https://github.com/rust-osdev/uefi-rs https://github.com/rust-osdev/uefi-rs).

pjmlp 2y ago

Xerox PARC, ETHZ, DEC Olivetti, Microsoft Research, Genera, and even Bell Labs had another understanding of systems programming.

kbolino 2y ago
Do tell
- pjmlp 2y ago
  Xerox PARC => Smalltalk, Mesa/Cedar, Interlisp-D ETHZ => Oberon, Oberon-2, Active Oberon, Component Pascal (via Oberon Systems, a startup spinoff out of ETHZ), Oberon-07. DEC Olivetti => Modula-2+, Modula-3 Microsoft Research => Singularity, Midori Genera and TI => Lisp Machines Bell Labs => C@+ (really confusing name, one of the few sources are a couple of DDJ articles), Limbo
  - kbolino 2y ago
    I am quite ignorant about how these systems actually worked. I have heard of Lisp Machines before; the Alto and Lilith seem similar in that they're purpose-built hardware focused on running particular languages (or families of languages). The others are kind of hard to find relevant information about. My cursory understanding of these environments is that the hardware did a lot "more" than modern micros and so the system software could enjoy many luxuries that a typical modern operating system has to build for itself. They also didn't work well with languages they weren't designed for.
    - pjmlp 2y ago
      Doesn't change the fact that they were full stack OS experiences written in those languages, covering most scenarios that everyone keeps claiming only C can do. The way they ended up not gaining traction had more to do with management decisions, company acquisitions and hardware costs, than the technology stacks themselves. The "C" for systems programming isn't only pure C as defined by K&R C, or ANSI/ISO C, rather C + Assembly, or compiler specific extensions for inline Assembly, pragmas, intrinsics, and keywords not part of any standard. D and C# are two modern examples of GC based languages with similar capabilities in intrinsics.
      - kbolino 2y ago
        I think with modern hardware you could significantly reduce the amount of C code but I'm not sure you could eliminate it entirely. Rust is trying to do just that but IMO isn't really comparable to the languages you mentioned. Maybe if microkernels had taken off and/or hardware drivers were written with more abstract interfaces, things might have been different even on the much cheaper hardware that won out.
        pjmlp 2y ago
        There are plenty of OS written in C++, already that is an improvement over bare bones C. For example, Meadow uses a C++ mikrokernel, with everything else written in C#. https://www.wildernesslabs.co/ https://www.wildernesslabs.co/
        kbolino 2y ago
        I'd be surprised if they can use all of C++'s advantages in a freestanding environment. Even Rust struggles there though at least it's a first-class option.
        yencabulator 2y ago
        > significantly reduce the amount of C code but I'm not sure you could eliminate it entirely Theseus is a research OS written in Rust that seems to include C purely to show how to support programs written in C (libc and a demo app). https://github.com/theseus-os/Theseus https://github.com/theseus-os/Theseus It contains some 1000+ lines of ASM for the early boot from BIOS, that look like they originate from https://os.phil-opp.com/minimal-rust-kernel/ https://os.phil-opp.com/minimal-rust-kernel/ -- I think UEFI boot would have been doable in pure Rust (https://github.com/rust-osdev/uefi-rs https://github.com/rust-osdev/uefi-rs).