4 ms·

Not trying to make a point or anything, but from my own experiences, people definitely seem to align differently to different languages and paradigms. I know f

Not trying to make a point or anything, but from my own experiences, people definitely seem to align differently to different languages and paradigms. I know for myself, when I got a chance to code professionally in Erlang, I was hooked, and could not see myself going back to Java or a mainstream scripting language. Having to think and model problems concurrently, think about failure, etc, is so natural a fit for my brain that trying to fit a language that doesn't have those as first class constructs feels stifling, and having to eschew those concerns to write something that ignores the considerations Erlang prioritizes breaks my brain; I've tried it for timed coding events and it just did not work (i.e., realizing after the fact "Oh, yeah, I totally didn't need to spend time making sure that my supervisor tree made sense, that state was persisted properly, and resumable in the event of restart"). And yet it's not totally ideal, either; I care deeply about typing, and wanting to squeeze the most 'correctness' as I can from static analysis, and Dialyzer just isn't quite sufficient to fully scratch that itch. Meanwhile I've seen some teammates who, while having the same diligence in thought, tend to be far more sequential, far more inclined toward single threaded models, reserving concurrency for the truly necessary cases, and more concerned with try/catch style error handling, than ensuring proper typing (Dialyzer) and otherwise letting it fail (at least until we know what we -really- need to handle). Both I and my teammates have very similar backgrounds, coming from a predominantly Java background, some with a bit of .Net, Javascript, etc, with a smattering of mainstream scripting languages thrown in, and of course, we're all working on the same project. Yet our 'taking' to the language and its paradigms varies pretty drastically. I think people, especially the HN crowd, miss that. PG's "Blub" paradox is viewed as the rule, and obviously everyone thinks they're at the top (or at least, as high up as is pragmatic for their domain), and while it's certainly true that you can't appreciate what you're missing if you don't at least understand it, people's brains work in very different ways. Languages certainly vary, and some are definitely better than others along a given axis, but I think it's unfair to take one's own experiences as objective truth. Even apart from domain differences, "This language made me 10x more effective"; yes, but is that due to the language, or due to your thought processes naturally fitting it? Will someone else who thinks differently find the methods of expressing problems in that language so naturally efficient that they'll see the same gains, or will it actually slow them down, even after learning it, because it isn't as good a fit for them?

eropple 12y ago
Though I've used it for my own stuff a little bit, I don't have a sufficient background in Erlang to really think natively in it. I do, however, spend a lot of time in Scala-land, where Akka is king (for better or worse) and tries to pull a lot of the same principles into the JVM. Have you ever looked at it? I'm curious how it feels to somebody who's worked extensively in Erlang. I think PG's Blub Paradox only works to a point, as you say, and I think you nailed what regularly drives me nuts about technology: there are axes to this stuff that people mash into a continuum to feed their (rampant) insecurities--so they can look down on somebody. I think it's a sign of cultural and personal immaturity. I thought it was super-cool to issue sweeping statements about technologies at one point, and sometimes I still fall into it when I'm feeling salty, but I try not to. Which is different from sweeping statements about the craft of programming; Gary Bernhardt's twitter feed is chock-full of things that as a programmer you really should full-stop not do to your users. But technology--ehh. I goof on Go a lot, and it does drive me squirrelly when I have to debug somebody's Go project for work, but I just can't cape for any particular stack anymore. Even Java has plenty of uses. (For me, Java's useful in that I can see in my head roughly what the bytecode output of a given thing, and reason about its behaviors on the JVM better than I can Scala.)
- lostcolony 12y ago
  I only ever toyed with Scala, and Akka, so I can't really speak too much to it, but it struck me that what I liked most about it was what Erlang simply ~is~. I think the main difference to me was that Erlang was built from the ground up for fault tolerance. Everything about it is structured around that; you get process isolation and concurrency because of the need to not have one error/exception kill everything, you get distribution because you need hardware/VM issues to not kill everything. Akka's motivation isn't that; it can't do that. The JVM doesn't allow for process isolation, there's one shared heap, etc, so it really does matter what is running locally vs what is running on other machines, you have to be careful about mixing concurrency patterns and using vars, and it is possible for one process to die and take down others with it. Akka is a little alien to me as well; things like 'become' seems a bit heavy handed (I believe it's due to the JVM not supporting tail call optimization, and Scala can't trampoline the calls if it doesn't know what you're trying to do). Similarly, the reactive nature of actors in Akka, where they don't do anything until they receive a message, while superficial, still bothers me a little bit. My mental model of an actor in Erlang is simply a lightweight process that executes a function, that has a queue attached; at any point the process can check its queue, and if it needs to repeat itself or change its behavior, you call itself or a different function. It's a very simple mental model that all the OTP behaviors build on. Akka instead has (necessarily) various syntaxes; you're creating this ~thing~ first, setting up all the things it can do, and then it sits waiting for a message to start executing. It's trivial to transcribe one mental model to the other, but I find Erlang's is the one I think best in. Now, that said, provided you don't need the soft realtime performance of Erlang, Scala/Akka is generally going to be more performant when it comes to number crunching; it's easier to just do it natively in Scala/Akka than have to do it externally in Erlang and open a port. Scala/Akka benefits from existing JVM expertise which most devs have a bit of; the Erlang VM has its own deep knowledge you have to learn to run it in production (that said, the introspection you have into it is -killer-). Scala/Akka is easier to transition people to, due to the OOness ("squint a bit and it can kinda be written like Java!"), but I think making a clean break of things with Erlang helped me; even the 'strange' syntax was helpful in that I didn't assume false familiarity due to syntax that seemed familiar (except for 'if'; everyone misuses that at least once). But if a dev finds that way of thinking alien to them, in the Erlang world they're just not going to be that productive; in Scala, you can mix paradigms and they'll likely see better productivity in areas of the code that are still very OO and imperative. I tend to feel there be dragons in OO, imperative code, but the reality is a lot of shops don't have the leisure to write everything in a functional manner, and to pick and choose who works on it based on their familiarity with that paradigm. There are a few other odds and ends; Scala allows operator overloading which I need so rarely that opening it up is a con in my book, there's a lot of implicit stuff (apply for instance) that while really cool, allows for a lot of hidden dragons to be buried in a large, shared codebase, I really wish Erlang was statically typed as I said before, etc, but those are the main.

eropple 12y ago

Though I've used it for my own stuff a little bit, I don't have a sufficient background in Erlang to really think natively in it. I do, however, spend a lot of time in Scala-land, where Akka is king (for better or worse) and tries to pull a lot of the same principles into the JVM. Have you ever looked at it? I'm curious how it feels to somebody who's worked extensively in Erlang. I think PG's Blub Paradox only works to a point, as you say, and I think you nailed what regularly drives me nuts about technology: there are axes to this stuff that people mash into a continuum to feed their (rampant) insecurities--so they can look down on somebody. I think it's a sign of cultural and personal immaturity. I thought it was super-cool to issue sweeping statements about technologies at one point, and sometimes I still fall into it when I'm feeling salty, but I try not to. Which is different from sweeping statements about the craft of programming; Gary Bernhardt's twitter feed is chock-full of things that as a programmer you really should full-stop not do to your users. But technology--ehh. I goof on Go a lot, and it does drive me squirrelly when I have to debug somebody's Go project for work, but I just can't cape for any particular stack anymore. Even Java has plenty of uses. (For me, Java's useful in that I can see in my head roughly what the bytecode output of a given thing, and reason about its behaviors on the JVM better than I can Scala.)

lostcolony 12y ago
I only ever toyed with Scala, and Akka, so I can't really speak too much to it, but it struck me that what I liked most about it was what Erlang simply ~is~. I think the main difference to me was that Erlang was built from the ground up for fault tolerance. Everything about it is structured around that; you get process isolation and concurrency because of the need to not have one error/exception kill everything, you get distribution because you need hardware/VM issues to not kill everything. Akka's motivation isn't that; it can't do that. The JVM doesn't allow for process isolation, there's one shared heap, etc, so it really does matter what is running locally vs what is running on other machines, you have to be careful about mixing concurrency patterns and using vars, and it is possible for one process to die and take down others with it. Akka is a little alien to me as well; things like 'become' seems a bit heavy handed (I believe it's due to the JVM not supporting tail call optimization, and Scala can't trampoline the calls if it doesn't know what you're trying to do). Similarly, the reactive nature of actors in Akka, where they don't do anything until they receive a message, while superficial, still bothers me a little bit. My mental model of an actor in Erlang is simply a lightweight process that executes a function, that has a queue attached; at any point the process can check its queue, and if it needs to repeat itself or change its behavior, you call itself or a different function. It's a very simple mental model that all the OTP behaviors build on. Akka instead has (necessarily) various syntaxes; you're creating this ~thing~ first, setting up all the things it can do, and then it sits waiting for a message to start executing. It's trivial to transcribe one mental model to the other, but I find Erlang's is the one I think best in. Now, that said, provided you don't need the soft realtime performance of Erlang, Scala/Akka is generally going to be more performant when it comes to number crunching; it's easier to just do it natively in Scala/Akka than have to do it externally in Erlang and open a port. Scala/Akka benefits from existing JVM expertise which most devs have a bit of; the Erlang VM has its own deep knowledge you have to learn to run it in production (that said, the introspection you have into it is -killer-). Scala/Akka is easier to transition people to, due to the OOness ("squint a bit and it can kinda be written like Java!"), but I think making a clean break of things with Erlang helped me; even the 'strange' syntax was helpful in that I didn't assume false familiarity due to syntax that seemed familiar (except for 'if'; everyone misuses that at least once). But if a dev finds that way of thinking alien to them, in the Erlang world they're just not going to be that productive; in Scala, you can mix paradigms and they'll likely see better productivity in areas of the code that are still very OO and imperative. I tend to feel there be dragons in OO, imperative code, but the reality is a lot of shops don't have the leisure to write everything in a functional manner, and to pick and choose who works on it based on their familiarity with that paradigm. There are a few other odds and ends; Scala allows operator overloading which I need so rarely that opening it up is a con in my book, there's a lot of implicit stuff (apply for instance) that while really cool, allows for a lot of hidden dragons to be buried in a large, shared codebase, I really wish Erlang was statically typed as I said before, etc, but those are the main.