What does HackerNews think of Mezzano?

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.

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

Alternatively a complete OS (not based on SBCL):

https://github.com/froggey/Mezzano

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.)

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

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.

[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/

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

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

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

https://github.com/froggey/Mezzano

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

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

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

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

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...

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

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

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

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/

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:

https://github.com/froggey/Mezzano

https://github.com/robert-strandh/McCLIM