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/

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.

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-p...

> 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?

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.