Joe talked about this in Strange Loop 2014, and it seems to me that the idea is far less crazy than it seems. The more functional programming I do, the more sense it makes.
A major reason for modules in OO languages is to manage mutability: There's some hidden state, and some conventions surrounding that state, that the module tries to abstract away from us. But the price is very high: We have to make sure our executables are built with the right versions of modules, and avoid incompatibilities: What we know as dependency hell.
But why do we need dependency hell at all? For instance, in Scala, why do I have to do gymnastics to use a modern version of Shapeless along with spray-routing? Because the JVM is not happy with multiple, incompatible versions of shapeless in the same classloader.
Under Joe's plan, all of that disappears. It's just a question of how much we lose in exchange for sidestepping a problem like this. Given that any libraries I write nowadays tend to have just a few hundred lines of production code, I am very tempted.
A major reason for modules in OO languages is to manage mutability: There's some hidden state, and some conventions surrounding that state, that the module tries to abstract away from us. But the price is very high: We have to make sure our executables are built with the right versions of modules, and avoid incompatibilities: What we know as dependency hell.
But why do we need dependency hell at all? For instance, in Scala, why do I have to do gymnastics to use a modern version of Shapeless along with spray-routing? Because the JVM is not happy with multiple, incompatible versions of shapeless in the same classloader.
Under Joe's plan, all of that disappears. It's just a question of how much we lose in exchange for sidestepping a problem like this. Given that any libraries I write nowadays tend to have just a few hundred lines of production code, I am very tempted.