What does HackerNews think of Mezzano?

An operating system written in Common Lisp

Language: Common Lisp

>> except building compilers and OSes

SBCL is written in Lisp, yes? Except the runtime, which is C + asm.

I've heard people wrote some OSes in the past, like Genera. Or if you prefer recent attempt, try https://github.com/froggey/Mezzano. Never tried it, though.

Also the Common Lisp OS Mezzano[0] runs like that. It runs Doom and Quake by means of lowering C to LLVM-IR which is then lowered to a subset of CL which is then compiled by the trusted native Mezzano compiler.

[0] https://github.com/froggey/Mezzano/

You might want to look at Mezzano which is an operation system written in Common Lisp https://github.com/froggey/Mezzano

I haven’t tried it since moving to M1/ARM, but it is cool.

Given that on a Lisp Machine (or in a Lisp OS like Mezzano https://github.com/froggey/Mezzano ), the language talks natively to low-level devices (Graphics, SCSI, Bus, Ethernet, ... and other peripherals), it is expected that it has to deal with bits, too.
Sure, the heritage of Lisp Machines shows that well enough. Or a modern version: https://github.com/froggey/Mezzano Not all GCs are equivalent, though.
Interlisp/Medley has sort of revived as an application that runs on your computer: https://interlisp.org/

There’s also Mezzano which is a relatively new, from scratch Common Lisp implementation on bare metal: https://github.com/froggey/Mezzano

Finally, if you know where to look, it’s possible to setup a Symbolics VM on Linux, which is somewhat interesting to poke around in (all the manuals available out of the box are pretty interesting to read through.)

Instead of Movitz, go for Mezzano [1], which is much more complete

[1] https://github.com/froggey/Mezzano

> why not design a new Lisp?

Hell no. Here is why:

1. The Common Lisp standard is brilliant. If your new Lisp is designed by anything less than a committee with people like Kent Pitman, Guy Steele, and Richard P. Gabriel, chances are that you will end up with something worse.

2. Common Lisp has one feature that people often forget about, but that is crucial for an operating system - you can rely on the fact that the semantics doesn't change. Lisp programs written in 1960 can usually be run on today's Common Lisp without modification, so there is hope that programs written today will still run properly even in centuries.

3. Common Lisp has the most powerful object system and the most powerful condition handling system. Both these features are invaluable for an operating system. This is actually my main motivation for contributing to this project. I want my programs to communicate via objects, and I want a system-wide mechanism for recovering from errors without crashing or unwinding the stack.

4. By relying on a very good existing language instead of reinventing this wheel, there is a chance that CLOSOS will actually get finished.

> I'm sure with a little bit of effort SBCL could run as a unikernel and provide a good base for the system.

Probably. But to make CLOSOS actually useful, we need an abstraction for having multiple first class global environments. And bolting that on top of SBCL without breaking existing things is about as painful as a full rewrite. The other big point is that SBCL values performance more than safety. But for CLOSOS, safety is crucial.

> Movitz

We intend to borrow some ideas from Movitz. But since we managed to bootstrap Common Lisp directly from Common Lisp, we hope that some things can be done more elegantly. The other project that should be mentioned here is Mezzano (https://github.com/froggey/Mezzano). We even borrow some code from Mezzano and are actively collaborating with its author.

There is at least one bug in the Movitz compiler, It won't correctly compile a simple loop expression, I spent a fair bit of time trying to fix it.

I think it would be fairly easy to make SBCL run as a unikernel.

There is also Mezzano [1], it is a Lisp OS.

[1] https://github.com/froggey/Mezzano

There is Mezzano, a Common Lisp operating system. Currently designed to be run within Virtualbox. https://github.com/froggey/Mezzano
It's far from comprehensive, but here are a handful of operating system projects that have caught my eye:

[1] MezzanoOS, an OS written in Common Lisp (https://github.com/froggey/Mezzano)

[2] SerenityOS, a Unix-like OS (https://github.com/SerenityOS/serenity/). The primary author has a youtube channel (https://www.youtube.com/c/AndreasKling/)

[3] RedoxOS, a microkernel OS written in Rust (https://www.redox-os.org/)

[4] Nebulet, a microkernel based on webassembly (https://github.com/nebulet/nebulet)

[5] It was never released by Microsoft, but Midori OS had some fascinating ideas like software isolated processes, asynchronous message passing and object capabilities. Nice write-up about the project by Joe Duffy here http://joeduffyblog.com/2015/11/03/blogging-about-midori/

> Lisp is a bad language to write an OS in

Beg to differ. Lisp machines were huge, back in the day, and there are still hobbyist projects like https://github.com/froggey/Mezzano

> I believe that no programming language with automatic memory management can be considered "low-level".

That's a view of a whole language and its implementation. Still it may have a range of features which are low level.

Lisp for example has Foreign Function Interfaces (FFI) with low-level interfaces and manual memory management.

Example: http://www.sbcl.org/manual/#Foreign-Function-Interface

Basic Lisp stuff like CAR and CDR were (almost) instructions on a CPU ( https://en.wikipedia.org/wiki/CAR_and_CDR ).

Something like a cons cell (the building block for lists) is basically a two-element vector. Lists were made by chaining them together via a CONS operator, which creates such a two-element vector.

Such a linked list data structure is pretty low-level and the typical mark&sweep GC of the early days is also relatively basic.

There is not much magic to it.

Many other programming languages have much more complex basic data structures (see object-oriented programming in Java with classes and instances, inheritance, interfaces, namespaces, ...). Compared to that the basic linked list in Lisp is primitive.

> I believe that no programming language with automatic memory management can be considered "low-level".

See the standards for Scheme or Common Lisp. There is not a word about automatic memory management in the specifications. Automatic memory management is a feature of an implementation, just like foreign function interfaces. Most implementations have a kind of garbage collector. But most implementations also have manual memory management.

People even write operating systems in Lisp sometimes: https://github.com/froggey/Mezzano

D has a garbage collector, and yet you can use it for operating system development: https://dlang.org/areas-of-d-usage.html#operating_systems

Lisp has a garbage collector, and yet you can use it for operating system development: https://github.com/froggey/Mezzano

Go has a garbage collector, and yet you can use it for operating system development: http://lsub.org/ls/clive.html

Should mention that Mezzano OS satisfies most of these design points and already runs.


Mezzano [1] is written in Common Lisp and can be run on Virtualbox and QEMU.

[1] https://github.com/froggey/Mezzano

Historically it's an operating system written in Lisp, typically running as a Lisp runtime+image on the metal. Itself providing memory management, interrupt handling, process scheduling, network I/O, graphics, keyboard, mouse, windows, applications ... and everything else a typical OS provides.

For a recent attempt see: https://github.com/froggey/Mezzano

There is Mezzano[0], but I am not sure if it has a similar kind of hackability. I believe environments like that are pretty amazing. It is something that is not unique to just lisps either, you see similar features in Smalltalk environments like Pharo[1].

[0]: https://github.com/froggey/Mezzano

[1]: https://pharo.org/

Emacs is a wide family of text editors. GNU Emacs is just one. Originally Emacs was implemented as a set of TECO macros. The second Emacs was then EINE (Eine is not Emacs). EINE was implemented in Lisp Machine Lisp on top of the Lisp Machine OS. One of the next Emacs editors was Multics Emacs, an Emacs implemented in Maclisp for the Multics mainframe computer. Both Maclisp and Lisp Machine Lisp were full-featured Lisp implementations and thus their Emacs was a Lisp-only implementation. From then on zillions of Emacs variants were implemented. This provides a list of Emacs implementations: http://www.finseth.com/emacs.html

GNU Emacs was developed as a text editor. Its implementation language are C and Elisp - not only the VM is coded in C, but there are other parts written in C. See for example: https://github.com/emacs-mirror/emacs/blob/master/src/frame....

Then Elisp is the extension language for writing extensions (like minor or major modes) and applications using a text-editor user interface. These applications are using the programmable editor buffer as their user interface building block.

General enhanced Lisp implementations which run as a standalone operating system, but which are not special purpose for editor implementation and which are not providing an editor-based user interface exist(ed) several: MIT Lisp Machine OS (and derived), Interlisp-D, ... Mezzano ( https://github.com/froggey/Mezzano ).

Since Elisp was an uncomplete and smaller Lisp - and not a systems programming dialect like Lisp Machine Lisp - its code base is mostly like that: no lexical binding, no real multithreading, no really scalable language constructs, ... moving this language forward is a) not easy and b) not really in the core interest (the core task is being a language for editor extensions).

Also it is questionable whether its editor user interface is a good model for a general UI...

Not exactly a Lisp OS - asm and C beneath. Compare to https://github.com/froggey/Mezzano
It already has a kernel, except it uses the host OS's system calls instead of its own drivers. Once you have a runnable OS that runs as a separate Unix process in its own address space, it is actually possible to port it over to bare metal by providing all the modules that the OS would normally provide: memory management, graphics, device management and HAL, keyboard/mouse input.

See https://github.com/froggey/Mezzano for something that can run on bare metal.

For an example of operating system kernel completely written in Lisp, see https://github.com/froggey/Mezzano
It's certainly a tricky endeavor, but not impossible:

- http://www.fltk.org/index.php - https://github.com/froggey/Mezzano

Then again most gui libraries end up including networking, file handling, etc...

Specific domains where clojure might not do so well are probably the same domains where the JVM is impractical, for example embedded or low-level programming, anything where you have to interact heavily with the world outside of the JVM and have a small footprint.

Obviously mobile looks like an area where common lisp has better options(with this announcement that makes two commercial implementations, the other one being mocl: https://wukix.com/mocl).

How about crazy experimental operating systems? https://github.com/froggey/Mezzano

If you want to write native(non-swing) guis LispWorks has that covered, and the open source gtk/qt bindings, while a bit unlispy work very well. Racket has a pretty cool framework too.

There is also the fact that a lot of programmers, rationally, or irrationally, simply dislike the JVM. Pretty much everything I dislike about clojure has more to do with the JVM than the core design itself.

Both lispworks and franz maintain success lists, so you can look at some of these projects if you want to see some areas where lisp has done fine:

http://www.lispworks.com/success-stories/index.html http://franz.com/success/

There is at least one current project - Mezzano -that boots a Common Lisp and some apps on bare metal.

But the Lisp Machines were more than Lisp on hw. They were about the software, the shell, the IDE. Some work was started more than 15 years ago to revive the CLIM API that made this possible and the original authors still work on it now. I'm really glad about this:



It's up on github (name changed to Mezzano because of the conflict with the CMS project):


IRC log discussing building: http://log.irc.tymoon.eu/freenode/lisp?from=2015-01-27T19%3A...