12 ms·

Can a language that uses GC (presumably, it says no manual memory management) be used to program an OS? Just wondering... I think the home page is not very info

Can a language that uses GC (presumably, it says no manual memory management) be used to program an OS? Just wondering... I think the home page is not very informative as it doesn't really tell me what features are there in this language, but just what it hopes to be. And tbh, from my experience using vim script, knowing its author may scare me away from this...

Jach 4y ago
Sure, the heritage of Lisp Machines shows that well enough. Or a modern version: https://github.com/froggey/Mezzano https://github.com/froggey/Mezzano Not all GCs are equivalent, though.
- RcouF1uZ4gsC 4y ago
  > Sure, the heritage of Lisp Machines shows that well enough. Yes it does. You can use GC for an OS but you end with slow, expensive, and very niche machines.
  - Jtsummers 4y ago
    Project Oberon and its descendants would be a counterpoint to this assertion. GC'd systems language + OS can be made to work effectively and without requiring anything special.
  - retrac 4y ago
    Lisp machines weren't slow. The initial CADR machines around 1980 could run simple integer and maths code around as fast as the VAX/780, a very fast minicomputer costing ~$50,000 (processor only!) that was released around the same time. And yet Lisp machines were slow. I chalk that up to a proto-Common Lisp system, with 1970s compilation techniques, being just too much. Millions of lines of code of a fully dynamic software environment with a GUI debugger that let you step into any part of the system including the OS and lowest runtime layers and edit it live -- crammed into a couple megabytes and a couple MIPS. Of course it was slow.
- samatman 4y ago
  Doing low-level programming in a Lisp is much like doing so with Cython or RPython: you're using effectively a different language with familiar syntax. Not that there's anything wrong with that! And a case could be made that much of the power in Lisp comes from the ease of turning it into, effectively, a different language. But it's less "all the power of a high-level GC language and the ability to write low-level systems code" and more "all the power of a high-level GC language or the ability to write low-level systems code".
  - Jach 4y ago
    You're maybe right with a generic idea of Lisp that includes all of Clojure and most Schemes and random GitHub "lisps", but I think Common Lisp (and its immediate predecessors) really does give you that and. "Going faster" or just lower doesn't really require anything like the contortions and sacrifices that something like moving from Python to Cython/RPython does. (As an aside, I recently came across and was amused by the existence of https://pypi.org/project/PeachPy/ https://pypi.org/project/PeachPy/) To take an example from the Lisp machines, here's the method (in the full OOP sense) for receiving UDP packets: https://twitter.com/RainerJoswig/status/1215728406823886854 https://twitter.com/RainerJoswig/status/1215728406823886854 High level code, which you can jump to while the system is running, edit, debug, recompile, but for a fairly low level networking task. With modern SBCL, you get some nice compiled assembly from your code out of the box but you can output your own custom assembly if you want yet still not lose out on interactivity and recoverable errors (way beyond typical exception handling). You also never lose macros, so things like ugly-ish repetitive magic-number-seeming (technically from a datasheet) code poking at bits in status registers can be nicely abstracted. The topic of just GC and precisely managing memory when you need to is more involved, and I'll admit that certain strategies are little different from a C++ style (i.e. allocate a bunch of memory ahead of time and re-use it, rather than calling slow delete/letting the GC work to reclaim it), but even if Lisp isn't where the state of the art is (I'd give that to the JVM ecosystem where you have things like ZGC's average 50 microsecond pause times) the ones you have these days are a lot better than those of the 70s (which seems to be where some people think all GCs are still at) and the subset of low-level programming tasks where it really pays off to mess with a lot continues to get smaller...
badsectoracula 4y ago
> Can a language that uses GC (presumably, it says no manual memory management) be used to program an OS? Yes, Project Oberon[0] by Niklaus Wirth and Jürg Gutknecht is written in Oberon-07 which is a very small programming language with a garbage collector. The garbage collector is even written in Oberon-07. [0] http://www.projectoberon.com/ http://www.projectoberon.com/
- kaba0 4y ago
  There is also Microsoft’s Singularity OS.
retrac 4y ago
Yes. One approach is to use a language that allows both GC and manually managed memory, perhaps a small subset of the full language proper. You then write the garbage collector itself and other runtime bits in that language. Another approach is to reduce the GC runtime to as small a blob as possible, and write it in C/assembly. The old LISP machines used both techniques -- there was an assembly language of sorts, that mapped closely to the high-level language, in which the most basic layer of the system like the GC was written.

Jach 4y ago

Sure, the heritage of Lisp Machines shows that well enough. Or a modern version: https://github.com/froggey/Mezzano https://github.com/froggey/Mezzano Not all GCs are equivalent, though.

RcouF1uZ4gsC 4y ago
> Sure, the heritage of Lisp Machines shows that well enough. Yes it does. You can use GC for an OS but you end with slow, expensive, and very niche machines.
- Jtsummers 4y ago
  Project Oberon and its descendants would be a counterpoint to this assertion. GC'd systems language + OS can be made to work effectively and without requiring anything special.
- retrac 4y ago
  Lisp machines weren't slow. The initial CADR machines around 1980 could run simple integer and maths code around as fast as the VAX/780, a very fast minicomputer costing ~$50,000 (processor only!) that was released around the same time. And yet Lisp machines were slow. I chalk that up to a proto-Common Lisp system, with 1970s compilation techniques, being just too much. Millions of lines of code of a fully dynamic software environment with a GUI debugger that let you step into any part of the system including the OS and lowest runtime layers and edit it live -- crammed into a couple megabytes and a couple MIPS. Of course it was slow.
samatman 4y ago
Doing low-level programming in a Lisp is much like doing so with Cython or RPython: you're using effectively a different language with familiar syntax. Not that there's anything wrong with that! And a case could be made that much of the power in Lisp comes from the ease of turning it into, effectively, a different language. But it's less "all the power of a high-level GC language and the ability to write low-level systems code" and more "all the power of a high-level GC language or the ability to write low-level systems code".
- Jach 4y ago
  You're maybe right with a generic idea of Lisp that includes all of Clojure and most Schemes and random GitHub "lisps", but I think Common Lisp (and its immediate predecessors) really does give you that and. "Going faster" or just lower doesn't really require anything like the contortions and sacrifices that something like moving from Python to Cython/RPython does. (As an aside, I recently came across and was amused by the existence of https://pypi.org/project/PeachPy/ https://pypi.org/project/PeachPy/) To take an example from the Lisp machines, here's the method (in the full OOP sense) for receiving UDP packets: https://twitter.com/RainerJoswig/status/1215728406823886854 https://twitter.com/RainerJoswig/status/1215728406823886854 High level code, which you can jump to while the system is running, edit, debug, recompile, but for a fairly low level networking task. With modern SBCL, you get some nice compiled assembly from your code out of the box but you can output your own custom assembly if you want yet still not lose out on interactivity and recoverable errors (way beyond typical exception handling). You also never lose macros, so things like ugly-ish repetitive magic-number-seeming (technically from a datasheet) code poking at bits in status registers can be nicely abstracted. The topic of just GC and precisely managing memory when you need to is more involved, and I'll admit that certain strategies are little different from a C++ style (i.e. allocate a bunch of memory ahead of time and re-use it, rather than calling slow delete/letting the GC work to reclaim it), but even if Lisp isn't where the state of the art is (I'd give that to the JVM ecosystem where you have things like ZGC's average 50 microsecond pause times) the ones you have these days are a lot better than those of the 70s (which seems to be where some people think all GCs are still at) and the subset of low-level programming tasks where it really pays off to mess with a lot continues to get smaller...

badsectoracula 4y ago

> Can a language that uses GC (presumably, it says no manual memory management) be used to program an OS? Yes, Project Oberon[0] by Niklaus Wirth and Jürg Gutknecht is written in Oberon-07 which is a very small programming language with a garbage collector. The garbage collector is even written in Oberon-07. [0] http://www.projectoberon.com/ http://www.projectoberon.com/

kaba0 4y ago
There is also Microsoft’s Singularity OS.

retrac 4y ago

Yes. One approach is to use a language that allows both GC and manually managed memory, perhaps a small subset of the full language proper. You then write the garbage collector itself and other runtime bits in that language. Another approach is to reduce the GC runtime to as small a blob as possible, and write it in C/assembly. The old LISP machines used both techniques -- there was an assembly language of sorts, that mapped closely to the high-level language, in which the most basic layer of the system like the GC was written.