3 ms·

The "doesn't have good library support" factor is mitigated by its "ports" - Erlang is happy to run arbitrary processes in C, Python, Lua, whatever in a bubble

The "doesn't have good library support" factor is mitigated by its "ports" - Erlang is happy to run arbitrary processes in C, Python, Lua, whatever in a bubble and just be the fault-tolerant network glue tying them together. I seem to be fond of languages that make polarizing trade-offs but encourage multi-language programming: Lua, Prolog, Erlang, awk, etc. Use them when they're the best tool for the job, and when they aren't, they'll happily co-operate. Win win. (Requiring people to know multiple languages seems like it'd be a burden, but said languages can also be a lot smaller because they can avoid being responsible for what they're bad at. And, isn't that ultimately the point of DSLs?)

davidw 16y ago
I thought you just liked languages that start arrays at 1... If you have to glue stuff together in C or with pipes, it's going to be just as easy to do it in Tcl, Python, Ruby or whatever though, which also have more libraries to start with, and are fairly "promiscuous" in their own right. I'm not sure I buy the 'glue language' thing: that's what both Tcl and PHP (and Perl to some degree) started out as, but it seems that people end up wanting to do everything in the higher level language that they can, because it's a lot less effort. Something that might be really cool is if one of the efforts like Reia took off and made something a little bit nicer looking that sits on top of the Erlang run time.
- silentbicycle 16y ago
  > I thought you just liked languages that start arrays at 1... Ha. If anything, I'm big on languages based around pattern matching. :) Oh, and Erlang's ports are better than Unix pipes - it's more like a process run in isolation with asynchronous IO, and which the local Erlang runtime can restart as necessary. I changed the wording a bit to make that clearer. I prefer working 100% in higher level languages and then moving hotspots down to C, etc., but it seems like languages designed to be glue languages make the transition easiest (because they have a kind of inherent modesty). I never got into Tcl, but feel a common mindset in Ousterhout's essays (such as http://home.pacbell.net/ouster/scripting.html http://home.pacbell.net/ouster/scripting.html).

davidw 16y ago

I thought you just liked languages that start arrays at 1... If you have to glue stuff together in C or with pipes, it's going to be just as easy to do it in Tcl, Python, Ruby or whatever though, which also have more libraries to start with, and are fairly "promiscuous" in their own right. I'm not sure I buy the 'glue language' thing: that's what both Tcl and PHP (and Perl to some degree) started out as, but it seems that people end up wanting to do everything in the higher level language that they can, because it's a lot less effort. Something that might be really cool is if one of the efforts like Reia took off and made something a little bit nicer looking that sits on top of the Erlang run time.

silentbicycle 16y ago
> I thought you just liked languages that start arrays at 1... Ha. If anything, I'm big on languages based around pattern matching. :) Oh, and Erlang's ports are better than Unix pipes - it's more like a process run in isolation with asynchronous IO, and which the local Erlang runtime can restart as necessary. I changed the wording a bit to make that clearer. I prefer working 100% in higher level languages and then moving hotspots down to C, etc., but it seems like languages designed to be glue languages make the transition easiest (because they have a kind of inherent modesty). I never got into Tcl, but feel a common mindset in Ousterhout's essays (such as http://home.pacbell.net/ouster/scripting.html http://home.pacbell.net/ouster/scripting.html).