Clojurians Log v2

Context: The audio is a byte-array so normal clj equality doesn’t work

And that's pretty much the reason I avoid "data humanizers".

True. It would’ve been easier to understand the issue if I’d had: #object["[B" 0x50cab54c "[B@50cab54c"]

Herakleitos was correct, you truly can’t step into the same ByteStream twice

Maybe within the scope of tests, CIDER could use a best-of-both-worlds representation e.g. #byte-array[0x50cab54c [116, 101, 115, 116]]

I know almost nothing about Kotlin, so allow me to speak authoritatively about it: it’s at best an iterative improvement over Java. Is it really worth it?

Colin Fleming has some good things to say about Kotlin in the context of using it to build Cursive. I remember null safety was a big element.

My outburst was tongue in cheek; while I don’t know much about the particulars of Kotlin, I totally get that the (sometimes, historically) glacial pace of development of the Java language will entice some people to improve their own situation rather than waiting for someone else to do it. I imagine that in this case, the language can also inform the Java development process about what’s missing from Java.

It's not just about speed, it's about backwards compatibility. There are things you cannot do in Java that would break compatibility, but you can do easily in a brand new language. Even if it is just Java with that one backwards-incompatible tweak, a new name is warranted. (Kotlin is a bit more, though.)

There's a very interesting interview with Brian Goetz on this topic: https://www.youtube.com/watch?v=ZyTH8uCziI4

Also around 48:00 says something about his favorite JVM language apart from Java.

I suspect the XTDB team would have some good things to say about Kotlin too, given that ~20% of that codebase is Kotlin (and 66% is Clojure).

I’ve recently interacted with the Google, Anthropic, and Open AI Java SDKs, migrating away from bespoke REST stuff. Google has written theirs in Java, and Anthropic and Open AI has gone via Kotlin. From a Clojure consumption perspective, the Google SDK has been easier to work with in various ways. I have no idea whether this stems from innate differences between Java and Kotlin, or whether it’s due to SDK design as distinct from language particulars.

That any Google SDK is "easier to work with" is pretty shocking to me, based on extensive use of a lot of Google SDKs! 🤣 We found them to be all over the place and very inconsistent. We ended up writing our own generic Google REST API client that introspects the API description, so we had a consistent "interface" across their various services.

Oh, that certainly wasn’t the case with the Vertex AI, but to my surprise the new “genai” SDK turned out to be pretty OK to work with. Much of that comes down to them supporting fromJson and toJson at pretty much every level, which means I don’t have to switch to parochial object builders for leaf node stuff that is already logically data on the Clojure side (function call requests/responses for example).

Well, logically all of it is data on the Clojure side, but that stuff is especially aggravating to have to squeeze through a bunch of nested builder patterns, because the shape is not statically known.

Click the "write ins" tab:

It wasn't listed because they considered it too niche based on past years' survey numbers I expect.

Ah, ok. Too few to make it statistically interesting

(I was actually more skeptical of their past surveys and they've changed quite a few things about how they present the data this year, I think?)

Nice to know I'm a really Niche CTO 😂

For the past 25 years, I've only worked with niche languages: ColdFusion, Groovy, Scala, Clojure 🙂

My movement (albeit with glacial speed) has been towards niche: C / Perl / Java / JavaScript / TypeScript / Clojure (and with an architect title along some others like Senior Software Jester)

My arc prior to that was C ('80s), C++ ('90s), Java (late '90s). And COBOL/assembler prior to that.

Emacs also consigned to "write-ins" 😢