4 ms·

Also a shout out to Steel (https://github.com/mattwparas/steel https://github.com/mattwparas/steel), another Scheme-on-Rust which is more active. The Rust comm

Also a shout out to Steel (https://github.com/mattwparas/steel https://github.com/mattwparas/steel), another Scheme-on-Rust which is more active. The Rust community has given us at least two Scheme runtimes, several JS runtimes, but no Clojure interpreter yet that I'm aware of. There are a few zombie projects squatting on the name (seems common in Rust) but no viable releases.

harrison_clarke 2y ago
there's no reason you couldn't do a clojure in rust but the main implementation benefits from GC and making it easy to call host (java) methods. as far as i know, the core clojure data structures are kinda hard if you don't have a GC
- packetlost 2y ago
  Lisps almost universally require or expect GC.
  - pjmlp 2y ago
    Yes, although the Common Lisp derived ones, and the old ones from Xerox, Symbolics, TI and co, also have other capabilities available, especially for the low level programming part, and all common data structures, not only lists.
  - TransAtlToonz 2y ago
    The only mature, production-used exception of which I can think is Naughty Dog's Game Oriented Object Lisp/Game Oriented Assembly Lisp. EDIT: I was wrong, wikipedia claims there are basic GC functions. I can't speak to the details, but I imagine that whatever they have would attempt to lift allocations out of the hot path/use arena allocation or some similar mechanism. That said, people have strong opinions on whether reference counting counts as GC. I say it does, but others are vehement that it does not. If it does not count as GC, I think Interlisp-D would qualify.
- JonChesterfield 2y ago
  The hashed trie structure is definitely more annoying to write without a general garbage collector. Reference counting it works though, and comes with the magic trick that a reference count of one means you're the only reference to it, i.e. only one thread can see it, thus mutation is safe. Encoding that in the lifetime rules of rust might be a nuisance. Works very well in C.
  - kibwen 2y ago
    Rust has provisions for safely existing outside of the lifetime rules, which exist largely to accommodate refcounting schemes. You'd likely be using an Arc<RwLock<T>> here. Otherwise you can implement something on your own and express whatever C-style shenanigans you have in mind via the primitives in std::cell or std::sync.
    - harrison_clarke 2y ago
      you could do it in rust with Arc<T>.get_mut if you're implementing the clojure data structures, you wouldn't use a cell inside. semantically, they're immutable, and the operations on them all return copies that share nodes with the old one. if you know the old one won't be used, you can cheat and mutate it instead the issue with using Arc for these data structures is that it's a fatter pointer (costs memory, causes cache pressure), and it requires atomics/fences. they also generate a ton of garbage in typical use-cases (unless you can do the mutation optimization). languages with a compacting GC also usually get a faster allocator it's basically ideal conditions for a GC to outperform reference counting
      - kibwen 2y ago
        I don't doubt that a good GC can generally outperform a simple refcounting scheme, but when it comes to the aforementioned count-of-one optimization, Rust already gives you that out of the box by dint of the fact that owned values are moved by default and bumping the refcount is an explicit operation, which means that in any given scope you can simply pass the handle on if you're done with it and subsequent functions can access it without needing to touch the counter at all.
Jeaye 2y ago
I expect that jank will be migrating from C++ to Rust, at some point. https://github.com/jank-lang/jank https://github.com/jank-lang/jank
- pjmlp 2y ago
  They would hardly gain anything and lose access to 40 years of libraries.
  - remexre 2y ago
    Aren't they calling C++ functions via LLVM? Their implementation language shouldn't affect their ability to _generate_ code that uses the C++ ABI.
    - pjmlp 2y ago
      If it is a Clojure dialect, implementated on top of a compiler construction kit written in C++, generating C++, and calling into C++ libraries, what is the benefit of rewriting part of it in Rust, complicating the whole toolchain, only to write some blog post about the rewrite? If it is about additional safety, in any regard, self hosting would be the answer, not Rust.
      - deleted 2y ago
        [deleted]
      - zamalek 2y ago
        One of the main goals of the project is to bring REPL workflows to C++: https://youtu.be/ncYlHfK25i0?si=rmzp5In3sv3IFlvA&t=965 https://youtu.be/ncYlHfK25i0?si=rmzp5In3sv3IFlvA&t=965
- jwhitlark 2y ago
  That’s really interesting, as a long time clojurist and recent rust user. Can you expand on that, or is it too early days?
no_wizard 2y ago
The Clojure community hasn't even closed the gap on the CLR implementation they been working on for years, as far as I am aware.

harrison_clarke 2y ago

there's no reason you couldn't do a clojure in rust but the main implementation benefits from GC and making it easy to call host (java) methods. as far as i know, the core clojure data structures are kinda hard if you don't have a GC

packetlost 2y ago
Lisps almost universally require or expect GC.
- pjmlp 2y ago
  Yes, although the Common Lisp derived ones, and the old ones from Xerox, Symbolics, TI and co, also have other capabilities available, especially for the low level programming part, and all common data structures, not only lists.
- TransAtlToonz 2y ago
  The only mature, production-used exception of which I can think is Naughty Dog's Game Oriented Object Lisp/Game Oriented Assembly Lisp. EDIT: I was wrong, wikipedia claims there are basic GC functions. I can't speak to the details, but I imagine that whatever they have would attempt to lift allocations out of the hot path/use arena allocation or some similar mechanism. That said, people have strong opinions on whether reference counting counts as GC. I say it does, but others are vehement that it does not. If it does not count as GC, I think Interlisp-D would qualify.
JonChesterfield 2y ago
The hashed trie structure is definitely more annoying to write without a general garbage collector. Reference counting it works though, and comes with the magic trick that a reference count of one means you're the only reference to it, i.e. only one thread can see it, thus mutation is safe. Encoding that in the lifetime rules of rust might be a nuisance. Works very well in C.
- kibwen 2y ago
  Rust has provisions for safely existing outside of the lifetime rules, which exist largely to accommodate refcounting schemes. You'd likely be using an Arc<RwLock<T>> here. Otherwise you can implement something on your own and express whatever C-style shenanigans you have in mind via the primitives in std::cell or std::sync.
  - harrison_clarke 2y ago
    you could do it in rust with Arc<T>.get_mut if you're implementing the clojure data structures, you wouldn't use a cell inside. semantically, they're immutable, and the operations on them all return copies that share nodes with the old one. if you know the old one won't be used, you can cheat and mutate it instead the issue with using Arc for these data structures is that it's a fatter pointer (costs memory, causes cache pressure), and it requires atomics/fences. they also generate a ton of garbage in typical use-cases (unless you can do the mutation optimization). languages with a compacting GC also usually get a faster allocator it's basically ideal conditions for a GC to outperform reference counting
    - kibwen 2y ago
      I don't doubt that a good GC can generally outperform a simple refcounting scheme, but when it comes to the aforementioned count-of-one optimization, Rust already gives you that out of the box by dint of the fact that owned values are moved by default and bumping the refcount is an explicit operation, which means that in any given scope you can simply pass the handle on if you're done with it and subsequent functions can access it without needing to touch the counter at all.

Jeaye 2y ago

I expect that jank will be migrating from C++ to Rust, at some point. https://github.com/jank-lang/jank https://github.com/jank-lang/jank

pjmlp 2y ago
They would hardly gain anything and lose access to 40 years of libraries.
- remexre 2y ago
  Aren't they calling C++ functions via LLVM? Their implementation language shouldn't affect their ability to _generate_ code that uses the C++ ABI.
  - pjmlp 2y ago
    If it is a Clojure dialect, implementated on top of a compiler construction kit written in C++, generating C++, and calling into C++ libraries, what is the benefit of rewriting part of it in Rust, complicating the whole toolchain, only to write some blog post about the rewrite? If it is about additional safety, in any regard, self hosting would be the answer, not Rust.
    - deleted 2y ago
      [deleted]
    - zamalek 2y ago
      One of the main goals of the project is to bring REPL workflows to C++: https://youtu.be/ncYlHfK25i0?si=rmzp5In3sv3IFlvA&t=965 https://youtu.be/ncYlHfK25i0?si=rmzp5In3sv3IFlvA&t=965
jwhitlark 2y ago
That’s really interesting, as a long time clojurist and recent rust user. Can you expand on that, or is it too early days?

no_wizard 2y ago

The Clojure community hasn't even closed the gap on the CLR implementation they been working on for years, as far as I am aware.