> FTR, the way Ceylon models this is the way this is the same way it is modeled in mathematics. That is to say, in mathematics, a function is a set of ordered pairs, where the first element of each ordered pair is a tuple. The notion of a tuple is itself defined by recursion. Therefore, in Ceylon, a function type is Callable<AType, ATupleType>, and Tuple is is a class with a recursive definition. Clean, intuitive, abstractable.

Sounds like HList. AIUI performance concerns were why early versions of Scala used the current style of tuple (and alas compatibility requires us to keep using it). Do you avoid instantiating a JVM object for each entry? Are you sacrificing Java compatibility, or is the tradeoff somewhere else?

Having now paid attention to who you are, how do you handle ORM in what I presume is a more immutability-oriented language? Right now I've got a nice reactive spray webapp backing on to a pool of database-access threads (because JDBC still does blocking I/O) which are deliberately as dumb as possible, and it feels like I'm fighting hibernate all the way; 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. It works for now, but it feels like every time I try to do something new (like having an entity with a collection in) something breaks; I'm not saying it's impossible to use hibernate in this kind of environment (I mean, the reason I'm using it at all is that it's still better than the alternatives) but it feels like I'm cutting against the grain and everything is harder than it should be. Perhaps I should be using monads to accumulate operations to be performed in a session, and handing those off to my database threads? (but even that won't work if I want to update an object based on the result of an async call).

Anyway, to get back to the point, does Ceylon have a good story for this problem? Is it going to include a next-gen hibernate replacement? Is there some nice way to do session-in-view and carry a session for a particular web request around even as processing that request happens on several threads? Are you still expecting people to represent database rows as mutable objects? Am I thinking about this all wrong?