Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Jank Language: LLVM Hosted Clojure

jank-lang.org

Post reply on HN
Print view View original

71–80 of 83 posts

Re: The Jank Language: LLVM Hosted Clojure

#71

Post by burjui »

mike_hearn wrote: post #35
ducktective wrote: post #32

Earlier quoted context omitted.

Yes, when the same functionality could be achieved in like 200KiB, 10 MiB is too much. It adds up and suddenly you may have to bundle a whole browser with your ap...oh

Bear in mind that this 10mb is not a fixed multiplication factor. Like, doubling you code size doesn't double your binary size with native-image because that base contains a lot of stuff that's generic. Not just GC but stuff like support for timezones. It also contains a cached heap (in fact most of it is cached heap) which is one reason these binaries start as fast as C programs do. Especially important for Clojure…

That begs the question: if Clojure is so inefficient, that a program written in it needs 10 MB of some "cached heap" just to start as fast as a C program, and it does a lot of unnecessary work at startup, why use Clojure and this Jank (great name lol) in the first place? We have Rust, after all. I mean, creating an optimizing native compiler for any language is not an easy task, there must be some seriously powerful stuff in Clojure to warrant such an undertaking. Or just madness.

Re: The Jank Language: LLVM Hosted Clojure

#72

Post by reitzensteinm »

eatonphil wrote: post #69
eatonphil wrote: post #68

Earlier quoted context omitted.

Does Clojure really compete closely in overall performance with other immutable-first languages like OCaml/Standard ML?

This is all a bit of a distraction though. > The only reason Clojure is viable for production use is because it relies on the really good JVM GCs. How will Jank try to solve the the GC problem? I think this original statement is wrong because people are fine with poor performance (see Python, Ruby) if the language (ecosystem) is effective. And Clojure is effective (IMO) moreso because of the JVM ecosystem not the JVM…

I think you're underestimating how slow a naive implementation would be. The only Clojure implementations that have gained traction are built on top of both great JITs and GCs.

Re: The Jank Language: LLVM Hosted Clojure

#73

Post by ithrow »

burjui wrote: post #71
mike_hearn wrote: post #35

Earlier quoted context omitted.

Bear in mind that this 10mb is not a fixed multiplication factor. Like, doubling you code size doesn't double your binary size with native-image because that base contains a lot of stuff that's generic. Not just GC but stuff like support for timezones. It also contains a cached heap (in fact most of it is cached heap) which is one reason these binaries start as fast as C programs do. Especially important for Clojure…

That begs the question: if Clojure is so inefficient, that a program written in it needs 10 MB of some "cached heap" just to start as fast as a C program, and it does a lot of unnecessary work at startup, why use Clojure and this Jank (great name lol) in the first place? We have Rust, after all. I mean, creating an optimizing native compiler for any language is not an easy task, there must be some seriously powerful…

It's like they have not seen how much engineering resources and talent have been put into V8 and JVM GCs, and it's only because of these state of the art GCs (and JITs) that Clojure is bearable and practical for day to day use.

I'm almost sure the author would drop the project as soon as he realizes and lives the frustration of not being able to come anywhere near close to the performance of Clojure in the JVM.

Re: The Jank Language: LLVM Hosted Clojure

#74

Post by terinjokes »

Jeaye wrote: post #48
dangoor wrote: post #44

Unless I'm reading it wrong, it sounds from the license[1] like programs made with Jank that you want to distribute must have their source available. If the intention is that distributions of the _Jank compiler itself_ are the only things that need source available, I think it'd be good to spell that out. [1]: https://github.com/jeaye/jank/blob/main/LICENSE

This applies to the compiler itself, in the same way that GCC is under the GPL but that doesn't mean all programs you compile with it are also under the GPL.

I'm curious if there is a reason you went with (what I believe is) a derivative of the Sleepycat license, instead of one of the more familiar licenses?

Your comment here is at odds with my understanding of how the Sleepycat license works and how Berkeley DB is licensed.

Re: The Jank Language: LLVM Hosted Clojure

#75

Post by huahaiy »

burjui wrote: post #71
mike_hearn wrote: post #35

Earlier quoted context omitted.

Bear in mind that this 10mb is not a fixed multiplication factor. Like, doubling you code size doesn't double your binary size with native-image because that base contains a lot of stuff that's generic. Not just GC but stuff like support for timezones. It also contains a cached heap (in fact most of it is cached heap) which is one reason these binaries start as fast as C programs do. Especially important for Clojure…

That begs the question: if Clojure is so inefficient, that a program written in it needs 10 MB of some "cached heap" just to start as fast as a C program, and it does a lot of unnecessary work at startup, why use Clojure and this Jank (great name lol) in the first place? We have Rust, after all. I mean, creating an optimizing native compiler for any language is not an easy task, there must be some seriously powerful…

Rust and Clojure address completely different domains of problems.

Rust is competing with C++ for writing low level systems, whereas Clojure is designed for writing business applications.

Low level systems tend to have stable and well understood requirements, whereas the same cannot be said for business applications. Efficiency is not a primary concern of business applications, but flexibility is. The efficiency of Clojure is often "good enough" for business application, and there is no peer in flexibility. This explains the many fintech companies using Clojure, as well as many other B2B companies.

Re: The Jank Language: LLVM Hosted Clojure

#76

Post by huahaiy »

ithrow wrote: post #73
burjui wrote: post #71

Earlier quoted context omitted.

That begs the question: if Clojure is so inefficient, that a program written in it needs 10 MB of some "cached heap" just to start as fast as a C program, and it does a lot of unnecessary work at startup, why use Clojure and this Jank (great name lol) in the first place? We have Rust, after all. I mean, creating an optimizing native compiler for any language is not an easy task, there must be some seriously powerful…

It's like they have not seen how much engineering resources and talent have been put into V8 and JVM GCs, and it's only because of these state of the art GCs (and JITs) that Clojure is bearable and practical for day to day use. I'm almost sure the author would drop the project as soon as he realizes and lives the frustration of not being able to come anywhere near close to the performance of Clojure in the JVM.

That's indeed a valid concern. Keeps my finger crossed.

Re: The Jank Language: LLVM Hosted Clojure

#77

Post by dunefox »

vindarel wrote: post #59
dunefox wrote: post #33

Earlier quoted context omitted.

That seems very abandoned.

How so? Last commit: June of this year. State: "very early (pre-alpha) stages, but it has progressed far enough to load clojure.test, allowing the test suite to actually be written in Clojure." and the author is still a very active lisper. So, pretty nice for an experiment, I guess.

Yes, that commit changed the readme. The commit before that was in January of 2021, the one before that in March 2020. Doesn't look very active to me.

Re: The Jank Language: LLVM Hosted Clojure

#78

Post by JonChesterfield »

mjul wrote: post #36
vaylian wrote: post #27

Earlier quoted context omitted.

The official Clojure (JVM) project has an official sister project: ClojureScript, which is designed to be compiled to JavaScript (and maybe Webassembly in the future?). There is a lot of code that runs with both languages and therefore I don't think you should worry too much about using Jank with existing Clojure/ClojureScript libraries.

Clojure is a language without a platform so all the Clojure dialects have the different semantics of the underlying platform, be it the JVM or JavaScript. For example ClojureScript has all the “wat” semantics from JavaScript primitive types. You can build libraries that try to hide the differences but the leaky abstraction is inherently still there.

I didn't realise clojurescript did that, though clojure certainly threw JVM stack traces at me.

That seems a shame - a language implementation is an abstraction that doesn't have to leak, the layer below can be totally inaccessible if desired.

Re: The Jank Language: LLVM Hosted Clojure

#79

Post by 3836293648 »

Jeaye wrote: post #56
masukomi wrote: post #54

Earlier quoted context omitted.

The landing page explicitly says "jank is 100% compatible with Clojure." not "jank aims to be..." No, "jank IS" this is... ridiculously uncool and misleading.

Thanks for the feedback. The usage of "jank" here refers to its design; the concept of jank. This is different from its current implementation. jank is designed to be many things, as the landing page shows, and the implementation is catching up with that.

Aren't the implementation and jank the same thing? It still reads like it's claiming to be Clojure.

Like clang is still C, just like GCC is still C

Re: The Jank Language: LLVM Hosted Clojure

#80

Post by mike_hearn »

burjui wrote: post #71
mike_hearn wrote: post #35

Earlier quoted context omitted.

Bear in mind that this 10mb is not a fixed multiplication factor. Like, doubling you code size doesn't double your binary size with native-image because that base contains a lot of stuff that's generic. Not just GC but stuff like support for timezones. It also contains a cached heap (in fact most of it is cached heap) which is one reason these binaries start as fast as C programs do. Especially important for Clojure…

That begs the question: if Clojure is so inefficient, that a program written in it needs 10 MB of some "cached heap" just to start as fast as a C program, and it does a lot of unnecessary work at startup, why use Clojure and this Jank (great name lol) in the first place? We have Rust, after all. I mean, creating an optimizing native compiler for any language is not an easy task, there must be some seriously powerful…

A dynamically typed Lisp has virtually nothing in common with Rust. A cached heap can benefit literally any language which is why it's an optimization found in some programs written in C or C++ as well.

Also, Rust binaries have been of comparable size in the past. Check out this question where someone asks why Hello World is 3mb even in release mode:

https://stackoverflow.com/questions/29008127/why-are-rust-ex...

This 3mb doesn't have any cached heap, doesn't have any garbage collector, doesn't have support for high quality exceptions and doesn't have much in the way of a cross platform abstraction, whereas the Clojure-as-native binary has all of those and more.

There's a giant pile of things you can do here to try and reduce Rust's binary size:

https://github.com/johnthagen/min-sized-rust

... but as you can see, it's a lot of work.

Rust gets great press and HN is flooded with "let's do it in Rust" type comments. But I think sometimes we need a reality check. Rust is an extremely different language to most others, even C. The combination of the borrow checker+everything async is not obviously better than everything else, not even in the low level domains even though Rust is deservedly picking up loyal users there. The moment you care about development speed i.e. for the sort of apps Clojure was designed for, you're going to be better off with a GC and a strong runtime that abstracts the platform well.

Post reply on HN