[HN Gopher] ClojureRS - Clojure interpreter implemented in Rust
___________________________________________________________________
ClojureRS - Clojure interpreter implemented in Rust
Author : capableweb
Score : 117 points
Date : 2022-04-30 08:17 UTC (14 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| 0atman wrote:
| My two favourite languages made a baby!
|
| Would love to see this implemented as a macro too, like
| macro_lisp!
| newskfm wrote:
| Hammershaft wrote:
| From the github: Project Goals:
|
| 1: To create a version of Clojure that gets to exist independent
| of a particular platform
|
| 2: To explore a Clojure that, being more independent, has
| Proper tail call elimination Conditions / Restarts
| Any other feature it might not normally be able to indulge
|
| 3: To, should the project progress, begin looking more serious
| into advanced compilation techniques, to create a serious Clojure
| implementation ---
|
| This is exciting stuff!
| pcr910303 wrote:
| (While it seems that the project isn't active) I'm interested not
| because of the Rust part but because of the more independent
| part, with plans to implement conditions and restarts [0].
|
| I've mentioned a few days ago [1] about the lack of a clean and
| consistent lisp (in the development sense, not in the core-
| language-is-tiny sense) with a CL-like REPL-driven development
| workflow: maybe Clojure with conditions and restarts can be part
| of the picture?
|
| (In Common Lisp, restarts and conditions are a major part of the
| REPL as it allows the REPL to have a mechanism to catch error
| conditions and allows the user to resume execution appropriately,
| after the user debugs and fixes errors.)
|
| [0]: https://lisper.in/restarts
|
| [1]: https://news.ycombinator.com/item?id=31179701
| joshlemer wrote:
| Thanks for sharing! I think these restarts could definitely be
| implemented as a library in Clojure with the help of a
| coroutine library like
| https://github.com/leonoel/cloroutine#guides
| didibus wrote:
| Someone added conditions/restarts to Clojure:
| https://github.com/IGJoshua/farolero
|
| It does allow errors to be caught by the Repl and choose how to
| handle them.
|
| Honestly though, I haven't found the interactive restarts at
| the REPL useful. It's way faster to just re-evaluate the code
| again.
|
| Maybe in CL they are more useful because the language is full
| of mutation? I can't say, I've only ever done Clojure and Emacs
| Lisp, but in Clojure I tried that library, and found picking
| options at the REPL to handle the condition was more laborious
| than just fixing whatever or adding a catch and pressing
| Ctrl+Enter again.
| tko38 wrote:
| Oh hey, yea this is mine. Stopped for a while initially because
| of serious epilepsy. Don't know when I'll pick it back up but
| in my free time I've been trying to think of what direction I
| want to take with it, because another goal not listed there (I
| think) is a Smalltalk-like development environment, but I
| almost wonder if I should just make that in vanilla Clojure. I
| do have a branch locally starting the implementation built upon
| some Rust graphics lib (iced or druid maybe)
| capableweb wrote:
| Nice to see you here, thanks for stopping by :) Really sad to
| hear about the epilepsy, hope it's going better now!
|
| Regarding picking it back up, would you have any interest in
| being funded by the community to work on the project? I know
| myself and others are very interested in seeing Clojure in
| Rust with interop, and would be interested in funding the
| effort if it's something you're interested in.
|
| Maybe you could leave some contact details on your about page
| here on HN (no one except HN mods/admins can see your email)
| and we could talk privately if you prefer that.
| tko38 wrote:
| Not sure, would have to discuss and think about it. I just
| put my email on my about page if that helps
| capableweb wrote:
| > I've mentioned a few days ago [1] about the lack of a clean
| and consistent lisp (in the development sense, not in the core-
| language-is-tiny sense) with a CL-like REPL-driven development
| workflow: maybe Clojure with conditions and restarts can be
| part of the picture?
|
| There seems to be some efforts of adding user-land conditions,
| see for example https://nextjournal.com/pangloss/a-tutorial-on-
| conditions-an...
|
| One could imagine another user-land REPL that also makes use of
| that, to give a similar REPL for Clojure as for Common Lisp.
| ReactNative22 wrote:
| Now can someone do the same for Common Lisp :D That would be
| amazing
| cardanome wrote:
| Why? What is missing for you from the great implementations we
| already have?
| Jach wrote:
| Someone did: https://github.com/ruricolist/cloture
| ducktective wrote:
| I've been checking out Babashka [1] recently. It allows you to
| write clojure scripts and output a single-binary with fast
| startup time.
|
| Then I did a very brief search for clojure libraries, things like
| parsing html. Most of the github projects were not seeing much
| activity (like last commit in 2020).
|
| I've found bash-as-glue of unix programs like ImageMagick, curl,
| jq and pup very practical [2]. I was just looking for a possible
| alternative to be sure I'm not missing out. Doesn't seem like it.
|
| Anyone wants to hop in and sell me on his own approach?
|
| [1]: https://babashka.org/
|
| [2]: https://news.ycombinator.com/item?id=31142635
| didibus wrote:
| Nothing prevents you from using babashka and still use it as a
| glue for Unix programs. The difference is you get a nicer
| language (my opinion), a REPL if you want, and also you do get
| access to a lot more libraries from Java and Clojure and the
| pod concept if you need too as well, sometimes for more advance
| use cases.
|
| So to be clear, you can easily use ImageMagick, curl, jq, pup,
| etc. See: https://clojure.github.io/clojure/clojure.java.shell-
| api.htm... and https://github.com/babashka/process
|
| Other benefits are that you only need to learn Clojure and
| suddenly you can use it for everything, backend apps, frontend
| apps, scripts, etc. You don't need to learn bash, js, java, go,
| make, etc.
|
| > Then I did a very brief search for clojure libraries, things
| like parsing html. Most of the github projects were not seeing
| much activity (like last commit in 2020)
|
| This surprises everyone, but those libraries still work, have
| no bugs, are missing no features, and can be used without
| issues in production.
|
| Clojure is one of the most stable language, so things never
| break and almost never need updating.
|
| People have a kind of Stockholm syndrome I think coming from
| other languages that if something didn't need a bug fix in a
| year it must be abandoned and broken.
|
| And the reason you often don't need to update those libraries
| to keep up with the environment, like OS versions, is because
| they all leverage existing runtimes under the hood like JVM and
| that's the one that updates. So they're all secure and kept up
| to date, working with new OS and new architecture for free as
| JVM updates. This applies to Babashka as well, because it is
| implemented using a JVM.
| jonahbenton wrote:
| One data point, from a registered bashochist, and a clojurist-
| I think he's on to something for Clojure-based build tooling.
| bb is much more ergonomic than the tooling Cognitect is
| themselves providing. But I don't see it getting into my main
| non-clj shell workflow. That's even though I really don't like
| having to appease jq's opinions of aggregate hierarchical
| querying. But there's too much unique value working directly in
| the shell in most cases.
|
| Where the shell work dips directly into areas clj is strong-
| pure data processing- I have recently been thinking that maybe
| bb could make it easy to create a full clj repl environment, so
| I wouldn't have to suffer through jq. But that wouldn't be
| doing the work in a shell with bb. It would be doing the work
| in a repl. FWIW.
|
| One other point- lack of activity on clojure libs is not the
| red flag it is in other languages. There's much, much less of
| the churn and grind that there is everywhere else in the
| ecosystem. When there is something novel that doesn't have a
| native clj implementation, it very likely will in Java, and
| pulling that into clj- even straight from java source on
| github- is easy.
|
| HTH. Cheers.
| ducktective wrote:
| You see, I keep asking myself, when I want image processing,
| I reach for IM. video processing? ffmpeg. Json/XML/any
| structured data? jc | jq.
|
| It's hard to beat this workflow. Like, what possible ""java""
| library is gonna beat the ubiquitous unix tools?
| jonahbenton wrote:
| Agree. Though- of tangential interest, on the margin-
|
| For a commercial project I have been dipping into
| webassembly, and figuring out how to run wasm inside a JVM.
| The setup ergonomics are terrible, because it's native code
| land.
|
| But it works, and performance is spectacular.
|
| With all the build tooling targeting wasm, maybe there is a
| crazy future where native engines become pervasively
| available under wasm, and therefore inside a JVM....
|
| This is not far from where Python has been- for 20 years.
| Its mechanical sympathy with native libraries is a big part
| of its current supremacy. But Py is a poor shell and repl,
| and most cli tools don't ship as engine libraries.
|
| So nothing yet competes with bash on the file system
| chaining together executables.
|
| Should there be widespread wasm, though, in THAT world, a
| Clojure repl with a nice menu of engines, caches, stores,
| all just functions and data- those ergonomics might get
| some people to switch...
|
| (fantasy goggles off now)
| fulafel wrote:
| For a more active native code Clojure interpreter with active
| users and practical libs, see also Babashka:
| https://github.com/babashka/babashka (links under Related
| projects heading can also be interesting)
| capableweb wrote:
| Built with the lovely SCI library
| (https://github.com/babashka/sci) + GraalVM, probably the most
| useful GraalVM project I've seen in the wild so far.
|
| Also, Babashka will probably always support more features than
| ClojureRS ever could, particularly the interop with the various
| Java classes/functions, as that'd be very hard to achieve in
| ClojureRS.
| hiepph wrote:
| Extremely useful. I use it to write small to medium scripts,
| replacing Bash. For example, I wrote a small client that
| interacts with Pocket API. [1] Aside from interop with shell
| commands (I use Fish for that), most things seem pleasant so
| far.
|
| [1]
| https://github.com/hiepph/dotfiles/blob/master/scripts/_pock...
| geokon wrote:
| 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
| panick21_ wrote:
| 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.
| didibus wrote:
| 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.
| tko38 wrote:
| > 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 wrote:
| 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.
| sremani wrote:
| Gentle reminder, there is also ClojureCLR.
|
| https://github.com/clojure/clojure-clr
| roenxi wrote:
| 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.
| temporallobe wrote:
| 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.
| tko38 wrote:
| 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
| bitwize wrote:
| > 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
|
| Note that this project is unmaintained and the last updates are
| ~10 years old.
| Blikkentrekker wrote:
| 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.
___________________________________________________________________
(page generated 2022-04-30 23:01 UTC)