2 ms·
That was sarcasm. I get the impression that many of the people put off by Erlang's strings are unaware of atoms, too. The string type could be better, certainl
by silentbicycle 16y ago
That was sarcasm. I get the impression that many of the people put off by Erlang's strings are unaware of atoms, too.
The string type could be better, certainly, but the language has plenty of other aspects to make up for it. I hear Java is bad at {atoms,pattern matching,fault tolerance,...}.
- jerf 16y agoSorry, I have a bad habit of springboarding off the sarcasm without making it clear I got it. :) Seriously, they're months away from the point where they will discover they can't replicate Erlang on top of JS no matter how smart they are; I'm very down on Node.js's long term future because trying to build it on top of JS was locally a cool hack but globally an unrecoverable error. They're not done applying their first coat of whitewash and not interested in being told that a whitewashed Pinto is still not going to be a race car.
- silentbicycle 16y agoNo kidding. I was working on a very similar, event-loop-based system in Lua, but after spending more time with Erlang, I realized that it was already done a million times better. Lua's very good for other stuff, but massive concurrency is not its focus. I wrote a (somewhat limited) Lua asynch. webserver to provide a REST interface to my distributed filesystem, but I'm not interested in generalizing it or making it uber-scalable anymore. It uses select (luasocket.select, actually), which is quite good enough for my purposes. It's not the primary part of the system, anyway - it was actually feature creep. The thing that really bugs me with node.js is writing everything in callback-passing-style. Coroutines are SO much cleaner.