‹ 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. jcgl · · focus · HN ↗
            The Go team as a whole was not adamantly against generics though, as I recall. Rather, they were against implementations that would have bad overall implications for the language (especially its complexity, both in usage and in implementation).

            Once a sufficiently good proposal was made, generics were adopted.

            1. jasonwatkinspdx · · focus · HN ↗
              It was considerably more messy than that but I don't want to dredge up old drama in detail.
Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.