Yea, seems great. There are some really impressive projects for the JVM: • graalvm's native-image: compile to native • panama: flexible, fast native interop • valhalla: value objects • loom: virtual threads

Gripe about loom: give us continuations, Ron

Calling it now: Next Big Thing for JVM is lifetimes

Or traits

it is complicated though, things like clojure maps rely on being trees of pointers to make path copying work, which is what makes updating cheap even though they are immutable maps

if you watch the loom presentation from the jvm language summit, the presenter mentions people running into basically unrealistic expectations

people just wanting to sprinkle virtual threads on everything and have it go better, without understanding the limitations of virtual threads and the expected use cases for them

value objects look great, and some of the more recent stuff I've seen where they talk about not having to introduce new byte codes for it sounds fantastic, and man it would be great to get rid of the primitive/object distinction

but we'll see what we get

Yeah - perhaps this can do more for things like tech.ml.dataset (which relies on packed data) than the built in clojure data structures.

Aren't value classes in Clojure a good fit for • defrecord • enjoying the benefits for primitives - longs, doubles, booleans?

I think the semantics of value classes are a good fit, the question is will the improved communication of intent to the jvm result in running faster / using less memory, it likely will, but there maybe be caveats, and it may take time to how best to use them

and, depending on how they are implemented, if they require additional compiler support, etc it might be a while before we see that land in clojure

.NET has had them forever, I think usually most business apps usually don't have a strong need for them

there was a lot of speculation about improvements from invoke dynamic, but that has been available for sometime and clojure doesn't use it (deciding where and when in the clojure compiler to use it, would certain things in clojure need a redesign, would that be backwards compatible, etc, etc)

java got functional interfaces and some notion of lambdas a while back and maybe the next clojure release will have features to make interop with that more seamless

I think its safe to be in "wait and see" mode

at least in terms of language features on the clojure side

though no reason the wider us can't mess around with macros+bytecode generation day -100

the loom presentation mentioned that because so much of the continuations implementation in the jvm is actually written in java, to reach peak performance of virtualthreads you have to wait until the continuation implementation has been jitted

Ron Pressler replied to a reddit thread where i shared some snippets for using Continutations pointing out that they are unsafe to use right now

or at least the API is

sure, but the continuations are what underpin loom virtual threads

i guess i was more replying to @UK0810AQ2 wanting continuations to be exposed

it depends on how the nullness side channels are exposed i guess?

if i'm thinking about how someone could make a maximally flattened array from clojure

Okay so random thoughts • Defrecord probably can't be made value-like because clojure maps probably can't. Structural sharing requires identity • If we made a def-jvm-record we could piggyback on whatever construction/reconstruction optimizations the JVM will do for records with those operations • A JVM record can be made value-based, so that might be the interop path • Assoc in a "value based JVM record" might not be able to support adding arbitrary keys like clojure records, so crash or promote would be a choice. • If we choose promote then maybe generating a sealed interface with a JVM record and clojure record implementations would make sense? • If we choose crash then that problem goes away • If there are no special optimizations given to JVM records, then generating a "different" impl of clojure lang Record might be okay • I'm stuck in bold now okay I'm free • The elephant in the room is metadata. To support metadata I think we want identity semantics even if we don't need it. == shouldn't really compare metadata • Tags, as implemented, probably won't be enough to represent arrays which contain non-null elements since [L the descriptor is unchanged • Array creation would need to be somehow expanded to allow for cramming in nullness/specification information • The benefit of Valhalla for us on this side would the same as for java, but it would be much more for high perf JVM specific stuff, not altering the programming model (unlike Java where I expect to have to explain the knob a lot more)

Considering how much startup time is a problem, ComputedConstant might be the most interesting thing coming down the pipe for me right now

I don't remember ever running into an issue where startup time is a problem. What are people doing where startup time is an issue?

Lambdas, shell scripts, etc

Babashka has claimed that niche as of now

@U3JH98J4R re defrecord, can't value classes' members be references? I think the extmap won't be a problem, if anything metadata will but just use equals() like the presenter said

You couldn't do lazy hashcode calculating

(which defrecords do)

Not lazy, deferred until first use I guess?

Why not implement metadata as Object<struct>? I think this should work. Then the Object bit won't be copied around but the struct bit would be copied :thinking_face: But then this Object will be located in the heap and cloned a lot of times :thinking_face: Basically int vs Integer... so object and Object :thinking_face: Edit: probably this doesn't sound too good

exposing continuations is super gross and I don’t know why people moan for it except for academic reasons or feature envy

it would be incompatible with pretty much every extant java lib

democratization of control flow

without continuations the runtime/language determines what control flow is available, with continuations users can build their own

(should they? do you trust them to? do you want to rely on code doing that?)