Hacker News new | past | comments | ask | show | jobs | submit login

You're not going to get "most of the advantages" of Erlang in a language that includes imperative OOP and runs on the JVM. The reliability of Erlang is built around features like:

* Upgrading code while it's running. In Erlang, this works because all program state is explicitly passed as parameters to a tail-recursive main loop, so there's a clear place where one version of the code can cleanly take over the state from a previous version. This won't work in a language with singletons, and mutable objects that mix code and data.

* Modularizing a program into tens or even thousands of lightweight shared-nothing processes. Erlang can do this efficiently because of key properties of the language and VM. For example, the entire language and all of its libraries use persistent or copy-on-write data structures, so that processes can share memory without sharing mutable state. This won't work in a language that's interoperating with Java libraries, and whose own data structures aren't 100% immutable.




That's my issue with Clojure as well. A language that provides and encourages use of a foundational feature X doesn't seem ideally coherent if it depends on usability provided from (Java) libraries which are unable to make use of that feature X.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: