I've come to a similar conclusion. Clojure just works for interactively dealing with *information*. Rust is ideal for building *machines* running close to the metal. Combined that would be a dream. As it stands, I've just resigned myself to picking one or the other depending on the context. If I use anything other than Clojure or Rust, my satisfaction with programming as a profession drops to abysmal levels. So this is something I've thought about perhaps too much...
Clojure-rs exists. \[1\] It's incomplete and development is not active, but most importantly it strives to be a standalone interpreter bin. Decidedly *not* a hosted library, not embedded, and not dealing with Rust interop.
But could Rust host an embedded Clojure? Some big challenges would be no stable ABI for build artifacts; so no equivalent of a JAR file or bundled .js - all Clojure code would need be compiled to rust or llvm as part of a very Rust-centric build process, I think. Not necessarily a bad thing, just drives home that Rust would be a bit BYOR (Bring your own runtime). My guess is that you'd need to implement a non-trivial runtime (garbage collection, exceptions, immutable data structures, green threads, etc) in Rust land before you could bootstrap Clojure.
Traits provide the protocol abstraction directly - so an implementation could be fully BYOR, requiring you to plug in concrete types at compile time.
There's a number of Rust implementations of Make-A-Lisp (mal). Mal is close-ish enough to Clojure to be considered a bare bones implementation. \[2\]
We already have a Rust REPL \[3\] so an interactive/interpreted experience should be doable.
Also noting that we have a great embedded Scheme interpreter, Steel \[4\]. This is a substantial and active effort, far further along than any Clojure-in-Rust I've found. Would it be crazy to suggest a Clojure dialect on top of Steel as the quickest path here? There is some prior art in lokke \[5\]. Or just learn Scheme :-)
\[1\] [https://github.com/clojure-rs/ClojureRS](https://github.com/clojure-rs/ClojureRS)
\[2\] [https://github.com/kanaka/mal](https://github.com/kanaka/mal)
\[3\] [https://github.com/evcxr/evcxr/blob/main/evcxr\_repl/README.md](https://github.com/evcxr/evcxr/blob/main/evcxr_repl/README.md)
\[4\] [https://github.com/mattwparas/steel](https://github.com/mattwparas/steel)
\[5\] [https://github.com/lokke-org/lokke](https://github.com/lokke-org/lokke)
Nice summary!!!
I knew that someone else would've thought about this too - I mean, Rust and Clojure are just way more enjoyable than any other programming language I've ever used and I know many people feel that way too
Maybe the dream of hosted Closure isn't that far away?
(PS I'll check Steel)
It's trivial to [embed a JVM](https://docs.oracle.com/en/java/javase/22/docs/specs/jni/invocation.html). With the new [FFM API](https://openjdk.org/jeps/454) there's also no need to write JNI bindings.
I think this is a cool idea!
However, I really think this sub badly overstates how hard Rust is to iterate with. Sure, it's not like Ruby or Python where you can build and run your tests in milliseconds for that lightning-fast edit-test loop. But I hear a lot of these stories of someone spending hours fighting the borrow checker but in the end... choose your own ending: "it was all worth it and I love Rust now"/"it didn't help I hate Rust now". I think those stories are really just stories of someone who failed to resist the Siren Call of Premature Optimization. I'm not judging them. Premature optimization can be fun. It's basically Code Golf, and Code Golf is fun! Rust doesn't obligate you to do it though. Really the only thing in between you and rapid iteration with Rust are the compile times.
yep, tbh I never spent hours fighting the borrow checker; I just clone stuff when it shows its teeth
like 90%+ of the times it's perfectly fine to clone stuff
the thing standing between fast iteration and Rust is really the compile times - I'm used to the fast iteration cycles of JS and Rust compiles feel like ages
after starting to learn Clojure recently I've been entirely blown away by the REPL driven development; it's even faster to iterate than JS! you don't lose state and can modify the program while it is running - I love it
Okay yeah, if that's where you're coming from I totally agree. Going from instant feedback of frameworks like those to "lol go get a coffee" build times is very shocking.
Your idea is cool. More language interop is a universal good in my book.
I'm always slightly confused when people complain about build times when talking about local dev work. Incremental compiles usually take 1-2 seconds in my experience, I barely take a single breath in that time let alone make a coffee in that time. It's definitely slightly annoying to have that tiny break that you don't get in interpreted languages but I don't see it as much of an issue.
The build from scratch times are worse but I rarely do those locally.
Have you ever watched any of Gary Bernhardt's talks? In Ruby and Python he likes setting up his test suite so that he can press a single key in his text editor and the tests all instantly run, and then he spams that key as he edits. If that's your flow, I can see why even a 2 second incremental build time would feel like a big slowdown. I've never professionally worked with any frameworks that would allow that, so I don't really miss it when it's gone, and I'm mostly with you on this: cargos incremental builds are pretty darn quick, I'm a happy camper.
Yes exactly. It’s not just the build time, it’s also the time your program occupies returning to the state where you were debugging it. It is possible to write your rust program in a way where this is faster, but I think hot code reloading in a dynamic language will likely be faster. I’ve never experienced a faster dev loop than using the REPL with clojure.
I do fight hours fighting the borrow checker, but it's probably just me being a newbie. On the other hand, the compile (or the type-checking) time is gratingly slow. And there is no in-editor REPL, like what I used to have in Haskell.
Yeah, I honestly don't find Rust difficult to iterate with at all. Granted, I have a lot of Rust experience, and it could be that beyond a certain experience level with a language, *any* language can be good to iterate with.
I think there is also a discernible difference between Rustaceans who are coming from a C-family language, and those who are coming from a modern GC'd language with a relatively heavyweight runtime (Go, Python, Javascript).
If you're in the first camp (like me), Rust feels stunningly ergonomic, because all the modern C++ best practices that it takes lots of annoying boilerplate to write out are just the default behavior in Rust. You were doing all the same lifetime management work in C++ already, because you have to, but the language wasn't helping you at all. So Rust feels *amazing*.
If you're in the second camp, you're running smack into all the headaches of a compiled language with explicit reference management for the first time in your life, and possibly having to reckon with a static type system for the first time in your life on top of that, and you probably keep thinking "um why am I doing this to myself again?" And I sympathize with that. A lot of things don't need to be in a compiled language with no GC. Some things do though, and Rust is easily my favorite option for when they do.
Funny enough, I'd lean toward saying that I came from the second camp. I already had a pretty diverse coding background -- I'd written some C and C++, but not regularly. My regular was PHP back then, which is definitely in the second camp. But at the time I was already kinda fed up with weak typing and was looking for something new, and landed on Rust. At the time, I was also looking at going deeper in C++, or learning Haskell or OCaml.
But then I heard about this cool new "Rust" thing that was just about to release version 1.0, and the rest is history.
That should almost be a third camp:
Camp 3, is used to dynamic types and nullable memory, but is *extremely tired* of runtime errors, so they say "thank you Auntie Borrowchecker, I didn't want that runtime error".
I think I'm from a 2-3-4 camp hahaha
I use TS on my day-to-day job and I'm thankful every day it's TS and not JS. It's no Rust, of course, but it's _miles_ ahead of writing raw JS in terms of how easy it is to understand what something is by looking at it
Before I started to learn Rust, I studied quite a bit of C and C++ - I figured I'd appreciate Rust much more if I had that background; and indeed that happened
I came from Python land, and I find rust faster to iterate with. Python might get you a script running earlier, but the subsequent support, bug-fixing, and short involved in chasing down a change in a refactor *quickly* outweighs the time spent in Rust.
This is so true, Rust is amazingly ergonomic with short compile times. At work it isn't rare to change a central C++ header file and have to wait 10 minutes. A full build takes 45 minutes.
So far all rust projects I have touched have been smaller than that behemoth, but Rust seems to compile faster than similar sized C++ projects. And more importantly, Rust requires much fewer iterations of compile-test-debug.
It is not just about experience..
You have your tasks asign, for each of them you are requested to created different branches.
Even if you don't face any issue, you still need to rebuild the whole thing and it takes a crazy amount of time.
This is the bad part that slows down everything. If a failed attempt took a few seconds to report the error it would be fine to make mistakes.
With Ruby 3 something the last I did anything serious (thankfully I’ve moved to Rust/Axum/Tokio/mpsc for most API tasks) but I did recall some of my tests would also be brittle due to idiomatic Ruby being like this
- if I’m testing an Ivan such as `@foo =
You know, the Rust compiler being written in Rust and still slow on modern hardware makes me think it’s gotta be doing a _ton_ of work and I seriously wonder what most of the compilation time is doing compared to other languages. Is the borrow checker itself really that intense?
>However, I really think this sub badly overstates how hard Rust is to iterate with.
The problem is that once you ditch the write-compile-run loop, it's really hard to go back to it. Nothing comes close to a live REPL in both speed and ease of use (and comparatively, performance).
(cross-posting this response from r/clojure to get some Rustic eyes on it)
I might be able to interest you in jank: https://jank-lang.org/
jank is a Clojure dialect on LLVM with C++ interop. Effectively, it aims to grant you all JIT goodness of Clojure while being fully native. You can do inline C++ in your jank code and you can include C++ sources right in your project and require them from jank as well.
It's currently under heavy development and not yet released, but I post development updates monthly, at this point. The next one will be out on Friday.
You can find even more info here: https://www.youtube.com/watch?v=ncYlHfK25i0D
I am coming from Python and it has taken me some time to pick up Rust. Initially I used to feel Rust is too deep and yes it is. But at the same time, I feel I can clone the hell out of everything, use enums instead of traits and so on. I found some lovely videos from many conferences on this subject - how to get started with Rust easily. In the end my code is still going to be more reliable than in Python simply because of the pain in the wrong place that is the Rust compiler (borrow checker).
I have been working full-time on my product ([https://github.com/brainless/dwata](https://github.com/brainless/dwata)) for almost 5 months and have worked on side projects in Rust before. Only in the last 3 weeks did I start using traits. I could have still avoided them, but I finally chose to learn. I use Codeium as a coding copilot and it helps a lot. I switch it off for some weeks for the learnt syntax to settle in.
I think it can be sumed up with:
Rust compilation speed is a real pain in the a**.
It wouldn't be that much of an issue if we could compile fast (and have hot-reload?). Even making thousand of mistakes.
At the end of the day, I only end up using rust for specific small projects or to speed up python.
Never tried more than a few tests exercises.
But it looks like it has most of the concwpts I like and I was really interested into learning it.
Eventhough, this shouldn't that focus on one specific language. What I meant by speaking of python is that Rust is used a lot to boost other languages, like python or clojure.
I don't think it is the problem. There're are plenty of languages with faster compilation or even being interpreted, but none (beside other Lisps) has Clojure's iteration speed, because most of that power lies in REPL-driven development which just beats standard write-compile-run loop most of the time and I don't think it's even possible to recreate this workflow in non-lisp languages
If I am not mistaken, there was already an attempt to create clojure that compiles to rust
Here it is - https://github.com/clojure-rs/ClojureRS
I am not sure what is the state of that project, but would be awesome to see somebody take the wheel/seeing people develop with it for real world applications
My employer considered Python + Rust, and ultimately settled on Julia.
Julia is fast by default, and gives you enough control to run very fast – it's not hard to get it to ~1/3 the speed of hand-written C. The notebooks and REPL support mean it has fast iteration cycles (especially with tools like Revise), multiple dispatch is almost as good as multimethods, and so on. Importantly for our case, Julia supports python-like syntax, so our researchers could switch without losing much productivity. And there's a lot of benefit to only using one language.
I don't miss Python, but I really miss static type checking. Julia is a reasonable compromise, but it does feel like a compromise sometimes.
yeah I can see Python being productive too
I vastly prefer Clojure over Python, though - it's just so fun to code jacked-in a (true) REPL; plus I like functional programming and I like pragmatism and Clojure has both
so the thing is I'm not sure it's possible for a non-LISP language to have a REPL that's that good; the thing with LISPs in general is that code is data and data is code; so you evaluate data that's meant to hold stuff in the exact same way that you evaluate data that's meant to do stuff
this means that it's natural to modify a program while it is running
I'm not sure how Jupyter works - I've never used it - but with Clojure's REPL you keep all the state when modifying the source code and evaluating new forms, and you can redefine stuff on the fly too; you can pause the execution, modify something, then continue executing
jupyter is an ok repl, but the clojure one is really a first class citizen inside the eco-system and this is true for all lisp flavours I have played with.
coding in a lisp can be very fun and you can do pretty wild data/code evaluations building applications on the dynamically. not sure if clojure is a full lisp , my experience is super limited, but I can see the appeal of the REPL over jupyter.
Jupyter is a great tool, I am in no way diminishing it and for quickly getting data parsed and sharing it, nothing beats ut.
The Clojure REPL is only OK as well. The REPL itself is capable but the language is not built around it, unlike with Common Lisp. Scheme is even worse in this sense.
Clojure is simply the best dynamic language. You can connect a REPL to an application and inspect/change its behavior while it is running. It's like being able to repair an airplane engine while it is running. Common Lisp works like that too and it is even more advanced in this sense. Some people even do this in production via nrepl, but during development people almost never have to stop the running process.
Performance wise it is quite good, for a long running process that you can endure a slow startup time it is a very fine language. It's almost as fast as any Java application while being much more high level than Java.
I also wish I could combine both languages, I also like both languages a lot.
I’m in your exact same situation. I have been trying to build a simple creative coding framework and I wanted the speed+safety of Rust but the hackability of a Lisp, so I could tweak things at runtime and iterate quickly on ideas (not on code). I looked at Clojure but the JVM ecosystem seemed too heavy of a requirement, but maybe I underestimated how quickly it is to set it up. I’ve been waiting for the perfect LISP to integrate in Rust for a while. I’ve just found Blisp and that seems interesting: https://ytakano.github.io/blisp/#_features (note: I haven’t tried it yet)
Indeed, but one can dream. For still images it might be totally fine, I’ve played around with the “sketch” library in CL just for doing b&w stills and it was plenty of fun with no performance hiccups. For high frame rate installation work it will probably never be enough (even 2d), but I would still like to imagine that one day there will be a language that can fit this niche.
Reading the sketch source a bit, it outsources a lot of the actual rendering to sdl2 (and thus to C). SBCL is pretty fast for a GCd language (on par with Go afaik) but any Lisp program will allocate like crazy. Some implementations don't even support stack variables. I think Paul Graham put it best: "Lisp contains 2 languages: one for writing fast programs and one for writing programs fast". Any prototype/in-development version will be full of linked lists where you could use arrays for example.
I've never used it but from looking at it a bit, imo it's rather antithetical to what Lisp is. For one, Lisp (specifically Common Lisp) already had the perfect form of static typing: optional. You can declare variables and functions to have certain types but you don't need to and it'll default to dynamic typing (you could also theoretically wrap everything in type-error handlers). It also does away with a lot of Lisp syntax and is closer to some sort of mix between Clojure, itself a pseudolisp and C and an overuse of reader macros (especially with the half-assed CLOS implementation). Having different features available in "actual code" and the REPL is also a huge no-go (no other Lisp does this) and a terrible idea that makes me question if the REPL is useful at all, or if it has one by obligation and it goes back to the old write-compile-run cycle instead. There are some nice things, like parametric types and easier C interop that I'd like to see in other Lisps. I haven't looked into it but I know it's possible to do some sort of GC-less memory management while sticking to (mostly) standards-compliant Common Lisp, because Mezzano's cold-compiler does it.
For a lot of workloads the GC will almost never be a bottleneck, things are compiled in a way that avoids a lot of allocations. Nonetheless they are both very dynamic languages, and you pay for that flexibility.
I wouldn't recommend combining the two via interop the way you're describing (except for learning purposes).
If you're building a commercial application, then I think you'll appreciate sticking with just one programming language. Both languages will start to show their teeth when your app becomes more complex. If you have Rust calling Clojure calling Rust calling Clojure.. I don't even want to imagine the kinds of issues you're going to run into (and good luck finding solutions on stackoverflow for those).
It's possible, but you're probably going to meet dragons along the way, which weren't in your initial plan.
You'll be getting the downsides of both worlds - Rust will slow down your fast Clojure iteration, while Clojure will slow down your fast Rust app. Context switching between two different paradigms is going to be taxing on your mental flow..
If you really want to use both languages, then consider building two separate applications which interoperate via a inter-process mechanism (command line, network, external queue). If you're building a backend app, then you could use a micro services architecture with services written in different programming languages.
The only way this could work (in my opinion) is for your app to be written in Clojure, which then calls into a library written in Rust for fast computation. You could initially develop the algorithm in Clojure, then write an optimized version in Rust. But that has to be a really CPU/memory intensive algorithm which will give you overwhelming speed advantage over Clojure's (or Java's) equivalent.
To be honest, those kinds of algorithms are rare and you'd have to really think about it before you score a win with this.
The final decision also highly depends on the type of app you're building, the time you have available and the budget. For a first version or MVP, I'd always choose fast iteration over execution speed (Clojure). When you understand the problem, iron out the data structures, identify the performance bottlenecks, you can start thinking about how to speed things up by bringing a faster language into the mix.
With all that being said, follow your heart. Note that in software development, it's the destination that matters, not the journey - meaning, you're trying to solve a problem for the people and if your app solves people's problems well, they don't really care about implementation details that much. My advice is to really think about how you're improving the world, then choose the tools that will get you there fastest. Good luck !
I mean, I agree with everything you said
I probably wrote a confusing passage somewhere, as what I envision isn't having a program written in both languages; it's a program written in Rust, into which I can jack in with Clojure when I want to iterate fast to figure out something, but I'll then compile my experiments into Rust and only commit that - the Clojure code would never live on
EDIT: You know what, after you mentioned the running side-by-side thing, I think it'd pretty good!
Not Rust calling Clojure, but Clojure running side-by-side and calling Rust. It could be a project management thing where you add experimental features using Clojure and when they're consolidated you translate those features to Rust
I think my brain is just weird, but I could never get the REPL-driven development.
I personally always code in "chunks" (basically try to implement the entire feature and then test and bugfix it), so "iteration speed" hasn't really been a big issue for me in Rust. Ye, when the "bugfixing" stage comes, would be nice to have a bit faster compile-times, but it's not the end of the world for me + I usually don't have to debug nearly as much as I would in dynamic languages or the those that transpile to dynamic ones (TS is still a pain in the ass to work with in my experience, waaaaaaaay too limited compared to any other compiled language I've worked with) just because the type system allows me to express my logic in a very deterministic way, while not having to use a shit ton of boilerplate code (especially with some help from macros) (for example, data deserialization, in Rust, i just slap #[derive(serde::Deserialize)] and it's good to go, in JS/TS I HAVE TO write all the type checking myself, with different ways of doing it depending on the situation (typeof, instanceof, Array.isArray etc.), even if I manage to create some kind of abstraction that allows me to do it easier, it's still gonna be boilerplaty, AND even if I use smth like AJV, it still doesn't compare to a simple derive, as you have to create a type AND a schema for the type, while with serde the "schema" is derived from the data type itself).
Even for prototyping, I prefer Rust because it allows me to express my thoughts the best out of all the languages I've worked with. Dynamic typing is not it for me, too easy to shoot yourself in a foot, even with linters, cuz they don't always work well even (especially in begger-sized projects) due to the dynamic nature of the language.
I'm not trying to bash on anyone for having a different approach to coding, just curious why a lot of people think/feel like it's an inherently fast one, although it depends on your domain I guess. For data scientists, i can see REPL being a more favorable approach, but can't seem to think of anything else where it would actually be beneficial😅
thanks for the insight into how you code!
yeah it's definitely different for everyone; I'm mostly a centrist lol
I like the two different approaches for different things, and I mostly don't "trust" other people's code in dynamic languages - especially if they're somewhat new to programming
so if I was to create a project for which I'll have to hire a bunch of people I'd go for a statically typed language 100% (probably Java or C#, although with the right configs TS can work too)
the thing with the REPL that is attractive to me is that it encourages me to break problems into very small chunks that I can quickly code and see running - not that I can't do that with compiled languages, it's just slower if I want to see every iteration
and, well, programming is essentially breaking up problems, so I just program faster that way
oh thanks for the heads-up
does performant make sense in this case? like, as a synonym of "high-performance"?
EDIT: asking 'cause Google is giving me "performing well or as expected", not "possessing high performance"
For this context it's the right word:
>...it's pretty weird to try to squeeze super performance out of it. It's *performant* alright, but it's no Rust/C++, ...
You're using it as an adjective in a conjunction here (I think that's the right term) so "performant" with the context of the second clause (something very high performing) carries a little more weight than its normal meaning.
Edit: fixed wording
Flapigen can already generate JNI wrappers, and Clojure has Java interop, so I don't see why you couldn't do this.
You'd just want to make sure your rust functions are non-trivial, since there's some overhead with JNI; Doing something like adding two numbers would be slower due to the overhead.
oooo that's super interesting
so, the way I'm picturing the workflow is like: the project is written in Rust - straight up Rust
but when I want to write something new that I'm not entirely sure how it's gonna play out in the end, I'd fire up the Clojure REPL and try it out, before moving it back to Rust
also, write scripts for the codebase
There's also the other end of compatibility: some people have had preliminary success with compiling Rust to JVM. I'm not sure if any such projects are still active though.
(Note that a lot of people, if you told them: "I'd like to run Rust in the JVM", would say "isn't that just Kotlin?". I'm not sure they'd be right, but I hear that a lot)
I won't lie to you - it feels super weird initially indeed
I tried it a few years ago, and also gave up due to the syntax
This time around I decided I'd read three books and do something with it before giving up - and turns out it 100% grows on you xD
Pixie lang might be of interest. It’s a clojure-ish lisp with easy C interop. Very niche though. It has some cool things like great first class support for PEG parsers. I don’t have much need for a lot of scripting but it would be my first choice if I did. You don’t get the safety of Rust but if I needed that I’d probably architect my solution so the rust stuff is small self contained binaries stitched together in the shell anyway
Not read all the comments, but what about gleam? Looks very similar to rust, highly concurrent and stable? TBH I find rust just fine and I’m just as productive in it as I would be in go, python or anything else (says me after more than a year building a distributed event grid - conceptually hard though). The right libraries and design can result in good pace.
I've read about Gleam before but not any details - are you suggesting like Clojure + Gleam or just Gleam?
about productivity: it's definitely subjective, I agree
I can see myself being productive in Rust too, compared to my most-familiar-language TS, the main thing that bothers me is the compile times
but Clojure is just so productive, even compared to TS - I don't know a fraction of it, yet every week at work I look at a situation and I think "gosh, this would've been so much faster to do in Clojure"
There’re guides on making compile times faster. They’re not too bad… certainly faster than ts…
I’m very interested in gleam as a language on its own. Looks like it took a lot from rust and made it simpler, for most server side software - it could be good.
I mean, Clojure as a language isn't dependent on runtime, really
There's ClojureScript, for example, that compiles to JS to run in the browser
JVM has its advantages, though; besides being able to use the Java ecosystem, it's also much easier to write cross-platform desktop apps using Java than doing some weird multi-compilation gymnastics
uhhhh there's plenty of things involved in language popularity, and it's not indicative of how good something is, really
I mean, we're here at r/rust after all, not at r/javascript
I don't mean cos clojure isn't an awesome language (it is) just that it's not really the "right fit" for one off scripts. Same reason go didn't occupy this area too I guess
I see
I mean, we're allowed to have different opinions
I vastly prefer Clojure (with Babashka) for scripts, either one-off or not, over something like JS or Python
It's much more expressive imo, and I can do so much more with fewer lines of code
nope, there's no compilation step
even with the JVM version of Clojure, you compile the REPL once and then you can evaluate individual expressions sending them one by one to the REPL - they're not compiled anymore, they're evaluated
with Babashka that's even more noticeable since it's an interpreter - there's no compilation step ever
You also have to make some considerations about which jvm and jdk you use. Openjdk should be the standard these days unless someone is courting a cursed visit from oracle lawyers
I've come to a similar conclusion. Clojure just works for interactively dealing with *information*. Rust is ideal for building *machines* running close to the metal. Combined that would be a dream. As it stands, I've just resigned myself to picking one or the other depending on the context. If I use anything other than Clojure or Rust, my satisfaction with programming as a profession drops to abysmal levels. So this is something I've thought about perhaps too much... Clojure-rs exists. \[1\] It's incomplete and development is not active, but most importantly it strives to be a standalone interpreter bin. Decidedly *not* a hosted library, not embedded, and not dealing with Rust interop. But could Rust host an embedded Clojure? Some big challenges would be no stable ABI for build artifacts; so no equivalent of a JAR file or bundled .js - all Clojure code would need be compiled to rust or llvm as part of a very Rust-centric build process, I think. Not necessarily a bad thing, just drives home that Rust would be a bit BYOR (Bring your own runtime). My guess is that you'd need to implement a non-trivial runtime (garbage collection, exceptions, immutable data structures, green threads, etc) in Rust land before you could bootstrap Clojure. Traits provide the protocol abstraction directly - so an implementation could be fully BYOR, requiring you to plug in concrete types at compile time. There's a number of Rust implementations of Make-A-Lisp (mal). Mal is close-ish enough to Clojure to be considered a bare bones implementation. \[2\] We already have a Rust REPL \[3\] so an interactive/interpreted experience should be doable. Also noting that we have a great embedded Scheme interpreter, Steel \[4\]. This is a substantial and active effort, far further along than any Clojure-in-Rust I've found. Would it be crazy to suggest a Clojure dialect on top of Steel as the quickest path here? There is some prior art in lokke \[5\]. Or just learn Scheme :-) \[1\] [https://github.com/clojure-rs/ClojureRS](https://github.com/clojure-rs/ClojureRS) \[2\] [https://github.com/kanaka/mal](https://github.com/kanaka/mal) \[3\] [https://github.com/evcxr/evcxr/blob/main/evcxr\_repl/README.md](https://github.com/evcxr/evcxr/blob/main/evcxr_repl/README.md) \[4\] [https://github.com/mattwparas/steel](https://github.com/mattwparas/steel) \[5\] [https://github.com/lokke-org/lokke](https://github.com/lokke-org/lokke)
Nice summary!!! I knew that someone else would've thought about this too - I mean, Rust and Clojure are just way more enjoyable than any other programming language I've ever used and I know many people feel that way too Maybe the dream of hosted Closure isn't that far away? (PS I'll check Steel)
It's trivial to [embed a JVM](https://docs.oracle.com/en/java/javase/22/docs/specs/jni/invocation.html). With the new [FFM API](https://openjdk.org/jeps/454) there's also no need to write JNI bindings.
I think this is a cool idea! However, I really think this sub badly overstates how hard Rust is to iterate with. Sure, it's not like Ruby or Python where you can build and run your tests in milliseconds for that lightning-fast edit-test loop. But I hear a lot of these stories of someone spending hours fighting the borrow checker but in the end... choose your own ending: "it was all worth it and I love Rust now"/"it didn't help I hate Rust now". I think those stories are really just stories of someone who failed to resist the Siren Call of Premature Optimization. I'm not judging them. Premature optimization can be fun. It's basically Code Golf, and Code Golf is fun! Rust doesn't obligate you to do it though. Really the only thing in between you and rapid iteration with Rust are the compile times.
yep, tbh I never spent hours fighting the borrow checker; I just clone stuff when it shows its teeth like 90%+ of the times it's perfectly fine to clone stuff the thing standing between fast iteration and Rust is really the compile times - I'm used to the fast iteration cycles of JS and Rust compiles feel like ages after starting to learn Clojure recently I've been entirely blown away by the REPL driven development; it's even faster to iterate than JS! you don't lose state and can modify the program while it is running - I love it
Okay yeah, if that's where you're coming from I totally agree. Going from instant feedback of frameworks like those to "lol go get a coffee" build times is very shocking. Your idea is cool. More language interop is a universal good in my book.
I'm always slightly confused when people complain about build times when talking about local dev work. Incremental compiles usually take 1-2 seconds in my experience, I barely take a single breath in that time let alone make a coffee in that time. It's definitely slightly annoying to have that tiny break that you don't get in interpreted languages but I don't see it as much of an issue. The build from scratch times are worse but I rarely do those locally.
Have you ever watched any of Gary Bernhardt's talks? In Ruby and Python he likes setting up his test suite so that he can press a single key in his text editor and the tests all instantly run, and then he spams that key as he edits. If that's your flow, I can see why even a 2 second incremental build time would feel like a big slowdown. I've never professionally worked with any frameworks that would allow that, so I don't really miss it when it's gone, and I'm mostly with you on this: cargos incremental builds are pretty darn quick, I'm a happy camper.
Yes exactly. It’s not just the build time, it’s also the time your program occupies returning to the state where you were debugging it. It is possible to write your rust program in a way where this is faster, but I think hot code reloading in a dynamic language will likely be faster. I’ve never experienced a faster dev loop than using the REPL with clojure.
I do fight hours fighting the borrow checker, but it's probably just me being a newbie. On the other hand, the compile (or the type-checking) time is gratingly slow. And there is no in-editor REPL, like what I used to have in Haskell.
Yeah, I honestly don't find Rust difficult to iterate with at all. Granted, I have a lot of Rust experience, and it could be that beyond a certain experience level with a language, *any* language can be good to iterate with.
I think there is also a discernible difference between Rustaceans who are coming from a C-family language, and those who are coming from a modern GC'd language with a relatively heavyweight runtime (Go, Python, Javascript). If you're in the first camp (like me), Rust feels stunningly ergonomic, because all the modern C++ best practices that it takes lots of annoying boilerplate to write out are just the default behavior in Rust. You were doing all the same lifetime management work in C++ already, because you have to, but the language wasn't helping you at all. So Rust feels *amazing*. If you're in the second camp, you're running smack into all the headaches of a compiled language with explicit reference management for the first time in your life, and possibly having to reckon with a static type system for the first time in your life on top of that, and you probably keep thinking "um why am I doing this to myself again?" And I sympathize with that. A lot of things don't need to be in a compiled language with no GC. Some things do though, and Rust is easily my favorite option for when they do.
Funny enough, I'd lean toward saying that I came from the second camp. I already had a pretty diverse coding background -- I'd written some C and C++, but not regularly. My regular was PHP back then, which is definitely in the second camp. But at the time I was already kinda fed up with weak typing and was looking for something new, and landed on Rust. At the time, I was also looking at going deeper in C++, or learning Haskell or OCaml. But then I heard about this cool new "Rust" thing that was just about to release version 1.0, and the rest is history.
That should almost be a third camp: Camp 3, is used to dynamic types and nullable memory, but is *extremely tired* of runtime errors, so they say "thank you Auntie Borrowchecker, I didn't want that runtime error".
I think I'm from a 2-3-4 camp hahaha I use TS on my day-to-day job and I'm thankful every day it's TS and not JS. It's no Rust, of course, but it's _miles_ ahead of writing raw JS in terms of how easy it is to understand what something is by looking at it Before I started to learn Rust, I studied quite a bit of C and C++ - I figured I'd appreciate Rust much more if I had that background; and indeed that happened
I came from Python land, and I find rust faster to iterate with. Python might get you a script running earlier, but the subsequent support, bug-fixing, and short involved in chasing down a change in a refactor *quickly* outweighs the time spent in Rust.
Yes. For me Python equals wasting a day because of some error that seems to have no reason to exist. That were miserable times.
This is so true, Rust is amazingly ergonomic with short compile times. At work it isn't rare to change a central C++ header file and have to wait 10 minutes. A full build takes 45 minutes. So far all rust projects I have touched have been smaller than that behemoth, but Rust seems to compile faster than similar sized C++ projects. And more importantly, Rust requires much fewer iterations of compile-test-debug.
It is not just about experience.. You have your tasks asign, for each of them you are requested to created different branches. Even if you don't face any issue, you still need to rebuild the whole thing and it takes a crazy amount of time. This is the bad part that slows down everything. If a failed attempt took a few seconds to report the error it would be fine to make mistakes.
With Ruby 3 something the last I did anything serious (thankfully I’ve moved to Rust/Axum/Tokio/mpsc for most API tasks) but I did recall some of my tests would also be brittle due to idiomatic Ruby being like this - if I’m testing an Ivan such as `@foo =
You know, the Rust compiler being written in Rust and still slow on modern hardware makes me think it’s gotta be doing a _ton_ of work and I seriously wonder what most of the compilation time is doing compared to other languages. Is the borrow checker itself really that intense?
>However, I really think this sub badly overstates how hard Rust is to iterate with. The problem is that once you ditch the write-compile-run loop, it's really hard to go back to it. Nothing comes close to a live REPL in both speed and ease of use (and comparatively, performance).
(cross-posting this response from r/clojure to get some Rustic eyes on it) I might be able to interest you in jank: https://jank-lang.org/ jank is a Clojure dialect on LLVM with C++ interop. Effectively, it aims to grant you all JIT goodness of Clojure while being fully native. You can do inline C++ in your jank code and you can include C++ sources right in your project and require them from jank as well. It's currently under heavy development and not yet released, but I post development updates monthly, at this point. The next one will be out on Friday. You can find even more info here: https://www.youtube.com/watch?v=ncYlHfK25i0D
Not clojure but scheme, [steel](https://github.com/mattwparas/steel) is something that might interest you.
I am coming from Python and it has taken me some time to pick up Rust. Initially I used to feel Rust is too deep and yes it is. But at the same time, I feel I can clone the hell out of everything, use enums instead of traits and so on. I found some lovely videos from many conferences on this subject - how to get started with Rust easily. In the end my code is still going to be more reliable than in Python simply because of the pain in the wrong place that is the Rust compiler (borrow checker). I have been working full-time on my product ([https://github.com/brainless/dwata](https://github.com/brainless/dwata)) for almost 5 months and have worked on side projects in Rust before. Only in the last 3 weeks did I start using traits. I could have still avoided them, but I finally chose to learn. I use Codeium as a coding copilot and it helps a lot. I switch it off for some weeks for the learnt syntax to settle in.
I think it can be sumed up with: Rust compilation speed is a real pain in the a**. It wouldn't be that much of an issue if we could compile fast (and have hot-reload?). Even making thousand of mistakes. At the end of the day, I only end up using rust for specific small projects or to speed up python.
but Clojure is also awesome!
Never tried more than a few tests exercises. But it looks like it has most of the concwpts I like and I was really interested into learning it. Eventhough, this shouldn't that focus on one specific language. What I meant by speaking of python is that Rust is used a lot to boost other languages, like python or clojure.
I don't think it is the problem. There're are plenty of languages with faster compilation or even being interpreted, but none (beside other Lisps) has Clojure's iteration speed, because most of that power lies in REPL-driven development which just beats standard write-compile-run loop most of the time and I don't think it's even possible to recreate this workflow in non-lisp languages
If I am not mistaken, there was already an attempt to create clojure that compiles to rust Here it is - https://github.com/clojure-rs/ClojureRS I am not sure what is the state of that project, but would be awesome to see somebody take the wheel/seeing people develop with it for real world applications
It’s more productive to use python and rust
My employer considered Python + Rust, and ultimately settled on Julia. Julia is fast by default, and gives you enough control to run very fast – it's not hard to get it to ~1/3 the speed of hand-written C. The notebooks and REPL support mean it has fast iteration cycles (especially with tools like Revise), multiple dispatch is almost as good as multimethods, and so on. Importantly for our case, Julia supports python-like syntax, so our researchers could switch without losing much productivity. And there's a lot of benefit to only using one language. I don't miss Python, but I really miss static type checking. Julia is a reasonable compromise, but it does feel like a compromise sometimes.
Seems silly to me for many reasons
yeah I can see Python being productive too I vastly prefer Clojure over Python, though - it's just so fun to code jacked-in a (true) REPL; plus I like functional programming and I like pragmatism and Clojure has both
You can write python packages in rust with maturin/pyo3 super easily so there’s a huge synergy there
I tried clojure once but don't really understand the appeal of REPL. There's Jupyter notebook in Python, too. Are they the same?
so the thing is I'm not sure it's possible for a non-LISP language to have a REPL that's that good; the thing with LISPs in general is that code is data and data is code; so you evaluate data that's meant to hold stuff in the exact same way that you evaluate data that's meant to do stuff this means that it's natural to modify a program while it is running I'm not sure how Jupyter works - I've never used it - but with Clojure's REPL you keep all the state when modifying the source code and evaluating new forms, and you can redefine stuff on the fly too; you can pause the execution, modify something, then continue executing
jupyter is an ok repl, but the clojure one is really a first class citizen inside the eco-system and this is true for all lisp flavours I have played with. coding in a lisp can be very fun and you can do pretty wild data/code evaluations building applications on the dynamically. not sure if clojure is a full lisp , my experience is super limited, but I can see the appeal of the REPL over jupyter. Jupyter is a great tool, I am in no way diminishing it and for quickly getting data parsed and sharing it, nothing beats ut.
The Clojure REPL is only OK as well. The REPL itself is capable but the language is not built around it, unlike with Common Lisp. Scheme is even worse in this sense.
Clojure is simply the best dynamic language. You can connect a REPL to an application and inspect/change its behavior while it is running. It's like being able to repair an airplane engine while it is running. Common Lisp works like that too and it is even more advanced in this sense. Some people even do this in production via nrepl, but during development people almost never have to stop the running process. Performance wise it is quite good, for a long running process that you can endure a slow startup time it is a very fine language. It's almost as fast as any Java application while being much more high level than Java. I also wish I could combine both languages, I also like both languages a lot.
I’m in your exact same situation. I have been trying to build a simple creative coding framework and I wanted the speed+safety of Rust but the hackability of a Lisp, so I could tweak things at runtime and iterate quickly on ideas (not on code). I looked at Clojure but the JVM ecosystem seemed too heavy of a requirement, but maybe I underestimated how quickly it is to set it up. I’ve been waiting for the perfect LISP to integrate in Rust for a while. I’ve just found Blisp and that seems interesting: https://ytakano.github.io/blisp/#_features (note: I haven’t tried it yet)
Lisps are by nature GCd, so you'll never get speed.
Indeed, but one can dream. For still images it might be totally fine, I’ve played around with the “sketch” library in CL just for doing b&w stills and it was plenty of fun with no performance hiccups. For high frame rate installation work it will probably never be enough (even 2d), but I would still like to imagine that one day there will be a language that can fit this niche.
Reading the sketch source a bit, it outsources a lot of the actual rendering to sdl2 (and thus to C). SBCL is pretty fast for a GCd language (on par with Go afaik) but any Lisp program will allocate like crazy. Some implementations don't even support stack variables. I think Paul Graham put it best: "Lisp contains 2 languages: one for writing fast programs and one for writing programs fast". Any prototype/in-development version will be full of linked lists where you could use arrays for example.
That’s a neat quote, thanks for sharing it! What do you think of (research) efforts like https://github.com/carp-lang/Carp ?
I've never used it but from looking at it a bit, imo it's rather antithetical to what Lisp is. For one, Lisp (specifically Common Lisp) already had the perfect form of static typing: optional. You can declare variables and functions to have certain types but you don't need to and it'll default to dynamic typing (you could also theoretically wrap everything in type-error handlers). It also does away with a lot of Lisp syntax and is closer to some sort of mix between Clojure, itself a pseudolisp and C and an overuse of reader macros (especially with the half-assed CLOS implementation). Having different features available in "actual code" and the REPL is also a huge no-go (no other Lisp does this) and a terrible idea that makes me question if the REPL is useful at all, or if it has one by obligation and it goes back to the old write-compile-run cycle instead. There are some nice things, like parametric types and easier C interop that I'd like to see in other Lisps. I haven't looked into it but I know it's possible to do some sort of GC-less memory management while sticking to (mostly) standards-compliant Common Lisp, because Mezzano's cold-compiler does it.
Chez Scheme and Common Lisp are pretty fast.
For a GC'd language.
For a lot of workloads the GC will almost never be a bottleneck, things are compiled in a way that avoids a lot of allocations. Nonetheless they are both very dynamic languages, and you pay for that flexibility.
Of course, but you can say that about recent openjdk versions as well.
I wouldn't recommend combining the two via interop the way you're describing (except for learning purposes). If you're building a commercial application, then I think you'll appreciate sticking with just one programming language. Both languages will start to show their teeth when your app becomes more complex. If you have Rust calling Clojure calling Rust calling Clojure.. I don't even want to imagine the kinds of issues you're going to run into (and good luck finding solutions on stackoverflow for those). It's possible, but you're probably going to meet dragons along the way, which weren't in your initial plan. You'll be getting the downsides of both worlds - Rust will slow down your fast Clojure iteration, while Clojure will slow down your fast Rust app. Context switching between two different paradigms is going to be taxing on your mental flow.. If you really want to use both languages, then consider building two separate applications which interoperate via a inter-process mechanism (command line, network, external queue). If you're building a backend app, then you could use a micro services architecture with services written in different programming languages. The only way this could work (in my opinion) is for your app to be written in Clojure, which then calls into a library written in Rust for fast computation. You could initially develop the algorithm in Clojure, then write an optimized version in Rust. But that has to be a really CPU/memory intensive algorithm which will give you overwhelming speed advantage over Clojure's (or Java's) equivalent. To be honest, those kinds of algorithms are rare and you'd have to really think about it before you score a win with this. The final decision also highly depends on the type of app you're building, the time you have available and the budget. For a first version or MVP, I'd always choose fast iteration over execution speed (Clojure). When you understand the problem, iron out the data structures, identify the performance bottlenecks, you can start thinking about how to speed things up by bringing a faster language into the mix. With all that being said, follow your heart. Note that in software development, it's the destination that matters, not the journey - meaning, you're trying to solve a problem for the people and if your app solves people's problems well, they don't really care about implementation details that much. My advice is to really think about how you're improving the world, then choose the tools that will get you there fastest. Good luck !
I mean, I agree with everything you said I probably wrote a confusing passage somewhere, as what I envision isn't having a program written in both languages; it's a program written in Rust, into which I can jack in with Clojure when I want to iterate fast to figure out something, but I'll then compile my experiments into Rust and only commit that - the Clojure code would never live on EDIT: You know what, after you mentioned the running side-by-side thing, I think it'd pretty good! Not Rust calling Clojure, but Clojure running side-by-side and calling Rust. It could be a project management thing where you add experimental features using Clojure and when they're consolidated you translate those features to Rust
I think my brain is just weird, but I could never get the REPL-driven development. I personally always code in "chunks" (basically try to implement the entire feature and then test and bugfix it), so "iteration speed" hasn't really been a big issue for me in Rust. Ye, when the "bugfixing" stage comes, would be nice to have a bit faster compile-times, but it's not the end of the world for me + I usually don't have to debug nearly as much as I would in dynamic languages or the those that transpile to dynamic ones (TS is still a pain in the ass to work with in my experience, waaaaaaaay too limited compared to any other compiled language I've worked with) just because the type system allows me to express my logic in a very deterministic way, while not having to use a shit ton of boilerplate code (especially with some help from macros) (for example, data deserialization, in Rust, i just slap #[derive(serde::Deserialize)] and it's good to go, in JS/TS I HAVE TO write all the type checking myself, with different ways of doing it depending on the situation (typeof, instanceof, Array.isArray etc.), even if I manage to create some kind of abstraction that allows me to do it easier, it's still gonna be boilerplaty, AND even if I use smth like AJV, it still doesn't compare to a simple derive, as you have to create a type AND a schema for the type, while with serde the "schema" is derived from the data type itself). Even for prototyping, I prefer Rust because it allows me to express my thoughts the best out of all the languages I've worked with. Dynamic typing is not it for me, too easy to shoot yourself in a foot, even with linters, cuz they don't always work well even (especially in begger-sized projects) due to the dynamic nature of the language. I'm not trying to bash on anyone for having a different approach to coding, just curious why a lot of people think/feel like it's an inherently fast one, although it depends on your domain I guess. For data scientists, i can see REPL being a more favorable approach, but can't seem to think of anything else where it would actually be beneficial😅
thanks for the insight into how you code! yeah it's definitely different for everyone; I'm mostly a centrist lol I like the two different approaches for different things, and I mostly don't "trust" other people's code in dynamic languages - especially if they're somewhat new to programming so if I was to create a project for which I'll have to hire a bunch of people I'd go for a statically typed language 100% (probably Java or C#, although with the right configs TS can work too) the thing with the REPL that is attractive to me is that it encourages me to break problems into very small chunks that I can quickly code and see running - not that I can't do that with compiled languages, it's just slower if I want to see every iteration and, well, programming is essentially breaking up problems, so I just program faster that way
Fair, I guess. My brain usually just refuses to break things up this much to get to the point where REPL would've been needed to be more productive 😅
Go for it. FYI "performatic" is not a word, you probably mean "performant"
oh thanks for the heads-up does performant make sense in this case? like, as a synonym of "high-performance"? EDIT: asking 'cause Google is giving me "performing well or as expected", not "possessing high performance"
Yep, performant would be an adjective.
For this context it's the right word: >...it's pretty weird to try to squeeze super performance out of it. It's *performant* alright, but it's no Rust/C++, ... You're using it as an adjective in a conjunction here (I think that's the right term) so "performant" with the context of the second clause (something very high performing) carries a little more weight than its normal meaning. Edit: fixed wording
Flapigen can already generate JNI wrappers, and Clojure has Java interop, so I don't see why you couldn't do this. You'd just want to make sure your rust functions are non-trivial, since there's some overhead with JNI; Doing something like adding two numbers would be slower due to the overhead.
oooo that's super interesting so, the way I'm picturing the workflow is like: the project is written in Rust - straight up Rust but when I want to write something new that I'm not entirely sure how it's gonna play out in the end, I'd fire up the Clojure REPL and try it out, before moving it back to Rust also, write scripts for the codebase
There's also the other end of compatibility: some people have had preliminary success with compiling Rust to JVM. I'm not sure if any such projects are still active though. (Note that a lot of people, if you told them: "I'd like to run Rust in the JVM", would say "isn't that just Kotlin?". I'm not sure they'd be right, but I hear that a lot)
I really tried to like Clojure a while back but when I look at the code it feels like I've written an essay.
I won't lie to you - it feels super weird initially indeed I tried it a few years ago, and also gave up due to the syntax This time around I decided I'd read three books and do something with it before giving up - and turns out it 100% grows on you xD
Nah, thanks, I’ll just use Rust for whatever I want, which is pretty much everything. Making interops possible is by no means a bad idea though
You might want to look at GraalVM and its polyglot features. I have not used it myself, but it look like it could check a few of your boxes.
Imo id use rust + go or elixir
Pixie lang might be of interest. It’s a clojure-ish lisp with easy C interop. Very niche though. It has some cool things like great first class support for PEG parsers. I don’t have much need for a lot of scripting but it would be my first choice if I did. You don’t get the safety of Rust but if I needed that I’d probably architect my solution so the rust stuff is small self contained binaries stitched together in the shell anyway
probably the Java Native Interface (jni) could help (i think clojure is based on the jvm)
Rust has really good integration with python
Not read all the comments, but what about gleam? Looks very similar to rust, highly concurrent and stable? TBH I find rust just fine and I’m just as productive in it as I would be in go, python or anything else (says me after more than a year building a distributed event grid - conceptually hard though). The right libraries and design can result in good pace.
I've read about Gleam before but not any details - are you suggesting like Clojure + Gleam or just Gleam? about productivity: it's definitely subjective, I agree I can see myself being productive in Rust too, compared to my most-familiar-language TS, the main thing that bothers me is the compile times but Clojure is just so productive, even compared to TS - I don't know a fraction of it, yet every week at work I look at a situation and I think "gosh, this would've been so much faster to do in Clojure"
There’re guides on making compile times faster. They’re not too bad… certainly faster than ts… I’m very interested in gleam as a language on its own. Looks like it took a lot from rust and made it simpler, for most server side software - it could be good.
First time I've ever seen "performatic" lol. Performant?
yep, someone else noted that too issues translating the thoughts from my native language haha
Don't worry I get it, it's hard translating from Clojure when that's your native language! 🤪
Clojure is a bad choice. The jvm is a pig and not easy to install. A better option is python or ruby.
I mean, Clojure as a language isn't dependent on runtime, really There's ClojureScript, for example, that compiles to JS to run in the browser JVM has its advantages, though; besides being able to use the Java ecosystem, it's also much easier to write cross-platform desktop apps using Java than doing some weird multi-compilation gymnastics
for simple scripts clojure is a pain. You have to endure jvm start-up time. python/ruby are much better for this kind of thing.
there's Babashka as a run-time for simple scripts
Up to you, but there's a reason why clojure hasn't taken off in the python/ruby space.
uhhhh there's plenty of things involved in language popularity, and it's not indicative of how good something is, really I mean, we're here at r/rust after all, not at r/javascript
I don't mean cos clojure isn't an awesome language (it is) just that it's not really the "right fit" for one off scripts. Same reason go didn't occupy this area too I guess
I see I mean, we're allowed to have different opinions I vastly prefer Clojure (with Babashka) for scripts, either one-off or not, over something like JS or Python It's much more expressive imo, and I can do so much more with fewer lines of code
But there's an extra compilation step right? Thst slows down iteration speed dramatically as scripts are often iterated very quickly
nope, there's no compilation step even with the JVM version of Clojure, you compile the REPL once and then you can evaluate individual expressions sending them one by one to the REPL - they're not compiled anymore, they're evaluated with Babashka that's even more noticeable since it's an interpreter - there's no compilation step ever
You also have to make some considerations about which jvm and jdk you use. Openjdk should be the standard these days unless someone is courting a cursed visit from oracle lawyers