Instead of writing "implemented in Erlang", why not just write "slow"?
Seriously, how else could the implementation language matter? Aside from speed, either the thing is useful or it ain't. I appreciate the warning. However, reading the press release, it seems as if the event being announced is not just releasing a new version, but actually freeing up the code. People who hope to customize it probably do need to know what language they'll be coding.
Posted Jul 27, 2010 22:37 UTC (Tue) by NAR (subscriber, #1313)
[Link]
Seriously, how else could the implementation language matter?
For example with Erlang you get the possibility of hot code loading, which might mean upgrade without downtime. Also with Erlang distribution is built into the language/VM, so it might be very simple to scale the application by adding extra hardware. These features could be useful for a database of "big data". Of course these are only possibilities, it depends on the application too.
Also, any language that is not C/C++ implicates that you won't get segmentation faults because of an off-by-one error or a buffer overflow (although I have to add I've seen both the Java and the Erlang VMs segfaulting).
"high-level" is always a euphemism
Posted Jul 27, 2010 23:24 UTC (Tue) by njs (guest, #40338)
[Link]
This application is not going to be CPU bound, so who cares how slow Erlang is? It'll be IO bound (for which language doesn't matter), and scalability bound (for which Erlang, all else being equal, is going to kick the pants off pretty much any other mature/widely deployed language. It's a sad commentary on the current state of programming languages that every otherwise attractive general purpose language sucks mightily at distributed computing, but there it is).