[nickpsecurity]

One of the good LISP's back in the day was PreScheme that let it finally be a C alternative efficiency-wise. It was also used in first, verified LISP. Such a style might also be good for bootstrapping or just making more flexible ways to code C.

https://en.m.wikipedia.org/wiki/PreScheme

Looking at PreScheme, Carp doing a C alternative safe without a GC is a nice evolution of these LISP's. Next cool possibility: use a Rust-like LISP with an OS project like Mezzano on lowest-level stuff. Might even start with Redox OS just LISPifying its parts for a kernel and shell to start with.

[progman]

> Next cool possibility: use a Rust-like LISP

Why do you want a Rust with Lisp syntax? I don't see the benefits of such a "Lisp" if you take the core benefits of metaprogramming at runtime away which depends on the equality of code and data.

Safe software can also be written in other languages than Rust. Ada is still industry standard of safe programming today. Even Lisp can be used to write safe software since Lisp's memory management takes care of possible pointer problems.

Rust shines in the field where Mozilla developed it for -- safe Internet browsers. However, safe Internet browsers could also be written in Ada and Lisp. The Lisp version would just not be as performant as Ada's and Rust's.

[kazinator]

> The Lisp version would just not be as performant as Ada's and Rust's.

What makes browsers perform badly is the execution of all that Javascript.

In Lisp, we can scan Javascript and go to machine code with far less work than doing the same thing in Ada.

The Ada browser might beat the Lisp one on the raw rendering of a big HTML-only page.

[nickpsecurity]

"Rust-like LISP"

The phrase was ambiguous. I meant a LISP w/ safe, memory model like Carp. There's already LISP's in the past and present for OS's. There's also projects that restrict the power of languages to get better efficiency in low-level work. So, more of the latter with Rust's memory model might be advantageous. The former with their flexibility could be built on top of that same language with a low-latency GC for anything done dynamically or which the analyzer just couldn't handle enough to know safety. Might lead to a great performance boost on top of safety benefits.

"Safe software can also be written in other languages than Rust. Ada is still industry standard of safe programming today."

You're right that Ada was a language systematically designed for safety that people could be using right now. I gave them some resources on that here:

https://news.ycombinator.com/item?id=15771552

The problem: Ada does not have temporal safety or flexible support for race-free concurrency. The first part in Ada doesn't exist at all: they have to do unsafe deallocation when their tricks like memory pools aren't enough. The second, Ravenscar, is like a tome in its restrictions compared to the basic rules of the borrow-checker in Rust. Rust smashes Ada so hard on "safety without GC concept" that I told Yannick McCoy at AdaCore to get someone on achieving parity pronto. For SPARK if nothing else since it would have provably-safe sequential procedures whose composition was also safe w/ Rust's method. That would be awesome for projects such as IRONSIDES DNS.

"Rust shines in the field where Mozilla developed it for -- safe Internet browsers."

Rust shines anywhere you want safe, systems code without a GC and with concurrency. That's it's main selling point, not language design. There's tons of applications for that as the huge ecosystem is showing us replacing all sorts of components in other languages with safe, fast alternatives. Redox OS did an OS in it. In high-assurance sector, Robigalia was wrapping seL4 so one can have safe apps in Rust on a formally-verified, separation kernel. bluejekyll upthread wrote a DNS server (TrustDNS) in it. Rust can do about anything an analyzable subset of C can do.

"The Lisp version would just not be as performant as Ada's and Rust's."

This is correct. My recommendation to use one close to the metal like PreScheme with Rust-style safety that outputs C for LLVM attempts to address that. All the macros apply until the resulting code is straight-forward. The translation should be straight-forward to C where LLVM does the heavy lifting. One might also use techniques from projects such as Chicken Scheme, a whole-program optimizer, and/or a super-optimizer. The speed differences might be so minimal that nobody even cares. They already are for several LISP's on most applications but I'm talking system code.

[progman]

> My recommendation to use one close to the metal like PreScheme with Rust-style safety that outputs C for LLVM attempts to address that.

Wouldn't it be easier to develop a very basic OS core in Rust, and a simple Lisp 1.5 interpreter written in Rust as foundation for a full blown Lisp?

[pjmlp]

No, because PreScheme is still a Lisp like language, whereas Rust would be bringing something else into the table as well.