7 ms·

Go vs. Erlang for distribution

64 points by xkarga00 12y ago

davidw 12y ago
Here's another kind of interesting/kind of flamey one: Node.js vs Erlang: https://groups.google.com/forum/#!msg/erlang-programming/ufNoiKcx1N0/L9o5Wvh7Um4J https://groups.google.com/forum/#!msg/erlang-programming/ufN... I think the Erlang guys are not very good at marketing (in the broad sense) their system, which is a pity, because Erlang is very nice for some kinds of applications.
- mononcqc 12y ago
  It's very hard to market a system when the first (and often last) comment on it is inevitably about the syntax, which isn't going to change after 25 years or so, let's be honest, no matter unimportant it may be in the long run.
  - davidw 12y ago
    It certainly doesn't make things easier, but it's not impossible. Python has done pretty well, despite tons of people foaming at the mouth about "the white space issue". Maybe it could have done better without that, but I think it's been a very successful language, all things considered. Think about some of the articles from people like patio11, and what kind of ideas they might apply were they trying to sell something like Erlang.
    - mononcqc 12y ago
      Frankly, at this point I'd be happy to hear new opinions on it. What comes from us within the Erlang community seems to often be a repeat of itself. - Killer apps? done (Riak, CouchDB, RabbitMQ, Whatsapp, etc.) - Commercial use? done (Telcos, game companies, and so on) - Books? Done, 4-5 of them, getting more and more specialized even. - Static Type system? Well you can use Dialyzer and get some of it. The last things that seem to come up all the time are about documentation, the syntax, possibly renaming OTP (do people really get bogged down so much on an acronym?), and package management. There's no doubt to me a lot of work needs to be done regarding package management, but all previous attempts within the community more or less failed to bring something consistent, and we have rebar instead, with people fetching sources from git repositories and building them locally without always having proper versionning (and conflict resolution). Outside of this, there's little doubt in my mind that the unfamiliarity is the big issue, along with how hard it is to think in Erlang: nothing shared, immutable, with a Prolog look. Outside of all the rest, this is what I feel is the hardest, and fixing it means "don't be Erlang" (because books and whatnot seem to have a limited effect), which well, won't work as a solution for Erlang.
      - riquito 12y ago
        Well, personally I'd like to have some kind of namespace and do not have to prepend a personal string in front of every module I write (correct me if I'm wrong, I'm a newbie in Erlang). Until a little while ago the website http://www.erlang.org http://www.erlang.org looked old from any angle (I like the new design), but the documentation at http://www.erlang.org/doc/ http://www.erlang.org/doc/ feels really ancient. I know that the content is up-to-date, but at a first visit it seems like the documentation of a language that is not maintained (which is false). I think that when people start to learn something they want to either fill that they're learning something futuristic or that they're learning to build on the shoulders of giants; that page transmit me that the world has moved on and nobody cared to update the page. Erlang just needs better marketing.
        mononcqc 12y ago
        For namespacing, Erlang used to have packages to provide something a bit like that: http://www.erlang.se/publications/packages.html http://www.erlang.se/publications/packages.html They ended up being rarely used, and were eventually stripped out of the system as they ended up confusing regulars more than anything. The issue with trying to add namespacing to Erlang is that people think of namespacing modules, but they forget about the other global namespaces: process names, ETS table names, and so on. They'd need to be done all at once, or otherwise they risk giving you inconsistent results. For example say I namespace myapp.mymodule.erl, and inside of this I contact the process named 'mymodule' and the table also named 'mymodule'. If I'm not careful and pass that name around, will it still refer to a global namespace (which can clash), or will it now refer to a different process and table in another namespace? Fixing this requires changing a lot about the language, I think, and it's probably a far bigger challenge than it looks. For documentation: there's http://www.erlang.org/erldoc http://www.erlang.org/erldoc that's a searchable one, and http://erldocs.com/ http://erldocs.com/ that provides more modern design to the reference manuals. Erlang may need better marketing, but as a person from the community, I'd like to hear what I could do. "Just do it better" is hard to build on, I guess. It's reminiscent of "make the logo pop more" for designers.
        12y ago
  - mseri 12y ago
    There is Elixir [0], with its elegant Ruby-like syntax if that's the issue. [0]: http://www.elixir-lang.org http://www.elixir-lang.org
    - mononcqc 12y ago
      That's not marketing Erlang, that's marketing Elixir, though. On another note, I disagree with calling the Elixir syntax elegant, but that's purely a matter of taste at this point.
      - zaphar 12y ago
        Thats not completely accurate. When people talk about Erlang they are talking about two different things at the same time. 1. Erlang the functional language with a syntax inspired by prolog. 2. OTP and the Erlang Runtime. The first one is an annoyance you grow to tolerate and sometimes even love. The second one makes you a fan the first time you actually need fault tolerance. Elixer gives you the second one and arguably improves on the issues with the first one. All of which to say "Its more nuanced than you seem to want to make it".
        mononcqc 12y ago
        The distinction between language and runtime is right. I would disagree that Elixir improves issues of Erlang. I see it as plainly different, not a newer, better language on the Erlang VM. It does have the benefit of avoiding a few mistakes Erlang made (order of arguments in the standard library, for example), but for the vast majority of the time I spend developing in Erlang, that's a very minor part of it. The design objectives and decisions of the languages, the general tooling given (i.e. macros), and the approach the community takes to development has a much greater impact into how systems are shaped and built than the actual objective improvements they have done past Erlang mistakes that are the results of 25 years of existence, sealed in place through backwards compatibility promises. These are often not improvements, just a different way of doing it, and whether it's better or not will absolutely depend on the task at hand.
  - lostcolony 12y ago
    And not to resume those arguments, but it's a red herring. Erlang benefits from having unfamiliar syntax. You end up learning the new paradigm as you learn the new syntax; it's too easy to shoehorn the old paradigm in if it's the old syntax ("I can write FORTRAN in any language").
  - gbhn 12y ago
    I don't understand defenses of programming languages which seem to assume that syntax isn't a central issue. Syntax is the central issue of a programming language -- they all have very similar capabilities, in the end (thanks Alan Turing), and the core of a language is in how those capabilities are expressed in the syntax. If most people find the syntax any of {awkward, intimidating, unreadable, inscrutable, undesirable} then they won't use it unless they have to. This means programming languages are path-dependent. Perhaps in a different world, lisp-type syntax is how people think about programming. Or maybe in a different world Haskell syntax is the norm. But we live in this world, and in this world, such syntax is pretty much all of the above. This makes it harder for people to read and understand programs written in those languages. Since that's ultimately the central point of a programming language -- to make programs readable to human beings -- syntax is the primary thing on which languages are evaluated. Obviously there are other factors like available libraries, tools, platform support, and so forth, but syntax is an extremely important pillar.
    - mononcqc 12y ago
      Semantics is the central issue of programming languages, not syntax. The syntax defines the form of a valid program, but gives no information about what it means. Semantics define what the execution of that program would be. For example, 'X = X+1' can be valid by the syntax of two languages, except one of them (say Erlang), will fail to do the pattern matching defined under operator '=', whereas the other will do an assignment where 'X' is now worth its former value plus one. There is a lot more meaning and deeper implications to defining what 'x = x+1' means than defining how to write it. Another example can be '1 + 3 * 5': this is an addition and a multiplication, but what's the operator precedence? In smalltalk, it would be '(1 + 3) * 5'. In forth it has another entirely different meaning. You can think of it this way: Erlang the language can have a mostly-equivalent semantic set of operations in LFE, which is a lisp. It could have had semantic equivalence with Elixir's syntax, but it didn't (because Elixir made different decisions with re-binding and whatnot). Even if Erlang had Elixir's syntax, it doesn't mean you'd have to stop caring about: pattern matching, recursion, shared-nothing, etc. Syntax is important, but it's not nearly as important or challenging as semantics are.
    - rdtsc 12y ago
  - iopq 12y ago
    C syntax is awful. So much crap just to call a function. a(b, c); in some languages it's just a b c (Haskell)
    - pessimizer 12y ago
      Blasphemy! Languages can only be criticized for not looking like C, and if they actually are C, they can only be criticized for using pointers and allowing memory management. Downvoted to oblivion.
    - oscargrouch 12y ago
      if i see: a b c 1 2 3 g a b what is that? sudoku? complete the phrase? too little syntax.. it doesnt say what it does.. besides f(x) is is math for centuries ;)
      - iopq 12y ago
        a(b)(c) which is then curried to a(b, c) if a is a function that takes two arguments (1)(2)(3) since they are literals it's probably an argument list to a function, but not valid by itself g(a)(b) etc. remember, in Haskell pretty much everything is a function
  - NDizzle 12y ago
    I kind of like the syntax. I've been trying to learn erlang this year. When I put on my "erlang hat" - I think it's kind of like Bo Jackson leaving the baseball field and preparing to play football. It's just wildly different than the (shitty web stuff, mostly) things I've used in the past. I just hope I don't dislocate a thigh.
    - saraid216 12y ago
      > I just hope I don't dislocate a thigh. Eh. Let it crash.
  - regularfry 12y ago
    It's also hard to market a system which introduces the New Shiny very slowly. How long did it take to get maps in, for instance? I mean, I totally understand, and to a large extent approve of, their conservatism, but "this ecosystem is boring in a good way" is a hard sell to a generation brought up on 15 minute blog videos.
    - ryanobjc 12y ago
      Also "the ecosystem is boring in a good way" doesnt fly when... well... strings.
      - klibertp 12y ago
        Stop that. IO List and Binaries (look at Elixir, also Cowboy and pretty much every optimized piece of Erlang code) solved this problem quite some time ago. Yeah, more syntactic sugar would be nice, but then - unlike many other languages - you can just write a parse transform and be done with it.
        davidw 12y ago
        Strings are not a 'solved problem' in Erlang. Also "just write a parse transform" is not really encouraged very much because it'll make your code hard to read and maintain, something which is valued in Erlang land more than some super-tricky piece of really clever coding.
- pessimizer 12y ago
  I never understand these complaints. Erlang will need to market itself once you start seeing unemployed Erlang programmers. All marketing Erlang does for Erlang programmers at this point is create competition for them, and lower their salaries. If anyone should be marketing Erlang, it's a company that relies on it and wants to lower labor costs, or even better a company that licenses an application that requires on-site Erlang expertise. In my opinion, Erlang is already where it needs to be, and new things happen for it every month or two that completely blow my mind. Why should Erlang care that people want to use node.js for everything that Erlang does better?
  - rz2k 12y ago
    >Erlang will need to market itself once you start seeing unemployed Erlang programmers. All marketing Erlang does for Erlang programmers at this point is create competition for them I think you're getting at the idea that marketing a language stimulates demand for programmers or it stimulates the supply of programmers. If there's a fixed number of positions for Erlang programmers more proficient people to fill those positions will lower wages. However, if the marketing convinces people who have problems to solve, that Erlang and the work Erlang programmers can do is the solution then demand will increase. However, whereas econ 101 helps identify some of the central concepts, later courses would explore the dynamics in greater detail. For example, languages derive value from their communities and the network effects. Or, someone who is called a Erlang programmer could program in many other languages, but may enjoy Erlang more, or believe they can be more productive if they're able to use Erlang. Anyway, it makes me think of open source projects where there are difficult people. You can tell non-paying, non-customers they don't have to use the work you've publicly released for free when they find problems, but presumably you're deriving some utility from releasing the software, and your utility function probably isn't served by getting your work ignored. Even if advocacy only encouraged new programmers rather than marketing the language to people who have problems to solve, I think that advocates for the language want its usage to grow. There are language communities where people talk about proficiency as some sort of secret gold mine, but I think those 'secret' high-paying jobs are probably involve a lot of uninteresting maintenance of legacy code.
  - vithlani 12y ago
zaphar 12y ago
I've never really understood the desire to compare Go and Erlang. They serve radically different purposes. The only thing they share are processes/goroutines (or greenlets, green threads, fibers, whatever you want to call them). A cheap small footprint concurrency primitive. Go was created to make buildng a single server (in the software not hardware sense) easier. Erlang was created to create systems for managing a lot of servers with a complicated dependency hierarchy. Go doesn't have OTP and a fault tolerant runtime because Google has all that stuff at a separate layer in their datacenters and the Go engineers didn't feel a need to solve that problem. They wanted to solve the problem of still having to build http servers in C++ for performance and all the attendant annoyances that brings. If I were going to build a massive distributed system today I'd use the Erlang runtime to manage the overall system in a fault tolerant way and I'd use Go to build the components. They complement themselves well but they don't really replace each other.
- mratzloff 12y ago
  A cogent response. I didn't get far into the thread because it seemed like no one had any significant experience in Go and therefore they were not qualified to debate each language's relative merits. Maybe it improved after the point I stopped.
  - zaphar 12y ago
    It's more cogent I think because I'm a fan of both languages and have done non trivial work in both. The thread was short on people with both experience in Go and with knowledge of the motivations for Go.
- regularfry 12y ago
  It's all about the reader, and very little about the languages themselves. Erlang and Go are candidate "next language to learn" entries for a lot of people at the moment: Go because it's new(ish), it's shiny, but it's stable enough and there are enough success stories about to convince PHB's that it's not a risk; and Erlang, because ZOMG UPTIME. They appear together because they superficially share enough that someone interested in solving problems with one is likely to be doing something that the other can take a reasonable stab at, even if it's not in the sweet spot. And they both sell themselves hard on the "concurrency" angle, despite not necessarily meaning quite the same thing when they say it.
oinksoft 12y ago
Loïc Hogun (author of Cowboy, other projects) hits the nail on the head: For me Erlang is first fault tolerant, then concurrent, then functional, yet for many people it seems to be the opposite order. I personally care very little about Erlang being functional (though I do care a great deal about immutability and pattern matching being the default behavior, the rest not so much), and the concurrency is nice but only because it enables all the fault tolerance features of the language. I've yet to encounter anything as good as OTP for building fault-tolerant systems. Go is not designed for safety like Erlang/OTP, and as far as I know there is no concept of supervision with Go routines/channels, etc. Go is no "ultimate antagonist to Erlang" as OP hypothesized.
- craigyk 12y ago
  yup, but Go sure would be nicer if they added some good pattern matching...
saraid216 12y ago
So, while that was... odd, there were some links buried in there that I found to be interesting reading: http://carlos-trigoso.com/2014/03/07/out-of-the-labyrinth-of-metaphysics-v-001/ http://carlos-trigoso.com/2014/03/07/out-of-the-labyrinth-of... (Or the Abstractitude of the Hewitt Actor Model.) http://jlouisramblings.blogspot.se/2012/10/ramblings-on-thesis-of-bjarne-dacker.html http://jlouisramblings.blogspot.se/2012/10/ramblings-on-thes... (Or a summary of the original problems Erlang was trying to address.)

64 points by xkarga00 12y ago

Here's another kind of interesting/kind of flamey one: Node.js vs Erlang: https://groups.google.com/forum/#!msg/erlang-programming/ufNoiKcx1N0/L9o5Wvh7Um4J https://groups.google.com/forum/#!msg/erlang-programming/ufN... I think the Erlang guys are not very good at marketing (in the broad sense) their system, which is a pity, because Erlang is very nice for some kinds of applications.

mononcqc 12y ago
It's very hard to market a system when the first (and often last) comment on it is inevitably about the syntax, which isn't going to change after 25 years or so, let's be honest, no matter unimportant it may be in the long run.
- davidw 12y ago
  It certainly doesn't make things easier, but it's not impossible. Python has done pretty well, despite tons of people foaming at the mouth about "the white space issue". Maybe it could have done better without that, but I think it's been a very successful language, all things considered. Think about some of the articles from people like patio11, and what kind of ideas they might apply were they trying to sell something like Erlang.
  - mononcqc 12y ago
    Frankly, at this point I'd be happy to hear new opinions on it. What comes from us within the Erlang community seems to often be a repeat of itself. - Killer apps? done (Riak, CouchDB, RabbitMQ, Whatsapp, etc.) - Commercial use? done (Telcos, game companies, and so on) - Books? Done, 4-5 of them, getting more and more specialized even. - Static Type system? Well you can use Dialyzer and get some of it. The last things that seem to come up all the time are about documentation, the syntax, possibly renaming OTP (do people really get bogged down so much on an acronym?), and package management. There's no doubt to me a lot of work needs to be done regarding package management, but all previous attempts within the community more or less failed to bring something consistent, and we have rebar instead, with people fetching sources from git repositories and building them locally without always having proper versionning (and conflict resolution). Outside of this, there's little doubt in my mind that the unfamiliarity is the big issue, along with how hard it is to think in Erlang: nothing shared, immutable, with a Prolog look. Outside of all the rest, this is what I feel is the hardest, and fixing it means "don't be Erlang" (because books and whatnot seem to have a limited effect), which well, won't work as a solution for Erlang.
    - riquito 12y ago
      Well, personally I'd like to have some kind of namespace and do not have to prepend a personal string in front of every module I write (correct me if I'm wrong, I'm a newbie in Erlang). Until a little while ago the website http://www.erlang.org http://www.erlang.org looked old from any angle (I like the new design), but the documentation at http://www.erlang.org/doc/ http://www.erlang.org/doc/ feels really ancient. I know that the content is up-to-date, but at a first visit it seems like the documentation of a language that is not maintained (which is false). I think that when people start to learn something they want to either fill that they're learning something futuristic or that they're learning to build on the shoulders of giants; that page transmit me that the world has moved on and nobody cared to update the page. Erlang just needs better marketing.
      - mononcqc 12y ago
        For namespacing, Erlang used to have packages to provide something a bit like that: http://www.erlang.se/publications/packages.html http://www.erlang.se/publications/packages.html They ended up being rarely used, and were eventually stripped out of the system as they ended up confusing regulars more than anything. The issue with trying to add namespacing to Erlang is that people think of namespacing modules, but they forget about the other global namespaces: process names, ETS table names, and so on. They'd need to be done all at once, or otherwise they risk giving you inconsistent results. For example say I namespace myapp.mymodule.erl, and inside of this I contact the process named 'mymodule' and the table also named 'mymodule'. If I'm not careful and pass that name around, will it still refer to a global namespace (which can clash), or will it now refer to a different process and table in another namespace? Fixing this requires changing a lot about the language, I think, and it's probably a far bigger challenge than it looks. For documentation: there's http://www.erlang.org/erldoc http://www.erlang.org/erldoc that's a searchable one, and http://erldocs.com/ http://erldocs.com/ that provides more modern design to the reference manuals. Erlang may need better marketing, but as a person from the community, I'd like to hear what I could do. "Just do it better" is hard to build on, I guess. It's reminiscent of "make the logo pop more" for designers.
        12y ago
- mseri 12y ago
  There is Elixir [0], with its elegant Ruby-like syntax if that's the issue. [0]: http://www.elixir-lang.org http://www.elixir-lang.org
  - mononcqc 12y ago
    That's not marketing Erlang, that's marketing Elixir, though. On another note, I disagree with calling the Elixir syntax elegant, but that's purely a matter of taste at this point.
    - zaphar 12y ago
      Thats not completely accurate. When people talk about Erlang they are talking about two different things at the same time. 1. Erlang the functional language with a syntax inspired by prolog. 2. OTP and the Erlang Runtime. The first one is an annoyance you grow to tolerate and sometimes even love. The second one makes you a fan the first time you actually need fault tolerance. Elixer gives you the second one and arguably improves on the issues with the first one. All of which to say "Its more nuanced than you seem to want to make it".
      - mononcqc 12y ago
        The distinction between language and runtime is right. I would disagree that Elixir improves issues of Erlang. I see it as plainly different, not a newer, better language on the Erlang VM. It does have the benefit of avoiding a few mistakes Erlang made (order of arguments in the standard library, for example), but for the vast majority of the time I spend developing in Erlang, that's a very minor part of it. The design objectives and decisions of the languages, the general tooling given (i.e. macros), and the approach the community takes to development has a much greater impact into how systems are shaped and built than the actual objective improvements they have done past Erlang mistakes that are the results of 25 years of existence, sealed in place through backwards compatibility promises. These are often not improvements, just a different way of doing it, and whether it's better or not will absolutely depend on the task at hand.
- lostcolony 12y ago
  And not to resume those arguments, but it's a red herring. Erlang benefits from having unfamiliar syntax. You end up learning the new paradigm as you learn the new syntax; it's too easy to shoehorn the old paradigm in if it's the old syntax ("I can write FORTRAN in any language").
- gbhn 12y ago
  I don't understand defenses of programming languages which seem to assume that syntax isn't a central issue. Syntax is the central issue of a programming language -- they all have very similar capabilities, in the end (thanks Alan Turing), and the core of a language is in how those capabilities are expressed in the syntax. If most people find the syntax any of {awkward, intimidating, unreadable, inscrutable, undesirable} then they won't use it unless they have to. This means programming languages are path-dependent. Perhaps in a different world, lisp-type syntax is how people think about programming. Or maybe in a different world Haskell syntax is the norm. But we live in this world, and in this world, such syntax is pretty much all of the above. This makes it harder for people to read and understand programs written in those languages. Since that's ultimately the central point of a programming language -- to make programs readable to human beings -- syntax is the primary thing on which languages are evaluated. Obviously there are other factors like available libraries, tools, platform support, and so forth, but syntax is an extremely important pillar.
  - mononcqc 12y ago
    Semantics is the central issue of programming languages, not syntax. The syntax defines the form of a valid program, but gives no information about what it means. Semantics define what the execution of that program would be. For example, 'X = X+1' can be valid by the syntax of two languages, except one of them (say Erlang), will fail to do the pattern matching defined under operator '=', whereas the other will do an assignment where 'X' is now worth its former value plus one. There is a lot more meaning and deeper implications to defining what 'x = x+1' means than defining how to write it. Another example can be '1 + 3 * 5': this is an addition and a multiplication, but what's the operator precedence? In smalltalk, it would be '(1 + 3) * 5'. In forth it has another entirely different meaning. You can think of it this way: Erlang the language can have a mostly-equivalent semantic set of operations in LFE, which is a lisp. It could have had semantic equivalence with Elixir's syntax, but it didn't (because Elixir made different decisions with re-binding and whatnot). Even if Erlang had Elixir's syntax, it doesn't mean you'd have to stop caring about: pattern matching, recursion, shared-nothing, etc. Syntax is important, but it's not nearly as important or challenging as semantics are.
  - rdtsc 12y ago
- iopq 12y ago
  C syntax is awful. So much crap just to call a function. a(b, c); in some languages it's just a b c (Haskell)
  - pessimizer 12y ago
    Blasphemy! Languages can only be criticized for not looking like C, and if they actually are C, they can only be criticized for using pointers and allowing memory management. Downvoted to oblivion.
  - oscargrouch 12y ago
    if i see: a b c 1 2 3 g a b what is that? sudoku? complete the phrase? too little syntax.. it doesnt say what it does.. besides f(x) is is math for centuries ;)
    - iopq 12y ago
      a(b)(c) which is then curried to a(b, c) if a is a function that takes two arguments (1)(2)(3) since they are literals it's probably an argument list to a function, but not valid by itself g(a)(b) etc. remember, in Haskell pretty much everything is a function
- NDizzle 12y ago
  I kind of like the syntax. I've been trying to learn erlang this year. When I put on my "erlang hat" - I think it's kind of like Bo Jackson leaving the baseball field and preparing to play football. It's just wildly different than the (shitty web stuff, mostly) things I've used in the past. I just hope I don't dislocate a thigh.
  - saraid216 12y ago
    > I just hope I don't dislocate a thigh. Eh. Let it crash.
- regularfry 12y ago
  It's also hard to market a system which introduces the New Shiny very slowly. How long did it take to get maps in, for instance? I mean, I totally understand, and to a large extent approve of, their conservatism, but "this ecosystem is boring in a good way" is a hard sell to a generation brought up on 15 minute blog videos.
  - ryanobjc 12y ago
    Also "the ecosystem is boring in a good way" doesnt fly when... well... strings.
    - klibertp 12y ago
      Stop that. IO List and Binaries (look at Elixir, also Cowboy and pretty much every optimized piece of Erlang code) solved this problem quite some time ago. Yeah, more syntactic sugar would be nice, but then - unlike many other languages - you can just write a parse transform and be done with it.
      - davidw 12y ago
        Strings are not a 'solved problem' in Erlang. Also "just write a parse transform" is not really encouraged very much because it'll make your code hard to read and maintain, something which is valued in Erlang land more than some super-tricky piece of really clever coding.
pessimizer 12y ago
I never understand these complaints. Erlang will need to market itself once you start seeing unemployed Erlang programmers. All marketing Erlang does for Erlang programmers at this point is create competition for them, and lower their salaries. If anyone should be marketing Erlang, it's a company that relies on it and wants to lower labor costs, or even better a company that licenses an application that requires on-site Erlang expertise. In my opinion, Erlang is already where it needs to be, and new things happen for it every month or two that completely blow my mind. Why should Erlang care that people want to use node.js for everything that Erlang does better?
- rz2k 12y ago
  >Erlang will need to market itself once you start seeing unemployed Erlang programmers. All marketing Erlang does for Erlang programmers at this point is create competition for them I think you're getting at the idea that marketing a language stimulates demand for programmers or it stimulates the supply of programmers. If there's a fixed number of positions for Erlang programmers more proficient people to fill those positions will lower wages. However, if the marketing convinces people who have problems to solve, that Erlang and the work Erlang programmers can do is the solution then demand will increase. However, whereas econ 101 helps identify some of the central concepts, later courses would explore the dynamics in greater detail. For example, languages derive value from their communities and the network effects. Or, someone who is called a Erlang programmer could program in many other languages, but may enjoy Erlang more, or believe they can be more productive if they're able to use Erlang. Anyway, it makes me think of open source projects where there are difficult people. You can tell non-paying, non-customers they don't have to use the work you've publicly released for free when they find problems, but presumably you're deriving some utility from releasing the software, and your utility function probably isn't served by getting your work ignored. Even if advocacy only encouraged new programmers rather than marketing the language to people who have problems to solve, I think that advocates for the language want its usage to grow. There are language communities where people talk about proficiency as some sort of secret gold mine, but I think those 'secret' high-paying jobs are probably involve a lot of uninteresting maintenance of legacy code.
- vithlani 12y ago

zaphar 12y ago

I've never really understood the desire to compare Go and Erlang. They serve radically different purposes. The only thing they share are processes/goroutines (or greenlets, green threads, fibers, whatever you want to call them). A cheap small footprint concurrency primitive. Go was created to make buildng a single server (in the software not hardware sense) easier. Erlang was created to create systems for managing a lot of servers with a complicated dependency hierarchy. Go doesn't have OTP and a fault tolerant runtime because Google has all that stuff at a separate layer in their datacenters and the Go engineers didn't feel a need to solve that problem. They wanted to solve the problem of still having to build http servers in C++ for performance and all the attendant annoyances that brings. If I were going to build a massive distributed system today I'd use the Erlang runtime to manage the overall system in a fault tolerant way and I'd use Go to build the components. They complement themselves well but they don't really replace each other.

mratzloff 12y ago
A cogent response. I didn't get far into the thread because it seemed like no one had any significant experience in Go and therefore they were not qualified to debate each language's relative merits. Maybe it improved after the point I stopped.
- zaphar 12y ago
  It's more cogent I think because I'm a fan of both languages and have done non trivial work in both. The thread was short on people with both experience in Go and with knowledge of the motivations for Go.
regularfry 12y ago
It's all about the reader, and very little about the languages themselves. Erlang and Go are candidate "next language to learn" entries for a lot of people at the moment: Go because it's new(ish), it's shiny, but it's stable enough and there are enough success stories about to convince PHB's that it's not a risk; and Erlang, because ZOMG UPTIME. They appear together because they superficially share enough that someone interested in solving problems with one is likely to be doing something that the other can take a reasonable stab at, even if it's not in the sweet spot. And they both sell themselves hard on the "concurrency" angle, despite not necessarily meaning quite the same thing when they say it.

oinksoft 12y ago

Loïc Hogun (author of Cowboy, other projects) hits the nail on the head: For me Erlang is first fault tolerant, then concurrent, then functional, yet for many people it seems to be the opposite order. I personally care very little about Erlang being functional (though I do care a great deal about immutability and pattern matching being the default behavior, the rest not so much), and the concurrency is nice but only because it enables all the fault tolerance features of the language. I've yet to encounter anything as good as OTP for building fault-tolerant systems. Go is not designed for safety like Erlang/OTP, and as far as I know there is no concept of supervision with Go routines/channels, etc. Go is no "ultimate antagonist to Erlang" as OP hypothesized.

craigyk 12y ago
yup, but Go sure would be nicer if they added some good pattern matching...

saraid216 12y ago

So, while that was... odd, there were some links buried in there that I found to be interesting reading: http://carlos-trigoso.com/2014/03/07/out-of-the-labyrinth-of-metaphysics-v-001/ http://carlos-trigoso.com/2014/03/07/out-of-the-labyrinth-of... (Or the Abstractitude of the Hewitt Actor Model.) http://jlouisramblings.blogspot.se/2012/10/ramblings-on-thesis-of-bjarne-dacker.html http://jlouisramblings.blogspot.se/2012/10/ramblings-on-thes... (Or a summary of the original problems Erlang was trying to address.)