7 ms·

According to the author Go make concurrent programming "the best experience, by far, compared to other popular programming languages today." I beg to differ. I

• vvanders 8y ago
  I think the main argument is that Elixir isn't as mainstream which is a fair point. That said I agree with everything, Erlang pioneered in this space and has shown to scale very well[1] in a proven way over the last few decades. [1] https://phoenixframework.org/blog/the-road-to-2-million-websocket-connections https://phoenixframework.org/blog/the-road-to-2-million-webs...
  • mirceal 8y ago
    Yes. Because mainstream is what you should select for when choosing your tools. On a more serious note: I’m very wary of people that have discovered the one true language, framework, etc. That’s how you end up with 100 lines of go instead a one line bash script. That’s how you end up with “java developers” that are more concerned with design patterns instead of actual working code. I could go on. Learn about as many things possible, form your own opinions, choose the right tool for the job.
    • hmschreck 8y ago
      We had a developer interview here who was an Elixir zealot - and I use that word entirely purposefully. He was very adamant that we needed to rewrite our entire platform in Elixir because it was obviously better. We ended up not hiring; he refused to touch certain technologies that make up a core part of our stack (Node being the biggest issue), and he was honestly something of a massive tool -- on our take-home thing (takes most developers maybe a few hours) he limited himself to one hour, didn't get it done, wasn't even solving the right problem, and, when he sent in his solution... "It's ok, I know you won't get it, but that's OK."
      • EpicEng 8y ago
        Run, run far away... (I realize you did, but man...)
      • mirceal 8y ago
        a zealot is a zealot is a zealot. you don't get much info from the strong preferences of a zealot. you just quickly learn that you need to avoid them. refusing to touch the tech stack of the person that pays your bills if flat out stupid. if you don't touch it why am I hiring you? depending on how much experience this person had this behavior may be correctable if he/she is lucky enough to find a more senior developer that can show them how their [stupid] choices impact the project and how they can eliminate whole classes of problems by choosing the right tool.
      • fnordsensei 8y ago
        Being selective about the language you work with is entirely valid. But why would you go to an interview where they're not looking for your language and try to convince them otherwise? It seems futile.
        • tsmarsh 8y ago
          I had a weird experience where I was offered an interview at a company I respected, but who used ruby a lot. I explained that to everyone in the chain that I'd want to try and work to change that, and eventually got rejected because I didn't like ruby. It was a weird experience. But I got a nice lunch out of it. I'm still not sure what they got out of it.
    • CydeWeys 8y ago
      I've found that being mainstream is the most important factor in choosing tooling. Being mainstream has incredible advantages. It means you're going to find lots of help, resources, answers to questions, sample code, and high quality and well maintained libraries.
      • mmjaa 8y ago
        .. and of course, the old standard, if its mainstream .. you are replaceable.
        • fixermark 8y ago
          Totally agree, with the added observation that as a software engineer, I want to be replaceable. If my software can't be divorced from its creator, it can't outlive me. I don't want to be glued to my work inextricably; if you can't be replaced, you can't be promoted.
          • mirceal 8y ago
            being replaceable is a noble goal. the problem is that maybe some people don't want to be replaceable and maybe they want/seek to gain some kind of job security through the tooling they use, their idiosyncratic processes or just through rejection of new technology. those people are IMHO doomed to obsolescence.
        • nicheftw93 8y ago
          Anecdote time: making yourself too specialized makes you easily replaceable too. At a previous gig, a problem dev, who insisted on only using Erlang, was painted into a corner by eng at large who did not want to learn/support another language (Ruby, Python, JS, Java, and R were all over). This dev eventually got fired, as they didn't really contribute much to "the big picture". Since their efforts were so limited in scope, their Erlang work was quickly replaced using the other languages, and consumers of the results never noticed. YMMV. But that's a old standard that should probably die
      • cube2222 8y ago
    • EpicEng 8y ago
      >Yes. Because mainstream is what you should select for when choosing your tools It's a hugely important consideration. More devs, larger community, better support, more/better tooling, more libs, etc. If you don't think those matter then you're only concerned with pet/toy projects.
      • fnordsensei 8y ago
        There's also a zero chance of working with anything that's better than mainstream.
        • EpicEng 8y ago
          Ummm... ok? I don't know about you, but I like building things that solve problems. Tools are important, but they're not a goal unto themselves. If your 'better' language is beautiful, but lacks the ecosystem people solving real problems actually need to get work done, it's not actually better.
          • fnordsensei 8y ago
            Language is too restrictive to consider in isolation if we're talking about "the tools". And I'm personally more interested in effectiveness than beauty, although I'll grant that beauty could have some influence on effectiveness perhaps. Ecosystem is not a binary proposition: either there, or not there. At some point the ecosystem becomes solid enough for some purposes. Finally, if no outliers were ever a better choice than the status quo, the status quo would never change. Therefore, there are always some outliers that can be chosen for greater effect at the cost of accepting some perceived risk. Using tooling smack in the middle of the average zeroes the potential increase in effectiveness as well as the perceived risk.
    • xor1 8y ago
      >Yes. Because mainstream is what you should select for when choosing your tools. Ease of hiring experienced developers should absolutely be a part of selection criteria, but of course it should not be the only one. What good is it going to do you when you picked Elixir/Scala/Rust over Python/Go/Ruby, you need to hire senior engineers who can hit the ground running ASAP, and you have limited resources/budget? It's going to be harder to find them (especially if you're not in SF), it's a harder/longer initial learning curve if you hire senior engineers without prior experience, it's going to be harder to find non-seniors, you're going to have to pay more to get what you want...the list goes on.
      • mirceal 8y ago
        a senior developer, by definition, will hit the ground running with mostly anything you use. that's the senior part in senior developer. also if you believe that people need years of use to be good in any language/tools/framework you need to figure out how to attract better people. also, the question you need to ask yourself is: do you want to build something with a technology you've selected and think it's the best or do you want to have someone that can pick the right tool for the job pick the tech? sometimes, not building something or various parts of something is more valuable that building something that you don't need fast.
        • xor1 8y ago
          >a senior developer, by definition, will hit the ground running with mostly anything you use. that's the senior part in senior developer. a senior developer also gets to be picky in what stacks they want to work with. usually it's what they are familiar and comfortable with, or something similar to it >also if you believe that people need years of use to be good in any language/tools/framework you need to figure out how to attract better people. even the best engineers have ramp-up time when starting a new job that involves a new code base. that ramp-up time is increased significantly when it's a language that they aren't familiar with. feel free to convince me otherwise, im all ears >sometimes, not building something or various parts of something is more valuable that building something that you don't need fast. what about when it's not?
      • 8y ago
• rwcarlsen 8y ago
  I think most reasonable people wouldn't have trouble defending a position that Elixir isn't a particularly "popular" language - at least compared to Go.
  • erokar 8y ago
    I agree Go is more popular than Elixir — but is it actually a popular language? At least I wouldn't consider it mainstream in the sense Java, C# and Python are.
    • hyperpape 8y ago
      It doesn’t really matter where you draw “the” line for mainstream languages, so much as that there is some reasonably drawn line between Go and Erlang/Elixir.
    • JepZ 8y ago
      Well, just ask the Toibe index: https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/ It looks like Elixier ist by far less popular than the other discussed languages.
      • CydeWeys 8y ago
        Huh, I'm super surprised that VB .NET is growing. I used it at my last job briefly for unfortunate historical reasons and we were trying to run screaming away from it as fast as possible to C#. It felt like the runt of the litter of the .NET ecosystem; so many things worked better in C#.
      • TJSomething 8y ago
        I personally prefer the RedMonk rankings [1] over TIOBE, since TIOBE's entirely about Google hits, which lags as an activity indicator by a few years, because sites for languages that have stopped being used stay around for years. Also, Google hits counts are really noisy, especially for languages that have names that are also words, like Go and Elixir. RedMonk uses recent GitHub and Stack Overflow activity as a proxy for popularity. In this case though, Elixir is still way lower, at somewhere around 30th compared to Go's 14th. [1] https://redmonk.com/sogrady/2018/08/10/language-rankings-6-18/ https://redmonk.com/sogrady/2018/08/10/language-rankings-6-1...
• alberth 8y ago
  I really wish someone like Mike Pall (of LuaJIT fame) would work on BEAM to make it computationally as fast as Go on raw performance.
  • siscia 8y ago
    The architecture of the BEAM is quite complex. I don't believe you could reach the same raw performance that you have with go. However it is an unfair comparison, BEAM processes do much more than coroutines.
  • macintux 8y ago
    Erlang, I think, is crippled out of the box wrt performance by its emphasis on immutable data, live troubleshooting, small processes with lots of messaging, etc. These are the things that make it a brilliant language for use cases where it's well-suited. Not every language has to be a kitchen sink language like Java, thankfully. I like opinionated languages with well-defined strengths and weaknesses.
  • jlouis 8y ago
    The recent Erlang release (21) changed a lot of the internal interpreter structure with a nod in Mike Pall's direction. Just by shortening the typical opcode size down, they gained 20% speed boost. And the BEAM is a pretty good interpreter anyway. JITing the beast has been a want for a while, but there are also other paths taken right now which can provide speed boosts, among other a translation of the compiler to use SSA-representations.
  • notriddle 8y ago
    The BEAM is already much more performant than, for example, the Ruby reference implementation. And look at what people have managed to build with Ruby!
    • jashmatthews 8y ago
      Erlang 19 is only 10% faster than CRuby 2.3 on a simple factorial bench. Web throughput is even closer as lots of it is C extensions. I haven't made the comparison myself for a while but I suspect it's still very close.
• le-mark 8y ago
  How are the deployment, library ecosystem, build, and tooling stories for Elixir? Note I don't really care about the answer to the above, I just wish as a profession we could get past the tribalism and boosterism and have rational technical dicussions about things that matter as opposed to banal declarations about 'expressiveness' etc.
  • xyproto 8y ago
    Implementing a 3D vector or quaternion library in Go feels like a really bad fit, mainly due to the lack of operator overloading (which can easily be abused, like >> in C++). But it is an example of a field where Go allows programmer to express their ideas in a less direct way. I think Go is great, but I don't think describing parts of it as less expressive than some other languages is banal. Expressiveness has a sweet spot, though. Too many keywords and constructs makes a language harder to learn, and makes it too easy for developers to build their own little weird worlds that discourages team work and lowers readability.
    • fixermark 8y ago
      That exists, so we can look at at least one concrete attempt to evaluate the question. [https://github.com/go-gl/mathgl https://github.com/go-gl/mathgl]. And right off the bat, the first thing a person notices is that there are two identical sub-libraries, mgl32 and mgl64, to work around the language's constraint that the core numeric type in the library cannot be parameterized at the language level without performance-losing reflection.
      • jeremejevs 8y ago
        mgl64 is generated from mgl32 though [0], so no big deal, no? Who's hurt by this? [0] https://github.com/go-gl/mathgl#contributing https://github.com/go-gl/mathgl#contributing
        • fixermark 8y ago
          Well, let me just do a quick text-based search for the Vec3 implementation and... ... oh. There's three. The one in mgl64, the one in mgl32, and the canonical one that a developer should edit to make changes. And they only all stay synchronized if the developer remembers to follow the contributor practice and run that gen script, which is not enforced by anything. On a small project like this, not a big deal. But it's indicative of the over-arching problem of the approach go is necessitating here. There's noise here that a developer has to think around, and as a project scales up, that noise is going to become louder and trend towards intractable complexity.
• brightball 8y ago
  You’re not wrong. No matter the available constructs, there on concurrency guarantees that you can’t make in any language with a shared memory model. Everything has tradeoffs.