4 ms·

I'm surprised people have managed to port Clojure to so many platforms. Seems like a ton of work! :) From what I understand the vanilla JVM implementation isn'

by geokon 5y ago

I'm surprised people have managed to port Clojure to so many platforms. Seems like a ton of work! :) From what I understand the vanilla JVM implementation isn't built around a small core. So it's not like porting a Scheme. All the data structures and what-not are written with Java (not a criticism, it's great for performance and interop) But wouldn't it make more sense to first rewrite Clojure itself in some small/minimal scheme-y subset of Clojure - and then port that subset to Rust/Dart whatever? (With some performance penalty) I'm not super on top or Clojure's implementation, and people are prolly not doing this for a good reason - so I'm likely off base here somewhere

tko38 5y ago
> But wouldn't it make more sense to first rewrite Clojure itself in some small/minimal scheme-y subset of Clojure - and then port that subset to Rust/Dart whatever? (With some performance penalty) Actually indeed I think this is a possible route I went or have a note to try somewhere. The idea being if we can make a very lean Clojure core, and then the std library built upon that instead, it should be easier to port to other systems and share code. Gets tricky of course once you deal with code that relies at all on any sort of interop somewhere, but I should probably not get too much into it as my heads not been in that space for a while haha. The idea of a unified, universal Clojure of some sort (whether possible and practical or not) is an interesting problem in all this
- giraffe_lady 5y ago
  I wonder how many partial implementations of clojure are out there targeting different runtimes. I recently ran into the fennel cljlib which is not quite the same idea but definitely close. Not that any of these are the individually the wrong choice at all. It does suggest a lot of duplicated work, but I also get the sense that each's goals are different enough they maybe don't have as much overlap as it's easy to assume.
roenxi 5y ago
Clojure isn't pitched to be a toy language. The sell is that it is making a great many really thoughtful design choices that add up to a pleasant language. The reason Clojure Classic is hosted on the JVM is because Rich wanted access to the Java ecosystem (and probably because the JVM is an awesome piece of tech). If ClojureRS follows the same mentality, the point here is someone wants to program in Clojure but have access to the Rust ecosystem. From this perspective it is clear why they'd avoid taking a small-subset approach with a possible performance hit. This isn't a tour of force showing how great Clojure is & how clever someone is that they can implement it on Rust. The idea is to get work done, using Clojure, which may need access to Rust's libraries. It doesn't need to be elegant, that isn't especially important.
- tko38 5y ago
  Actually as mentioned in another comment, I believe I did at least think about it, even if not for this project. However I believe I went in another direction
- temporallobe 5y ago
  I appreciate this comment, as it answers the exact question I had in my head. I was actually wondering what the point of implementing a JVM-based language in another language was, but this sums it up nicely. As a Java (and Clojure) developer, Clojure makes perfect sense to me and I love the inteop capabilities because I know the Java ecosystem. ClojureRS would therefore make a lot sense to a Rust developer.
bitwize 5y ago
> But wouldn't it make more sense to first rewrite Clojure itself in some small/minimal scheme-y subset of Clojure How about Scheme?: https://github.com/takeoutweight/clojure-scheme https://github.com/takeoutweight/clojure-scheme Note that this project is unmaintained and the last updates are ~10 years old.
panick21_ 5y ago
For ClojureScript a lot of the data-strucutres and other parts of the language were rewritten in Clojure. So bootstrapping is now easier. That said, you likely would want native data-structure instead of interpreted code that implements them.
sremani 5y ago
Gentle reminder, there is also ClojureCLR. https://github.com/clojure/clojure-clr https://github.com/clojure/clojure-clr
Blikkentrekker 5y ago
Most Scheme implementations also implement core data structures natively rather than in Scheme. They could be implemented in Scheme, as it could in most languages, but they ren't for the sake of efficiency. What I still continue to find interesting is that Idris2 compiles to Chez Scheme, and is somehow faster than Idris1 which compiled to C. The Chez Scheme implementation very much natively handles all important data structures.
didibus 5y ago
Most of Clojure is implemented in Clojure, it's not the most minimal of all Lisp, but relatively speaking compared to a lot of programming languages it is still quite minimal.
- geokon 5y ago
  Maybe it's a bit naiive, but I'd imagine having a small-core interpreted Clojure and different host implementation would incrementally overload functionality and reimplement using the host's features. But the design (granted I'm judging from the docs and API - not digging through the source) seems like things weren't designed for multiple hosts in mind.
  - didibus 5y ago
    I'm not really sure what you're imagining, but basically you need to implement the few special forms, the general rules of parsing and evaluation, and then you need to implement all the core types, and finally you need to bring in all the core data-structures and standard library functions. A lot of the standard library functions are already written in Clojure itself, and don't use interop, but a lot of them, as well as types, and core data-structures are implemented in Java, and core functions that uses them tend to use interop. So that stuff needs to be ported as well. And that's about it. Now, you might think it would be great if all the types, data structures and therefore all core standard functions could also all be implemented in Clojure on top of the special forms. But I actually think it's specifically because that's not the case that Clojure gets ported to so many hosts. The special thing is that this design makes Clojure hosted, which is very different from simply being implemented over multiple hosts. For example, Clojure always uses the host's native types. So Clojure types are the same as the host it is running on. That's why then interop becomes a first class thing, and why Clojure always feels very symbiotic and compatible with the host. And because it uses the host's native types, it also can't implement it's core data-structures and some of its core standard functions without using interop. Which is why those need to be re-implemented to be host specific normally. I think there's a few extra things you could lift to be in pure Clojure, and I think Clojurescript has lifted more of them to be so, but still the types are same.as the host. If this wasn't part of the design, the appeal of porting it would also be lost. It would just be like a bunch of exactly same Clojire language just with various quality of implement and performance characteristics, and people would probably just pick the ine that has the best performance and most stable. But instead, Clojure becomes an alternate language for a multitude of hosts. Suddenly it means you can use Flutter as easily as with Dart, but have Clojure as your language to do so. It means you can use NodeJS as easy as with JavaScript, but using Clojure as your language, etc. It's also why it's a bit wrong to say Clojure gets ported to other hosts, in reality it doesn't, what happens is someone creates a new dialect of Clojure that is well adapted to a new host. And that's also why it's so useful.

by geokon 5y ago

tko38 5y ago

> But wouldn't it make more sense to first rewrite Clojure itself in some small/minimal scheme-y subset of Clojure - and then port that subset to Rust/Dart whatever? (With some performance penalty) Actually indeed I think this is a possible route I went or have a note to try somewhere. The idea being if we can make a very lean Clojure core, and then the std library built upon that instead, it should be easier to port to other systems and share code. Gets tricky of course once you deal with code that relies at all on any sort of interop somewhere, but I should probably not get too much into it as my heads not been in that space for a while haha. The idea of a unified, universal Clojure of some sort (whether possible and practical or not) is an interesting problem in all this

giraffe_lady 5y ago
I wonder how many partial implementations of clojure are out there targeting different runtimes. I recently ran into the fennel cljlib which is not quite the same idea but definitely close. Not that any of these are the individually the wrong choice at all. It does suggest a lot of duplicated work, but I also get the sense that each's goals are different enough they maybe don't have as much overlap as it's easy to assume.

roenxi 5y ago

Clojure isn't pitched to be a toy language. The sell is that it is making a great many really thoughtful design choices that add up to a pleasant language. The reason Clojure Classic is hosted on the JVM is because Rich wanted access to the Java ecosystem (and probably because the JVM is an awesome piece of tech). If ClojureRS follows the same mentality, the point here is someone wants to program in Clojure but have access to the Rust ecosystem. From this perspective it is clear why they'd avoid taking a small-subset approach with a possible performance hit. This isn't a tour of force showing how great Clojure is & how clever someone is that they can implement it on Rust. The idea is to get work done, using Clojure, which may need access to Rust's libraries. It doesn't need to be elegant, that isn't especially important.

tko38 5y ago
Actually as mentioned in another comment, I believe I did at least think about it, even if not for this project. However I believe I went in another direction
temporallobe 5y ago
I appreciate this comment, as it answers the exact question I had in my head. I was actually wondering what the point of implementing a JVM-based language in another language was, but this sums it up nicely. As a Java (and Clojure) developer, Clojure makes perfect sense to me and I love the inteop capabilities because I know the Java ecosystem. ClojureRS would therefore make a lot sense to a Rust developer.

bitwize 5y ago

> But wouldn't it make more sense to first rewrite Clojure itself in some small/minimal scheme-y subset of Clojure How about Scheme?: https://github.com/takeoutweight/clojure-scheme https://github.com/takeoutweight/clojure-scheme Note that this project is unmaintained and the last updates are ~10 years old.

panick21_ 5y ago

For ClojureScript a lot of the data-strucutres and other parts of the language were rewritten in Clojure. So bootstrapping is now easier. That said, you likely would want native data-structure instead of interpreted code that implements them.

sremani 5y ago

Gentle reminder, there is also ClojureCLR. https://github.com/clojure/clojure-clr https://github.com/clojure/clojure-clr

Blikkentrekker 5y ago

Most Scheme implementations also implement core data structures natively rather than in Scheme. They could be implemented in Scheme, as it could in most languages, but they ren't for the sake of efficiency. What I still continue to find interesting is that Idris2 compiles to Chez Scheme, and is somehow faster than Idris1 which compiled to C. The Chez Scheme implementation very much natively handles all important data structures.

didibus 5y ago

Most of Clojure is implemented in Clojure, it's not the most minimal of all Lisp, but relatively speaking compared to a lot of programming languages it is still quite minimal.

geokon 5y ago
Maybe it's a bit naiive, but I'd imagine having a small-core interpreted Clojure and different host implementation would incrementally overload functionality and reimplement using the host's features. But the design (granted I'm judging from the docs and API - not digging through the source) seems like things weren't designed for multiple hosts in mind.
- didibus 5y ago
  I'm not really sure what you're imagining, but basically you need to implement the few special forms, the general rules of parsing and evaluation, and then you need to implement all the core types, and finally you need to bring in all the core data-structures and standard library functions. A lot of the standard library functions are already written in Clojure itself, and don't use interop, but a lot of them, as well as types, and core data-structures are implemented in Java, and core functions that uses them tend to use interop. So that stuff needs to be ported as well. And that's about it. Now, you might think it would be great if all the types, data structures and therefore all core standard functions could also all be implemented in Clojure on top of the special forms. But I actually think it's specifically because that's not the case that Clojure gets ported to so many hosts. The special thing is that this design makes Clojure hosted, which is very different from simply being implemented over multiple hosts. For example, Clojure always uses the host's native types. So Clojure types are the same as the host it is running on. That's why then interop becomes a first class thing, and why Clojure always feels very symbiotic and compatible with the host. And because it uses the host's native types, it also can't implement it's core data-structures and some of its core standard functions without using interop. Which is why those need to be re-implemented to be host specific normally. I think there's a few extra things you could lift to be in pure Clojure, and I think Clojurescript has lifted more of them to be so, but still the types are same.as the host. If this wasn't part of the design, the appeal of porting it would also be lost. It would just be like a bunch of exactly same Clojire language just with various quality of implement and performance characteristics, and people would probably just pick the ine that has the best performance and most stable. But instead, Clojure becomes an alternate language for a multitude of hosts. Suddenly it means you can use Flutter as easily as with Dart, but have Clojure as your language to do so. It means you can use NodeJS as easy as with JavaScript, but using Clojure as your language, etc. It's also why it's a bit wrong to say Clojure gets ported to other hosts, in reality it doesn't, what happens is someone creates a new dialect of Clojure that is well adapted to a new host. And that's also why it's so useful.