3 ms·

I am the creator of jank. I am also not interested in a flame war. The key differentiator for jank is the seamless C++ interop, which is a problem not many peo

by Jeaye 2mo ago

I am the creator of jank. I am also not interested in a flame war. The key differentiator for jank is the seamless C++ interop, which is a problem not many people are willing to tackle, due to its scope and complexity. jank is a novel approach to this, providing incredible JIT and AOT support of arbitrary C++ libraries alongside your Clojure code, including a Cargo-inspired native build system for building your native deps along with your program (or finding them in the installed system). For some people, there is another key differentiator, which is the amount of AI-generated code involved. My understanding is that Jolt and other newer dialects like Glojure have a lot of spunk and are exploring new ideas, given the velocity that AI-driven coding can provide. I don't see jank ever being categorized in that way.

phtrivier 2mo ago
Thanks, and thanks for the effort on jank ! Since you're here ;) : I read on the alpha doc that protocols and other part of the clojure object model are not done yet - is your goal to include them eventually, or is there a part of the lore of clojure that makes them not indispensable ?
- Jeaye 2mo ago
  Protocols, records, and the like will be implemented in jank. They haven't been prioritized for two reasons. Firstly, historically, jank had a closed object model for performance, which I have blogged about here: https://jank-lang.org/blog/2023-07-08-object-model/ https://jank-lang.org/blog/2023-07-08-object-model/ Over the past few years, I've been spending hammock time to find a solution to this to re-open the object model efficiently. I came up with a design this year which addresses the concerns raised in that blog post and opens up the object model, but jank today is still in a half-way state between the two systems. Secondly, in the several years I've written Clojure professionally, I don't recall ever writing my own protocol, record, or struct. When I was first learning Clojure, I leaned on them more heavily, since I was coming from OOP land. But once I leaned into the pure Clojure data designs, the OOP side of things just stopped mattering. So, if I were to write just about anything in jank, I wouldn't intend on using these features. That alone has made them low priority for me. But they'll be implemented. :) I'd estimate Q1 next year for me to tackle those.
  - yogthos 2mo ago
    Prtotocols tend to be useful for the same reason as Java interfaces. For example, Ring uses a protocol to specify the contract for the adapter. So, then you can just implement it and seamlessly drop in wrapper Jetty or Undertow or whatever. https://github.com/ring-clojure/ring/tree/master/ring-core-protocols https://github.com/ring-clojure/ring/tree/master/ring-core-p...
  - geokon 2mo ago
    > I don't recall ever writing my own protocol, record, or struct. I'm honestly extremely surprised. Protocols seem sort of essential if you want two different "things" to exhibit the same behavior. The whole set of immutable datastructures are fundamentally backed by them (well they use Java Interfaces but its fundamentally the same). Not entirely sure how youd implement them without Protocols Theyre also sort of essential if you want plug-in backends for any part of your codebase. Im curious what your go-to is currently? Do you just write multimethods and dispatch on the inferred input type?
    - Jeaye 2mo ago
      I also rarely use multi-methods in Clojure. I just use maps and vectors and lists and keywords and strings and functions. Instead of multi-methods, I generally use a map of fns. When not writing open, extendable libraries, this is an even simpler choice which I find works well. Most of my Clojure work has been writing applications, so being able to extend in an open way is not a benefit. I'd prefer to keep everything centralized in one map. Also, as I described above in the blog post, protocols/interfaces aren't needed to implement Clojure's object model either. They're just one approach. They're the nominal typing approach, in contrast with something like the structural typing approach, documented in the blog post. For that, we use C++20 concepts for structural typing predicates.

by Jeaye 2mo ago

phtrivier 2mo ago

Thanks, and thanks for the effort on jank ! Since you're here ;) : I read on the alpha doc that protocols and other part of the clojure object model are not done yet - is your goal to include them eventually, or is there a part of the lore of clojure that makes them not indispensable ?

Jeaye 2mo ago
Protocols, records, and the like will be implemented in jank. They haven't been prioritized for two reasons. Firstly, historically, jank had a closed object model for performance, which I have blogged about here: https://jank-lang.org/blog/2023-07-08-object-model/ https://jank-lang.org/blog/2023-07-08-object-model/ Over the past few years, I've been spending hammock time to find a solution to this to re-open the object model efficiently. I came up with a design this year which addresses the concerns raised in that blog post and opens up the object model, but jank today is still in a half-way state between the two systems. Secondly, in the several years I've written Clojure professionally, I don't recall ever writing my own protocol, record, or struct. When I was first learning Clojure, I leaned on them more heavily, since I was coming from OOP land. But once I leaned into the pure Clojure data designs, the OOP side of things just stopped mattering. So, if I were to write just about anything in jank, I wouldn't intend on using these features. That alone has made them low priority for me. But they'll be implemented. :) I'd estimate Q1 next year for me to tackle those.
- yogthos 2mo ago
  Prtotocols tend to be useful for the same reason as Java interfaces. For example, Ring uses a protocol to specify the contract for the adapter. So, then you can just implement it and seamlessly drop in wrapper Jetty or Undertow or whatever. https://github.com/ring-clojure/ring/tree/master/ring-core-protocols https://github.com/ring-clojure/ring/tree/master/ring-core-p...
- geokon 2mo ago
  > I don't recall ever writing my own protocol, record, or struct. I'm honestly extremely surprised. Protocols seem sort of essential if you want two different "things" to exhibit the same behavior. The whole set of immutable datastructures are fundamentally backed by them (well they use Java Interfaces but its fundamentally the same). Not entirely sure how youd implement them without Protocols Theyre also sort of essential if you want plug-in backends for any part of your codebase. Im curious what your go-to is currently? Do you just write multimethods and dispatch on the inferred input type?
  - Jeaye 2mo ago
    I also rarely use multi-methods in Clojure. I just use maps and vectors and lists and keywords and strings and functions. Instead of multi-methods, I generally use a map of fns. When not writing open, extendable libraries, this is an even simpler choice which I find works well. Most of my Clojure work has been writing applications, so being able to extend in an open way is not a benefit. I'd prefer to keep everything centralized in one map. Also, as I described above in the blog post, protocols/interfaces aren't needed to implement Clojure's object model either. They're just one approach. They're the nominal typing approach, in contrast with something like the structural typing approach, documented in the blog post. For that, we use C++20 concepts for structural typing predicates.