‹ BackHN Continuity

Thread

Go Concurrency Distilled

402 points · 187 comments · chmaynard

  1. SamInTheShell · · focus · HN ↗
    The concurrency and threading in Go just feels like magic compared to every other language. I'm a goroutine addict and I refuse to be rehabilitated.

    Just from observations over the years, I don't think there's any other language quite like this, in terms of how things can end up happening in any thread.

    1. hank1931 · · focus · HN ↗
      How about Erlang or Elixir using BEAM?

      Supposedly WhatsApp scaled to serving over 1 billion users with Erlang and BEAM.

      RabbitMQ, used by Reddit, uses Erlang and BEAM.

      Discord uses Elixer and BEAM.

      I just traveled down the BEAM rabbit hole. Fascinating story. The Ericsson Computer Science Laboratory cranked out some amazing products in the early 1990's.

      Their goal was five nines of reliability for Ericsson telephone switches.

      According to Joe Armstrong (an interesting fellow from Ericsson), the AXD301 ATM switch achieved nine nines over a nine-month period using Erlang and BEAM in 2002. That calculates out to 24 milliseconds of downtime.

      1. CoolestBeans · · focus · HN ↗
        BEAM+OTP is a masterclass in using concurrency to achieve fault tolerance. But Go achieves its "magic" by feeling like the lingua francas of programming, C and C++. Go doesn't make the developer learn too many new concepts. The runtime is self enclosed in the final binary. This commitment to the familiar programming patterns also means it allows for concurrency anti-patterns like shared memory which for Erlang+OTP's design principles is verboten.
        1. winwang · · focus · HN ↗
          Slightly irrelevant but that's a part of my issue with Go. I personally feel the chances are slim that "familiar programming concepts" (i.e. as taught by most intro CS courses) are optimal by themselves. And I know it's an old thing, but the fact that Go was once adamantly against generics...
          1. throwaway894345 · · focus · HN ↗
            > I personally feel the chances are slim that "familiar programming concepts" (i.e. as taught by most intro CS courses) are optimal by themselves.

            On the other hand, Erlang has been out for ages and has largely failed to attract much adoption, so it doesn’t seem like the market finds it to be “optimal” either. Not that popularity is everything, but over time a language better languages should increase their market share, especially if your language got its start during an era where the competition was C and C++ and Java.

            > And I know it's an old thing, but the fact that Go was once adamantly against generics...

            Erlang not only lacks generics, but it lacks any static type system at all…

            1. OoooooooO · · focus · HN ↗
              Erlang is slow for compute.

              And most software does apparently not need what it offers.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.