Hacker News Reader

Comment by lisper | Hacker News Reader

> I'm not sure that it would be "pretty easy" to write a DSL that adds the constraints and provides the guarantees that Rust does.

It would be a lot easier than inventing Rust, for two reasons:

1. You don't need to write a parser.

2. The target language for your DSL compiler can be Common Lisp rather than machine language without sacrificing performance.

Those two things make it absolutely certain that however much work it is to re-invent Rust in CL it will be strictly less work than inventing Rust from scratch.

There are other benefits to this approach as well. For example: if, after implementing your DSL you discover that you've made a sub-optimal design decision somewhere along the line, it will be a lot easier to tweak your DSL than it is to tweak Rust.

View on HN

> 1. You don't need to write a parser.

One of the things people really like about Rust is its fantastic error messages. They're very helpful.

But, having decided you "don't need to write a parser" you're in a tough place for your DSL since there are problems where Lisp's parser will just tell your DSL programmers something went wrong here and leave them clueless as to what exactly is wrong in their program. Rust wouldn't have done that, but of course its compiler owns the parser too so it gets to handle all the corner cases correctly.

You can add descriptive error messages when an error happens (like multiple mutable borrows) during macro expansion. Macros are just regular list code, so all runtime features like printing functions are available.

You could even write a FPS using OpenGL where shooting functions, or pieces of suctions removes them from the current compile job (or even deletes them from the source code entirely). In a macro.

I mean, that's nice, Rust's proc macros get to emit descriptive error messages† too, but for that to happen the macro expansion occurred and that means we didn't have a parse error. So you're dodging the problem.

† Or of course, to deliberately not emit descriptive error messages, e.g. whichever-compiles!

> It would be a lot easier than inventing Rust

And yet rust has been invented, and it seems the CL version is hypothetical.

"Easier than inventing Rust" is very much not the same as "pretty easy", though...

And in a world where Rust already exists, in most cases it's easier to just use Rust than trying to write "that kind of thing" as a DSL in Lisp.

Or maybe using Rust is an instance of the sunk-cost fallacy. It's possible that the net costs of living with Rust's constraints are larger than the cost of re-implementing it in CL. This has undoubtedly been the case for C and C++. The cost of living with C's constraints (or lack thereof) is incalculable, surely billions of dollars, possibly trillions if you add up the costs of all the buffer overflow vulnerabilities that have cropped up through the ages. You could probably write one hell of a CL compiler for a billion dollars.

This is why Apple, Google and Microsoft have finally started to (slowly) move away from them (or deeply push mitigation strategies), with the increase of networked devices, fixing those CVEs is finally making visible results in what would be otherwise profits.

I don't think Lisp is as clearly superior to Rust, as Rust is to C.

> The target language for your DSL compiler can be Common Lisp rather than machine language without sacrificing performance.

Uh, how exactly does that work? Which CL impls can e.g. vectorize as well as rustc does?

Reply on news.ycombinator.com