as of January 2025, I’ll have quit my job at Electronic Arts to focus on jank full-time
Fun fact: Jeaye will become the second known Lobster to have left EA and started a programming language project of some sort, after @andyc! I say, keep ’em coming ;)
I’m a big fan of all of Rich Hickey’s talks, which definitely influenced my thinking about languages and programming. But I was never a JVM user, because of what I worked on, and because it isn’t very “Unix-y” . So I never used Clojure much
So Jank sounds very interesting! Anything that mixes interactive development and native code speed is interesting to me. I feel like that line of thought is a bit “forgotten”.
(I also want to ask for UTF-8 strings rather than UTF-16 strings, which the JVM has :) That may break things, but there are some ideas to paper over that problem - https://lobste.rs/s/i1rxgb/requiem_for_stringref )
Agreed, Rich (and Clojure) have changed the way I think about programming.
Anything that mixes interactive development and native code speed is interesting to me. I feel like that line of thought is a bit “forgotten”.
For sure. jank programs won’t be like hand-written C++ or Rust, since jank/Clojure is still such a dynamic, polymorphic runtime. That means there’s a great deal of figuring out the types of things at runtime and boxing values so that they can fit anywhere. Normal native code doesn’t do this. But it’ll be far lighter than the JVM, with faster startup time, and competitive run-time performance, even compared to Hotspot optimizations (based on the small benchmarks I’ve done so far – larger ones to come).
I also want to ask for UTF-8 strings rather than UTF-16 strings
Game dev was all done on Windows, except the PS2 dev kit was a PS2 with a Linux machine inside. Once in a blue moon, you would need to SSH to that machine, and then I encountered Vim :)
I left EA in December 2004, and I didn’t start Oils until after my second job, in 2016. I have been working on Oils for 8 years, not 20 :-) Thanks to everyone who has contributed, including many from lobste.rs!
Another funny thing is that Bob Nystrom of https://craftinginterpreters.com/ worked at EA in Florida, then Google in Seattle. I worked at both companies in the Bay Area, at about the same times. We have never met, but we even had literally the same team-mate, who worked in both offices, … (I have been meaning to write a dev guide “Oils vs. Crafting Intepreters”, because the internals are very similar, just “scaled up”.)
Typed Clojure will need some reader conditionals to support jank’s interop wherever it’s currently doing Java interop, but since Typed Clojure also works for ClojureScript, hooking that in should be trivial (since those reader conditionals are already there). Once jank is launched to production (aiming for mid-late 2025), I’ll be jumping into all of the common libs to add jank support into their cljc files.
I’ll be jumping into all of the common libs to add jank support into their cljc files.
That is really exciting! My passion project is a CMS in Clojure that I want the option to ship as a native binary. Graal is workable, but feels like overkill, and compilation times are abysmal. I know it’s a long way off, but looking forward to the day I can ditch it!
My biggest annoyance with Clojure always has been JVM and its startup times. It always felt like everything was unbearably slow (even though all the Clojure people would insist that it wasn’t so).
Now I’ve come to like Factor which is a lot like Clojure but without the parenthesis hell.
This brings fond memories of my Clojure-on-Ruby from ~2010. I was a bit too young and green to pull it off like you’re doing here; really nicely done. :)
Haha, thank you! It got far enough to make it into a book (!), I would learn years later. It was fun and Ruby was a good fit. Not much left of it now, but the wayback machine preserved a version of the website, sans styles.
sounds like Jank will be intimately bound to LLVM. won’t this affect stability and induce a lot of churn on developers? I would imagine that a language excessively bound to any specific implementation detail would get issues like this.
As andyc said in a sibling comment, the coupling to LLVM will largely affect people working on the jank compiler/runtime, not the end users. Overall, I think that LLVM remains the best bet out there for new projects. If I outgrow it, like Zig did, fair enough, but there’s a huge amount of tooling I’m able to use from LLVM that enables the whole JIT compilation/interactive development workflows which Clojure demands.
Fun fact: Jeaye will become the second known Lobster to have left EA and started a programming language project of some sort, after @andyc! I say, keep ’em coming ;)
Oh, that’s neat! Just looked it up. I’ve seen Oils floating around, but didn’t know Andy was also coming from EA. :D
I’m a big fan of all of Rich Hickey’s talks, which definitely influenced my thinking about languages and programming. But I was never a JVM user, because of what I worked on, and because it isn’t very “Unix-y” . So I never used Clojure much
So Jank sounds very interesting! Anything that mixes interactive development and native code speed is interesting to me. I feel like that line of thought is a bit “forgotten”.
(I also want to ask for UTF-8 strings rather than UTF-16 strings, which the JVM has :) That may break things, but there are some ideas to paper over that problem - https://lobste.rs/s/i1rxgb/requiem_for_stringref )
Agreed, Rich (and Clojure) have changed the way I think about programming.
For sure. jank programs won’t be like hand-written C++ or Rust, since jank/Clojure is still such a dynamic, polymorphic runtime. That means there’s a great deal of figuring out the types of things at runtime and boxing values so that they can fit anywhere. Normal native code doesn’t do this. But it’ll be far lighter than the JVM, with faster startup time, and competitive run-time performance, even compared to Hotspot optimizations (based on the small benchmarks I’ve done so far – larger ones to come).
jank has UTF-8 strings! The string type is quite competitive, compared to std::string and folly::FBString. https://lobste.rs/s/utauhe/jank_s_new_persistent_string_is_fast
A funny thing I remember from EA is that I touched Unix for the first time, and I had to ask one of my coworkers how to quit Vim (
:q).Just like the memes - https://stackoverflow.blog/2017/05/23/stack-overflow-helping-one-million-developers-exit-vim/
Game dev was all done on Windows, except the PS2 dev kit was a PS2 with a Linux machine inside. Once in a blue moon, you would need to SSH to that machine, and then I encountered Vim :)
I left EA in December 2004, and I didn’t start Oils until after my second job, in 2016. I have been working on Oils for 8 years, not 20 :-) Thanks to everyone who has contributed, including many from lobste.rs!
Another funny thing is that Bob Nystrom of https://craftinginterpreters.com/ worked at EA in Florida, then Google in Seattle. I worked at both companies in the Bay Area, at about the same times. We have never met, but we even had literally the same team-mate, who worked in both offices, … (I have been meaning to write a dev guide “Oils vs. Crafting Intepreters”, because the internals are very similar, just “scaled up”.)
Of course, sorry if I suggested otherwise!
That was a little joke – making a programming language takes a long time :-) Making 3 takes even longer!
I’m happy with Clojure on the JVM, but I’m excited about where this is heading.
Can it work with typed Clojure? Lack of types is my biggest hesitation
Typed Clojure will need some reader conditionals to support jank’s interop wherever it’s currently doing Java interop, but since Typed Clojure also works for ClojureScript, hooking that in should be trivial (since those reader conditionals are already there). Once jank is launched to production (aiming for mid-late 2025), I’ll be jumping into all of the common libs to add jank support into their cljc files.
That is really exciting! My passion project is a CMS in Clojure that I want the option to ship as a native binary. Graal is workable, but feels like overkill, and compilation times are abysmal. I know it’s a long way off, but looking forward to the day I can ditch it!
My biggest annoyance with Clojure always has been JVM and its startup times. It always felt like everything was unbearably slow (even though all the Clojure people would insist that it wasn’t so).
Now I’ve come to like Factor which is a lot like Clojure but without the parenthesis hell.
This brings fond memories of my Clojure-on-Ruby from ~2010. I was a bit too young and green to pull it off like you’re doing here; really nicely done. :)
We need a good Clojure-on-Ruby. You were onto something! :)
Haha, thank you! It got far enough to make it into a book (!), I would learn years later. It was fun and Ruby was a good fit. Not much left of it now, but the wayback machine preserved a version of the website, sans styles.
However robust a language this becomes, I fear it will never live down the jank-y name.
Naming is hard. This is not the way. I could be proved wrong, carry on ;-)
sounds like Jank will be intimately bound to LLVM. won’t this affect stability and induce a lot of churn on developers? I would imagine that a language excessively bound to any specific implementation detail would get issues like this.
Why would it be any different than Rust, Swift, Julia, and I think Zig, etc.?
From what I hear, it is not always pleasant to upgrade for the devs, but it’s stable for end users
As andyc said in a sibling comment, the coupling to LLVM will largely affect people working on the jank compiler/runtime, not the end users. Overall, I think that LLVM remains the best bet out there for new projects. If I outgrow it, like Zig did, fair enough, but there’s a huge amount of tooling I’m able to use from LLVM that enables the whole JIT compilation/interactive development workflows which Clojure demands.