[arximboldi]

I really want to like Carp but I somehow feel that the Rusty memory model does not fit the Lisp philosophy... all the borrowing story comes from a basis mutability.

I wish for something more Clojurish based on immutable data. Then one can exploit the power of inferred type linearity/affinity to transparently build safe "transients" and other cool stuff. Maybe some day I should write such Lisp myself on top of my C++ immutable data structures [1] :-)

[1] https://github.com/arximboldi/immer

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

[hoosieree]

Your point is solid for most architectures. On embedded systems however, you nearly always need some sort of lifetime/ownership model. If using an RTOS, you have to play by its API rules. If bare-metal C/C++, you have to code it from scratch. But it's always there.

Compiler support for this pattern is a huge plus in my book.

[kmill]

> does not fit the Lisp philosophy... all the borrowing story comes from a basis mutability

I found this to be a confusing statement until I realized you were talking about Clojure. Common Lisp condones mutation, and a borrowing model could be helpful for optimizing memory allocations.

[arximboldi]

You are right that a lot of Lisps consider themselves more procedural than functional and I was extrapolating Clojure there. (In my defense, the Scheme community is also very functional and immutable oriented)

[masukomi]

errr.... no. every scheme i've touched / seen is perfectly happy to mutate your variables. what one doesn't?

[kmill]

"Scheme community" probably meant "Racket", but I don't know much about schemers these days to know for sure.

[hashkb]

I use set! whenever I feel the urge.

[zitterbewegung]

That’s one of its strengths though . A lisp with type inference and performance is quite rare. More lisps should be less lispy .

[shakna]

> A lisp with type inference and performance is quite rare.

You mean apart from several Scheme implementations?

Chez Scheme is blisteringly fast, and on-par with C for quite a few things.

Gambit-C (Compiles to C), Chicken (based on the Cheney-on-the-MTA model) and Bigloo (designed to replace C++) also deserve a reference here.

[metaobject]

Bigloo has a special place in my heart. I spent a few years building scheme bindings to various C graphics and networking libraries. I can't quite put my finger on it, but I found it very enjoyable. Getting C-like performance from scheme is just wonderful.

[baldfat]

Racket which is moving to a Chez Scheme top and you can further go with typed Racket seems to fit that 'rare' category.

[white-flame]

> A lisp with type inference and performance is quite rare.

That's quite a befuddling thing to say, in every aspect.

The popular SBCL is likely the fastest general Lisp out there (gets close to or equal to C when declared properly), and type inference is certainly part of those speed wins.