> Sounds like HList. Maybe. I have never heard of HList until today. > Do you avoid instantiating a JVM object for each entry? Yes, a tuple, at the VM level

> Sounds like HList. Maybe. I have never heard of HList until today. > Do you avoid instantiating a JVM object for each entry? Yes, a tuple, at the VM level is just a wrapped array. Our compiler backend does magic with certain language module types. > Are you sacrificing Java compatibility, or is the tradeoff somewhere else? Well, I dunno, a tuple looks like a regular Ceylon list to a Java client, but I don't think that really breaks _compatibility_ as such. Depends how you define "compatible". > Having now paid attention to who you are, how do you handle ORM in what I presume is a more immutability-oriented language? No clue. That's something we'll have to think about in 2014. > hibernate seems to expect sessions to belong to a single thread, objects to belong to a single session, and updates to be performed by mutating an object rather than copying it. Yes. That's definitely what Hibernate expects. It was never designed for copy-on-write. Because at the end of the day the database contains a bunch of mutable state and Hibernate reflects that in memory. I can't imagine that the solution to this problem is going to be straightforward. > Anyway, to get back to the point, does Ceylon have a good story for this problem? Not yet. > Is it going to include a next-gen hibernate replacement? I hope so, but I can't promise because I have not spent time thinking about it.