8 ms·

From C++ to Clojure: Jank language promises best of both

259 points by Jeaye 2y ago

Tcepsa 2y ago
As a long-time fan of Clojure (I've been using it to varying degrees since 2008 and it is my favorite programming language) I'm really excited about the interpretability it sounds like this will open up!!
dang 2y ago
Related. Others? I quit my job to work on my programming language - https://news.ycombinator.com/item?id=42658898 https://news.ycombinator.com/item?id=42658898 - Jan 2025 (32 comments) Jank: Programming Language - https://news.ycombinator.com/item?id=42477992 https://news.ycombinator.com/item?id=42477992 - Dec 2024 (3 comments) Jank is now running on LLVM IR - https://news.ycombinator.com/item?id=42276672 https://news.ycombinator.com/item?id=42276672 - Nov 2024 (16 comments) Jank development update – Moving to LLVM IR - https://news.ycombinator.com/item?id=41845669 https://news.ycombinator.com/item?id=41845669 - Oct 2024 (49 comments) The Jank Language: LLVM Hosted Clojure - https://news.ycombinator.com/item?id=32493217 https://news.ycombinator.com/item?id=32493217 - Aug 2022 (79 comments)
tombert 2y ago
I'm not super familiar with this project, so forgive a bit of ignorance on this; what does this buy you over vanilla Clojure and native-image compiling with GraalVM. This is a genuine question, not meant to dismiss the project! ETA: Sorry, further down the article answered my question: > “jank is also a good fit for any Clojure devs who want a lighter runtime without sacrificing JIT compilation, as they would if they used a Graal native image, or if they want easy access to native libraries for whatever reason.”
- joeevans1000 2y ago
  You can compile a native program. Not one that requires the JVM. And it also interops with a number of more native graphical tools (as opposed to having other use things that require/work-from java). To those coming to this thread who might not be familiar with Clojure: Clojure already can sit on top of javascript (as Clojurescript) and there was work making it work on top of, if I recall right, some of the C languages. But those latter ones don't seem to be anywhere near the capabilities of this project.
- Jeaye 2y ago
  The two biggest things are: 1. You get a native binary without sacrificing interactive programming. With a Graal native image, all of that goes away. With jank, you can still REPL in, change things, JIT compile code, etc. 2. You get Clojure -> JVM level of seamless interop from jank -> C++. I am pretty darn sure that this will be unprecedented, given the challenges of the native space (no standard reflection, differing ABIs, C++ templates, etc). Aside from that, jank is making some huge quality of life improvements over Clojure JVM. I've shared some of this already, but I'll have a post coming out EOQ which will demonstrate the difference in compiler errors between the two. It's night and day.
  - tombert 2y ago
    I'm looking forward to it; being able to utilize C and C++ libraries directly from Clojure is something that I could see being pretty valuable. I've been debating trying my hand at making a simple game engine...it would be great if I could use a Lisp to do it.
    - lelanthran 2y ago
      You can use lisp with almost native C support, if you use ecl or gcl.
      - guenthert 2y ago
        ecl and gcl compile to C. That's fine, but not necessary to merely use C libraries; for that you need a C foreign function interface (FFI), which most surviving CL compilers offer. C++ is more of a challenge, hence the Clasp project.
        beepbooptheory 2y ago
        I feel like Clasp has huge game development potential but has gravitated towards science just because that's where it came from. Like surely one could use it to get good godot bindings for example, but I haven't seen stuff like that around.
upghost 2y ago
Curious what the story is for slotting Jank into gaming. Seems like a fit for Unreal, but I really love the Component-Based-Architecture of Unity. Would you get it into your Unity project the same was as getting normal C++ into your project?
- Jeaye 2y ago
  jank can embed into any native program like lua would. But it the offers seamless interop back into C++, including the ability to instantiate new templates. So, anywhere lua is being embedded, jank could be used while providing a tighter integration to C++, interactive dev with a REPL, and proper lisp macros.
  - 2mlWQbCK 2y ago
    A good alternative for game engines where Lua has literally already been embedded is to use Fennel, a LISP that borrows some Clojure-like syntax and that compiles to Lua-code. In some cases it should be possible, like for Löve 2D, to include a few lines of boilerplate Lua code to load Fennel-files on the fly. Elsewhere you probably have to pre-compile to Lua. https://fennel-lang.org/ https://fennel-lang.org/
    - iLemming 2y ago
      Fennel is fucking dope, I love it. It feels Clojuresque, yet, it still is more like "Lispy Lua" than Clojure. I don't know enough about compilers and building a language, but to me it feels like the design of Fennel was more accidental and the main goal was to sustain "virtually zero overhead" to run on Lua, not to bring the best ideas from Clojure. Jeaye, in contrast, seems to be taking a more deliberate approach in designing the language, not only taking the best ideas from Clojure but also trying to improve upon them.
joeevans1000 2y ago
This. Is. Awesome. Please keep moving forward with it. If it works well it will be a total game changer.
troad 2y ago
I'm very excited for Jank, I wish the creator well. If I could make one tiny plea, it would be to focus on tooling too, and ensuring the experience for someone trying Jank out is as smooth as possible. Don't assume everyone is already set up with paredit and can fire off emacs chords without a thought. I suspect that Jank will be of particular interest to C++ programmers, many of whom are used to a very different dev paradigm. The Clojure community has done a great job at trying to smooth out the rough edges of Lisp tooling, and ensure there are on-ramps for newcomers (e.g. things like Calva for VS Code). I hope Jank keeps this up, because those first impressions really do matter. I'd hate to watch people bounce off Jank because they get stuck on trying to figure emacs out, or because they get frustrated trying to keep parentheses matched in Notepad.
- roenxi 2y ago
  This seems like an opportunity to plug the good work https://www.clojuriststogether.org/ https://www.clojuriststogether.org/ do. They do good work. Plug concludes. Clojure - like many languages - seems to be benefiting a lot from the work the IDE people have been putting in to good infrastructure. A lot of the magic is being moved out of Emacs towards tools like Treesitter and the LSP server which are more platform independent. Not a huge amount to do with Clojure per say, but the Clojure ecosystem is benefiting a lot from it. The Emacs specific stuff is becoming very Emacs-specific (like paraedit, bless its socks).
  - diggan 2y ago
    I think Clojure has benefit way more from nRepl and everything in that ecosystem, than LSP and that newfangled stuff, at least my personal setup relies on nRepl and doesn't even use LSP afaik.
  - waffletower 2y ago
    I am wary of LSP. I should try LSP again using eastwood, which probably has its trade-offs. While I absolutely admire Borkdude's many gifts to the Clojure community, the lack of static analysis in clj-kondo is a non-starter for me -- macro support is painfully manual. Because of its speed, clj-kondo likely is more performant in an editor LSP context, but too opinionated for me.
deleted 2y ago
[deleted]
zem 2y ago
super excited about the potential for native gui apps
vmsp 2y ago
Looks similar to Clasp but implements Clojure instead of Common Lisp. https://clasp-developers.github.io/ https://clasp-developers.github.io/
- hatmatrix 2y ago
  Good point. When Clojure first came out it was questioned whether it's a lisp at all, but now I commonly hear many say it is the best Lisp.
- elcritch 2y ago
  The Jank creator talking with folks at CERN about integrating with their C++ codebase makes sense too. Clasp was originally used to do some molecular simulation if memory recalls.
- binary132 2y ago
  Clasp is really cool but it’s a shame that it does not support Windows properly. A lot of C++ is used on Windows. I’ve seen this pattern repeated elsewhere — I think it has to do with Windows exception handling being different and complicated. Hopefully jank does not suffer the same fate, since author is a gamedev!
- mark_l_watson 2y ago
  Cool. I tried to build Clasp from source a long while ago, and failed. Now a brew install….
VyseofArcadia 2y ago
Very excited for jank. I've been hacking together my weekend projects in Common Lisp for roughly a year. I've been wanting to look at Clojure as a modern lisp, but I want no truck with the JVM.
- cutler 2y ago
  JVM isn't the only option. There's nbb (Clojurescript for Node.js) and Babashka (Bash in Clojure). You can also use GraalVM for native compilation.
helf 2y ago
[dead]
runevault 2y ago
As someone who wants more in the space of Lisp-style languages with more interest in native, I'm going to be keeping an eye on Jank. Actually had this article recommended on my phone earlier.
systems 2y ago
My only comment, there are must nicer system programming languages that could have been host, I am mainly thinking OCaml, as for me zig would have also been nicer than C++ My main objection to C++ is that in 2025 its not a language I would want to learn or use, nothing about its inherit qualities
- Jeaye 2y ago
  I hear you! There are millions upon millions of lines of C++ in production, though. C++ is still the de facto language in game dev and many other industries. I'd choose Rust over C++ for any greenfield project, but C++ isn't going anywhere. I'm starting with C++ interop but will aim to provide interop with other native langs going forward, thanks to LLVM.
fuhsnn 2y ago
>Seamless C++ interop More detail would be appreciated, I'm not aware of any non-transpiling language that actually support full C++ RTTI/exceptions interop.
- Jeaye 2y ago
  More detail to come. You're right, it's unprecedented.
- pritambaral 2y ago
  Clasp, and implementation of Common Lisp in C++ on LLVM, has exceptions interop. The creator of Clasp even hooked up the Lisp GC to be able to automatically manage C++ objects. A compacting GC, mind, that automatically updates pointers to the managed C++ objects that it moves.
  - senkora 2y ago
    That’s pretty cool. I would love to hear more about how this works. In particular, whether it is restricted in practice to types that are std::is_trivially_relocatable. https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p1144r10.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p11...
jwr 2y ago
This is very cool and I intend to check on it from time to time. I use Clojure (and ClojureScript) all the time, and while performance on the JVM has never been an issue for me (the JVM is an impressive piece of engineering), I'm always on the lookout for new things!
j-pb 2y ago
As an ex-clojure dev that picked up Rust, I have no interest in this as long as it doesn't have ownership. Once you used lexical scoping, you're not going back to dynamic scope either, the same goes for the ability to reason about "where an object currently is" lexicographically. I think Carp (https://github.com/carp-lang/Carp https://github.com/carp-lang/Carp) is a much more interesting contender for a native clojure, simply because it has lexical ownership.
- Guthur 2y ago
  I think if you're overly using dynamic scoping in clojure you are probably doing it very wrong. I used clojure professionally for a number of years and I can't remember ever really using it.
  - mrkeen 2y ago
    Parent's not talking about dynamic scoping in clojure. It's a comparison to designed to elicit a reaction, e.g. "probably doing it very wrong". I.e. if you're not tracking ownership in new-lang, you're probably doing it very wrong.
    - j-pb 2y ago
      It's not a comparison to bash non-ownership as "very wrong", but arguing that lexical scope and ownership are literally the equivalent things. Lexical scope allows you to reason about scope on a syntactical level. Take this code: let x = 5; fn foo(): return x \* 2 fn bar(): let x = 10 return foo() fn baz(): let x = "hello world!" return foo() bar() With lexical scope, you can look at `foo` and you know immediately what it returns, the behaviour of the function is completely local to it and is a syntactical property of the program. With lexical scope you just don't know what's returned, for all you know x might not even be a number, but could be any type that just happens to be brought into scope. Ownership is similar, in that you make the existence of a value a local property. If a 'thing' is inside a variable then you can move it somewhere else, but it also means that it is no longer in that variable. And that tracking of where what is, is a syntactical property, just like with lexical scope. Clojure has software transactional memory. With ownership it wouldn't need half of the machinery (only that for rollback): let blocked_accounts = Set() let account_bob = new ExclusiveBankAccount(200) let account_alice = new ExclusiveBankAccount(600) // ExclusiveBankAccount cannot be copied or cloned fn transfer(source_acc, target_acc, ammount): if source_acc.deduce(amount.copy()): target_acc.deposit(amount.copy()) fn block(acc): let acc_identifier = acc.identifier.copy() // identifiers can be copied and are not exclusive blocked_accounts.put(acc) return acc_identifier fn unblock(acc): return blocked_accounts.take(acc) fn do_invalid_stuff(): let good_account = new ExclusiveBankAccount(200) let bad_account = new ExclusiveBankAccount(200) block(bad_account) transfer(bad_account, good_account) // <- this will fail because bad_account was moved by the block function and no longer exists here, it's invalid syntactically fn do_valid_stuff(): let good_account = new ExclusiveBankAccount(200) let bad_account = new ExclusiveBankAccount(200) let ident = block(bad_account) let restored_account = unblock(ident) transfer(restored_account, good_account, 100) The above code makes sure that: - you can only transfer funds between two accounts in a thread safe way - you can only transfer funds between accounts that are not blocked Simply by not allowing something like this on a syntactical level you get a much cleaner understanding of what your code does. After a while you're wondering why we allowed anything else in the first place. let x = thing(); let y = x; // the thing is moved from x to y here print(x) The fact that automatic memory management falls out of this is almost accidental, if you can track where a value is at any given time, you can also track the references to it, and the resources it uses. But that is not what truly makes it amazing, the fact that you can mentally think about digital objects as if they were physical objects is.
danbolt 2y ago
I really appreciate the seamless rawdogging into C++ that this language provides. It’s the sort of ambition I’m here for. Or, I find a lot of script runtimes in games have a strict boundary separating them from the native code (often for good reasons), but I wonder if we could integrate more tightly given static analysis has come a long way.
- Jeaye 2y ago
  "Seamless rawdogging into C++" is the best thing I've read in a while. ^_^ Anything less than seamless rawdogging would be neutered C++.
rcarmo 2y ago
Somehow I completely missed this. I mostly stopped using Clojure solely because of the JVM madness (yes, I know about babaskha, won’t use it due to the GraalVM dependency and possible Oracle tentacles lurking there) and have fallen back to things like Hy (which can be clunky but at least runs everywhere I have a Python interpreter). Something that has better Clojure-like syntax and uses LLVM aid very appealing, provided it can do (and serve) HTTP requests sanely and has enough batteries included. Any good pointers to existing libraries to get a feel for the ecosystem?
- bobnamob 2y ago
  As far as I'm aware, jank isn't at the point where libraries exist. It's still under initial development and doesn't implement all of Clojure just yet.
- sorry_i_lisp 2y ago
  No value judgment, what do you mean by "JVM madness"?
  - rcarmo 2y ago
    Slowness and bloat, plus the sheer dependency footprint.
    - pjmlp 2y ago
      Slower than C, C++, Rust, yeah still faster than most other alternatives, with exception of .NET. What some call bloat, others see saved effort not reinventing wheels.
barrell 2y ago
Always happy to see clojure on the front page, doubly happy to see jank! I just scoured the internet last week trying to find all the information I could on it. As a clojure(script) developer of 10 years, I still try and avoid anything JVM related. Not that I have anything against the JVM — but I never did any Java programming, and to really learn about the JVM you have to learn quite a bit about Java… which is just very low on my priority list. I have been dreaming about jank a little bit, so maybe this is a good place to ask the question, since I see the jank developer is reading the comments: would it be possible to write a module in jank that can be used in a Swift/iOS application (currently or in the future)? I assume so, but I’m not sure how accessible the outputs of jank are to other c libraries. The reason I ask is I have an offline clojurescript front end. If I want native mobile apps, that means I either have to duplicate the logic, figure out some JavaScript bridge, use react native, or use dart — none of which seem ideal. Ideally I could just extract the critical business logic into a few modules and generate the header files for swift, import directly into cljs for web, and use as regular clojure for android. Totally understandable if this isn’t a valid use case for jank, but it’s what’s captured my imagination :)
- Jeaye 2y ago
  Yes, definitely. You'll be able to use it to REPL into your phone, for development, and it'll AOT compile alongside the rest of your app for release (Apple is a stickler about JIT compilation in released apps). This, we get largely just by using LLVM.
avbanks 2y ago
Wishing you all the best! Thank you for being ambitious enough to try this out. I'm going to test this out and write about it on my blog.
oldpersonintx 2y ago
[dead]
deleted 2y ago
[deleted]
guenthert 2y ago
clojure gets robust, efficient garbage collection thanks to the JVM. What is jank's approach to memory management?
- Jeaye 2y ago
  jank is also garbage collected, since Clojure practically demands it. Currently using Boehm, a conservative GC, but we'll need to switch to something more competitive when that becomes a priority. I have my eyes on MMTK + Immix.
slifin 2y ago
I hope this works with flow storm one day
tmtvl 2y ago
Somewhat related-ish: Cakelisp <https://news.ycombinator.com/item?id=36154069 https://news.ycombinator.com/item?id=36154069>
aaronbrethorst 2y ago
How is it pronounced? Dzank or Yonk?
- Jeaye 2y ago
  j like gentleman, ank like tank
fud101 2y ago
This is dope. I cant remember the last time I got interested in a language enough to want to try it, but this passes that hurdle. I'm looking forward to the first release.

259 points by Jeaye 2y ago

As a long-time fan of Clojure (I've been using it to varying degrees since 2008 and it is my favorite programming language) I'm really excited about the interpretability it sounds like this will open up!!

dang 2y ago

Related. Others? I quit my job to work on my programming language - https://news.ycombinator.com/item?id=42658898 https://news.ycombinator.com/item?id=42658898 - Jan 2025 (32 comments) Jank: Programming Language - https://news.ycombinator.com/item?id=42477992 https://news.ycombinator.com/item?id=42477992 - Dec 2024 (3 comments) Jank is now running on LLVM IR - https://news.ycombinator.com/item?id=42276672 https://news.ycombinator.com/item?id=42276672 - Nov 2024 (16 comments) Jank development update – Moving to LLVM IR - https://news.ycombinator.com/item?id=41845669 https://news.ycombinator.com/item?id=41845669 - Oct 2024 (49 comments) The Jank Language: LLVM Hosted Clojure - https://news.ycombinator.com/item?id=32493217 https://news.ycombinator.com/item?id=32493217 - Aug 2022 (79 comments)

tombert 2y ago

I'm not super familiar with this project, so forgive a bit of ignorance on this; what does this buy you over vanilla Clojure and native-image compiling with GraalVM. This is a genuine question, not meant to dismiss the project! ETA: Sorry, further down the article answered my question: > “jank is also a good fit for any Clojure devs who want a lighter runtime without sacrificing JIT compilation, as they would if they used a Graal native image, or if they want easy access to native libraries for whatever reason.”

joeevans1000 2y ago
You can compile a native program. Not one that requires the JVM. And it also interops with a number of more native graphical tools (as opposed to having other use things that require/work-from java). To those coming to this thread who might not be familiar with Clojure: Clojure already can sit on top of javascript (as Clojurescript) and there was work making it work on top of, if I recall right, some of the C languages. But those latter ones don't seem to be anywhere near the capabilities of this project.
Jeaye 2y ago
The two biggest things are: 1. You get a native binary without sacrificing interactive programming. With a Graal native image, all of that goes away. With jank, you can still REPL in, change things, JIT compile code, etc. 2. You get Clojure -> JVM level of seamless interop from jank -> C++. I am pretty darn sure that this will be unprecedented, given the challenges of the native space (no standard reflection, differing ABIs, C++ templates, etc). Aside from that, jank is making some huge quality of life improvements over Clojure JVM. I've shared some of this already, but I'll have a post coming out EOQ which will demonstrate the difference in compiler errors between the two. It's night and day.
- tombert 2y ago
  I'm looking forward to it; being able to utilize C and C++ libraries directly from Clojure is something that I could see being pretty valuable. I've been debating trying my hand at making a simple game engine...it would be great if I could use a Lisp to do it.
  - lelanthran 2y ago
    You can use lisp with almost native C support, if you use ecl or gcl.
    - guenthert 2y ago
      ecl and gcl compile to C. That's fine, but not necessary to merely use C libraries; for that you need a C foreign function interface (FFI), which most surviving CL compilers offer. C++ is more of a challenge, hence the Clasp project.
      - beepbooptheory 2y ago
        I feel like Clasp has huge game development potential but has gravitated towards science just because that's where it came from. Like surely one could use it to get good godot bindings for example, but I haven't seen stuff like that around.

upghost 2y ago

Curious what the story is for slotting Jank into gaming. Seems like a fit for Unreal, but I really love the Component-Based-Architecture of Unity. Would you get it into your Unity project the same was as getting normal C++ into your project?

Jeaye 2y ago
jank can embed into any native program like lua would. But it the offers seamless interop back into C++, including the ability to instantiate new templates. So, anywhere lua is being embedded, jank could be used while providing a tighter integration to C++, interactive dev with a REPL, and proper lisp macros.
- 2mlWQbCK 2y ago
  A good alternative for game engines where Lua has literally already been embedded is to use Fennel, a LISP that borrows some Clojure-like syntax and that compiles to Lua-code. In some cases it should be possible, like for Löve 2D, to include a few lines of boilerplate Lua code to load Fennel-files on the fly. Elsewhere you probably have to pre-compile to Lua. https://fennel-lang.org/ https://fennel-lang.org/
  - iLemming 2y ago
    Fennel is fucking dope, I love it. It feels Clojuresque, yet, it still is more like "Lispy Lua" than Clojure. I don't know enough about compilers and building a language, but to me it feels like the design of Fennel was more accidental and the main goal was to sustain "virtually zero overhead" to run on Lua, not to bring the best ideas from Clojure. Jeaye, in contrast, seems to be taking a more deliberate approach in designing the language, not only taking the best ideas from Clojure but also trying to improve upon them.

joeevans1000 2y ago

This. Is. Awesome. Please keep moving forward with it. If it works well it will be a total game changer.

troad 2y ago

I'm very excited for Jank, I wish the creator well. If I could make one tiny plea, it would be to focus on tooling too, and ensuring the experience for someone trying Jank out is as smooth as possible. Don't assume everyone is already set up with paredit and can fire off emacs chords without a thought. I suspect that Jank will be of particular interest to C++ programmers, many of whom are used to a very different dev paradigm. The Clojure community has done a great job at trying to smooth out the rough edges of Lisp tooling, and ensure there are on-ramps for newcomers (e.g. things like Calva for VS Code). I hope Jank keeps this up, because those first impressions really do matter. I'd hate to watch people bounce off Jank because they get stuck on trying to figure emacs out, or because they get frustrated trying to keep parentheses matched in Notepad.

roenxi 2y ago
This seems like an opportunity to plug the good work https://www.clojuriststogether.org/ https://www.clojuriststogether.org/ do. They do good work. Plug concludes. Clojure - like many languages - seems to be benefiting a lot from the work the IDE people have been putting in to good infrastructure. A lot of the magic is being moved out of Emacs towards tools like Treesitter and the LSP server which are more platform independent. Not a huge amount to do with Clojure per say, but the Clojure ecosystem is benefiting a lot from it. The Emacs specific stuff is becoming very Emacs-specific (like paraedit, bless its socks).
- diggan 2y ago
  I think Clojure has benefit way more from nRepl and everything in that ecosystem, than LSP and that newfangled stuff, at least my personal setup relies on nRepl and doesn't even use LSP afaik.
- waffletower 2y ago
  I am wary of LSP. I should try LSP again using eastwood, which probably has its trade-offs. While I absolutely admire Borkdude's many gifts to the Clojure community, the lack of static analysis in clj-kondo is a non-starter for me -- macro support is painfully manual. Because of its speed, clj-kondo likely is more performant in an editor LSP context, but too opinionated for me.

deleted 2y ago

[deleted]

zem 2y ago

super excited about the potential for native gui apps

vmsp 2y ago

Looks similar to Clasp but implements Clojure instead of Common Lisp. https://clasp-developers.github.io/ https://clasp-developers.github.io/

hatmatrix 2y ago
Good point. When Clojure first came out it was questioned whether it's a lisp at all, but now I commonly hear many say it is the best Lisp.
elcritch 2y ago
The Jank creator talking with folks at CERN about integrating with their C++ codebase makes sense too. Clasp was originally used to do some molecular simulation if memory recalls.
binary132 2y ago
Clasp is really cool but it’s a shame that it does not support Windows properly. A lot of C++ is used on Windows. I’ve seen this pattern repeated elsewhere — I think it has to do with Windows exception handling being different and complicated. Hopefully jank does not suffer the same fate, since author is a gamedev!
mark_l_watson 2y ago
Cool. I tried to build Clasp from source a long while ago, and failed. Now a brew install….

VyseofArcadia 2y ago

Very excited for jank. I've been hacking together my weekend projects in Common Lisp for roughly a year. I've been wanting to look at Clojure as a modern lisp, but I want no truck with the JVM.

cutler 2y ago
JVM isn't the only option. There's nbb (Clojurescript for Node.js) and Babashka (Bash in Clojure). You can also use GraalVM for native compilation.

helf 2y ago

[dead]

runevault 2y ago

As someone who wants more in the space of Lisp-style languages with more interest in native, I'm going to be keeping an eye on Jank. Actually had this article recommended on my phone earlier.

systems 2y ago

My only comment, there are must nicer system programming languages that could have been host, I am mainly thinking OCaml, as for me zig would have also been nicer than C++ My main objection to C++ is that in 2025 its not a language I would want to learn or use, nothing about its inherit qualities

Jeaye 2y ago
I hear you! There are millions upon millions of lines of C++ in production, though. C++ is still the de facto language in game dev and many other industries. I'd choose Rust over C++ for any greenfield project, but C++ isn't going anywhere. I'm starting with C++ interop but will aim to provide interop with other native langs going forward, thanks to LLVM.

fuhsnn 2y ago

>Seamless C++ interop More detail would be appreciated, I'm not aware of any non-transpiling language that actually support full C++ RTTI/exceptions interop.

Jeaye 2y ago
More detail to come. You're right, it's unprecedented.
pritambaral 2y ago
Clasp, and implementation of Common Lisp in C++ on LLVM, has exceptions interop. The creator of Clasp even hooked up the Lisp GC to be able to automatically manage C++ objects. A compacting GC, mind, that automatically updates pointers to the managed C++ objects that it moves.
- senkora 2y ago
  That’s pretty cool. I would love to hear more about how this works. In particular, whether it is restricted in practice to types that are std::is_trivially_relocatable. https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p1144r10.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p11...

jwr 2y ago

This is very cool and I intend to check on it from time to time. I use Clojure (and ClojureScript) all the time, and while performance on the JVM has never been an issue for me (the JVM is an impressive piece of engineering), I'm always on the lookout for new things!

j-pb 2y ago

As an ex-clojure dev that picked up Rust, I have no interest in this as long as it doesn't have ownership. Once you used lexical scoping, you're not going back to dynamic scope either, the same goes for the ability to reason about "where an object currently is" lexicographically. I think Carp (https://github.com/carp-lang/Carp https://github.com/carp-lang/Carp) is a much more interesting contender for a native clojure, simply because it has lexical ownership.

Guthur 2y ago
I think if you're overly using dynamic scoping in clojure you are probably doing it very wrong. I used clojure professionally for a number of years and I can't remember ever really using it.
- mrkeen 2y ago
  Parent's not talking about dynamic scoping in clojure. It's a comparison to designed to elicit a reaction, e.g. "probably doing it very wrong". I.e. if you're not tracking ownership in new-lang, you're probably doing it very wrong.
  - j-pb 2y ago
    It's not a comparison to bash non-ownership as "very wrong", but arguing that lexical scope and ownership are literally the equivalent things. Lexical scope allows you to reason about scope on a syntactical level. Take this code: let x = 5; fn foo(): return x \* 2 fn bar(): let x = 10 return foo() fn baz(): let x = "hello world!" return foo() bar() With lexical scope, you can look at `foo` and you know immediately what it returns, the behaviour of the function is completely local to it and is a syntactical property of the program. With lexical scope you just don't know what's returned, for all you know x might not even be a number, but could be any type that just happens to be brought into scope. Ownership is similar, in that you make the existence of a value a local property. If a 'thing' is inside a variable then you can move it somewhere else, but it also means that it is no longer in that variable. And that tracking of where what is, is a syntactical property, just like with lexical scope. Clojure has software transactional memory. With ownership it wouldn't need half of the machinery (only that for rollback): let blocked_accounts = Set() let account_bob = new ExclusiveBankAccount(200) let account_alice = new ExclusiveBankAccount(600) // ExclusiveBankAccount cannot be copied or cloned fn transfer(source_acc, target_acc, ammount): if source_acc.deduce(amount.copy()): target_acc.deposit(amount.copy()) fn block(acc): let acc_identifier = acc.identifier.copy() // identifiers can be copied and are not exclusive blocked_accounts.put(acc) return acc_identifier fn unblock(acc): return blocked_accounts.take(acc) fn do_invalid_stuff(): let good_account = new ExclusiveBankAccount(200) let bad_account = new ExclusiveBankAccount(200) block(bad_account) transfer(bad_account, good_account) // <- this will fail because bad_account was moved by the block function and no longer exists here, it's invalid syntactically fn do_valid_stuff(): let good_account = new ExclusiveBankAccount(200) let bad_account = new ExclusiveBankAccount(200) let ident = block(bad_account) let restored_account = unblock(ident) transfer(restored_account, good_account, 100) The above code makes sure that: - you can only transfer funds between two accounts in a thread safe way - you can only transfer funds between accounts that are not blocked Simply by not allowing something like this on a syntactical level you get a much cleaner understanding of what your code does. After a while you're wondering why we allowed anything else in the first place. let x = thing(); let y = x; // the thing is moved from x to y here print(x) The fact that automatic memory management falls out of this is almost accidental, if you can track where a value is at any given time, you can also track the references to it, and the resources it uses. But that is not what truly makes it amazing, the fact that you can mentally think about digital objects as if they were physical objects is.

danbolt 2y ago

I really appreciate the seamless rawdogging into C++ that this language provides. It’s the sort of ambition I’m here for. Or, I find a lot of script runtimes in games have a strict boundary separating them from the native code (often for good reasons), but I wonder if we could integrate more tightly given static analysis has come a long way.

Jeaye 2y ago
"Seamless rawdogging into C++" is the best thing I've read in a while. ^_^ Anything less than seamless rawdogging would be neutered C++.

rcarmo 2y ago

Somehow I completely missed this. I mostly stopped using Clojure solely because of the JVM madness (yes, I know about babaskha, won’t use it due to the GraalVM dependency and possible Oracle tentacles lurking there) and have fallen back to things like Hy (which can be clunky but at least runs everywhere I have a Python interpreter). Something that has better Clojure-like syntax and uses LLVM aid very appealing, provided it can do (and serve) HTTP requests sanely and has enough batteries included. Any good pointers to existing libraries to get a feel for the ecosystem?

bobnamob 2y ago
As far as I'm aware, jank isn't at the point where libraries exist. It's still under initial development and doesn't implement all of Clojure just yet.
sorry_i_lisp 2y ago
No value judgment, what do you mean by "JVM madness"?
- rcarmo 2y ago
  Slowness and bloat, plus the sheer dependency footprint.
  - pjmlp 2y ago
    Slower than C, C++, Rust, yeah still faster than most other alternatives, with exception of .NET. What some call bloat, others see saved effort not reinventing wheels.

barrell 2y ago

Always happy to see clojure on the front page, doubly happy to see jank! I just scoured the internet last week trying to find all the information I could on it. As a clojure(script) developer of 10 years, I still try and avoid anything JVM related. Not that I have anything against the JVM — but I never did any Java programming, and to really learn about the JVM you have to learn quite a bit about Java… which is just very low on my priority list. I have been dreaming about jank a little bit, so maybe this is a good place to ask the question, since I see the jank developer is reading the comments: would it be possible to write a module in jank that can be used in a Swift/iOS application (currently or in the future)? I assume so, but I’m not sure how accessible the outputs of jank are to other c libraries. The reason I ask is I have an offline clojurescript front end. If I want native mobile apps, that means I either have to duplicate the logic, figure out some JavaScript bridge, use react native, or use dart — none of which seem ideal. Ideally I could just extract the critical business logic into a few modules and generate the header files for swift, import directly into cljs for web, and use as regular clojure for android. Totally understandable if this isn’t a valid use case for jank, but it’s what’s captured my imagination :)

Jeaye 2y ago
Yes, definitely. You'll be able to use it to REPL into your phone, for development, and it'll AOT compile alongside the rest of your app for release (Apple is a stickler about JIT compilation in released apps). This, we get largely just by using LLVM.

avbanks 2y ago

Wishing you all the best! Thank you for being ambitious enough to try this out. I'm going to test this out and write about it on my blog.

oldpersonintx 2y ago

[dead]

deleted 2y ago

[deleted]

guenthert 2y ago

clojure gets robust, efficient garbage collection thanks to the JVM. What is jank's approach to memory management?

Jeaye 2y ago
jank is also garbage collected, since Clojure practically demands it. Currently using Boehm, a conservative GC, but we'll need to switch to something more competitive when that becomes a priority. I have my eyes on MMTK + Immix.

slifin 2y ago

I hope this works with flow storm one day

tmtvl 2y ago

Somewhat related-ish: Cakelisp <https://news.ycombinator.com/item?id=36154069 https://news.ycombinator.com/item?id=36154069>

aaronbrethorst 2y ago

How is it pronounced? Dzank or Yonk?

Jeaye 2y ago
j like gentleman, ank like tank

fud101 2y ago

This is dope. I cant remember the last time I got interested in a language enough to want to try it, but this passes that hurdle. I'm looking forward to the first release.