9 ms·

Agreed. As a comparison Golang was sold as "CSP like Erlang without the weird syntax" but people realized channels kind of suck and goroutines are not really a

Agreed. As a comparison Golang was sold as "CSP like Erlang without the weird syntax" but people realized channels kind of suck and goroutines are not really a lot better than threads in other languages. The actual core of OTP was the supervisor tree but that's too complicated so Golang is basically just more concise Java. I don't think this is a bad thing but it's a funny consequence that to become mainstream you have to (1) announce a cool new feature that isn't in other languages (2) eventually accept the feature is actually pretty niche and your average developer won't get it (3) sand off the weird features to make another "C but slightly better/different"

pif 1y ago
[flagged]
- xyse53 1y ago
  I think that's harsh. IME Go excels in a business setting where the focus is on correct, performant, maintainable, business logic in larger organizations, that's easy to integrate with a bunch of other systems. You can't squeeze every last bit of low-level performance out of it but you can get ... 9x% of the way there with concurrent code that is easy to reason about.
  - TylerE 1y ago
    What matters is being 100x faster than python, not 5x slower than C++ or 2x slower than Java. Performant enough that IO (or network) rather than CPU is the bottleneck (in my limited experience). Personally I just far prefer to work in a GCed langauge. Much simpler mental model.
  - pif 1y ago
    > correct, performant, maintainable, business logic That's the requirement for 100% if professional software development.
- mcdoogal 1y ago
  Yikes, language flamebait in 2025?
  - zozbot234 1y ago
    Flamebait? It's literally what the designers of Golang said publicly about the background of prospective developers, and how that constrained the language design: "The key point here is our programmers are Googlers, they’re not researchers. They're typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They're not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt."
    - Degorath 1y ago
      Nowhere in this quote are these fresh grads equated to "lousy programmers", though (which the flamebaity comment did). And interpreting the quote charitably I'm going to have to agree with it - I don't think many of my coworkers care enough to get to the point where they'd appreciate everything something like Haskell can do for them.
      - ModernMech 1y ago
        Have you ever worked with fresh grads? They're definitionally lousy programmers, if we take lousy mean "having a propensity to inject bugs into programs".
    - binary132 1y ago
      The more time you spend in software engineering the more you realize that this is actually brilliant and helpful, not bad. And IME, the more expressivity I have fluently at my disposal, the more complexity I tend to create. I’m not saying I don’t enjoy more complex languages, but reducing cognitive load and easing collaboration with more junior engineers are easily the best features of Go, hands down (although I can’t say the new generics necessarily always help with that).
    - 1y ago
- Aeolun 1y ago
  I don’t like writing golang, but I sure like reading it. It’s nearly impossible not to understand.
- konart 1y ago
  Serious being what? Most programmers are "lousy programmers" because most of the are not researchers and have no interest in theory. I can write in Go or Rust (or anything else given some time) but I won't ever use Rust to write any kind of business logic for my company - and this is what I do most of the time I actually write code. Why? Because Rust is terrible for the job (at least if we are talking about real life scenario where the job should be done in hours and not weeks)
  - oneshtein 1y ago
    I can do business logic, like complex CRUD, in Rust much faster than in other languages. I assume, «lousy programmers» have problems with separation of concerns, which then cause problems with borrow checker, because developers need to perform different things in different ways on different parts of data structures (AKA «god object» anti-pattern).
    - konart 1y ago
      > separation of concerns but this would be a problem almost anywhere, no? This has nothing to do with Rust vs Go vs Ruby or something else. Rust makes this even bigger problem, ok, but I don't think we should call people not using Rust (c\c++ etc) "lousy". PS: tbh this kind of statements usually (from my experience) come from people who mainly write system level software or work with hardware directly.
- binary132 1y ago
  There are a lot of those for sure. There are far more in Python and Java. Any popular, simple-enough language will attract a horde of jobseeking mouthbreathers, that’s kind of inevitable and normal really.
fmbb 1y ago
> Golang is basically just more concise Java. That is exactly how it was sold. A safe C, or a nicer simpler Java. Nobody cared about Erlang back then and nobody does today. I write Erlang for a living.
- gdbsjjdn 1y ago
  I was an early Golang dev and people were _crazy_ with channels for a couple years. I remember the most popular Golang Kafka client was absolute spaghetti of channels and routines. It's never been "safe C" because it's garbage collected. Java is truly the comp because it's a great Grug language. I also wrote some Erlang in the past, I really enjoy it and I was sad that Go didn't borrow more.
  - tptacek 1y ago
    This is "share by communicating, don't communicate by sharing". Pretty much everyone agrees it's a good thought. ~Most programs get there just fine with channels, because ~most code isn't so performance sensitive that channel limitations matter. Go leaves plenty of room for the rest of programs to do something else. Seems good.
- nothrabannosir 1y ago
  I remember very well one of the first public presentations about Go. It focused heavily on goroutines and channels and included a live demonstration of pushing an element through one million channels. It also included a demo of spinning up three racing queries to the Google search engine using the select statement, and picking whoever returned first. it was all about the new cool feature. They also had TCP-over-channels and eventually had to remove that because the model didn’t fit. Nobody may have known they cared about Erlang, but those features sure made people pay attention.
- nine_k 1y ago
  Writing Elixir for a living is seemingly a growing trend.
- hardwaresofton 1y ago
nine_k 1y ago
Due to lack of many abstractions, and lack of exceptions, Go is a less concise Java. It's a language where the lack of expressiveness forces you to write simpler code. (Not that it helps too much.) Go's selling points are different: it takes a weekend to learn, and a week to become productive, it has a well-stocked standard library, it compiles quickly, runs quickly enough, and produces a single self-contained executable. I would say that Go is mostly a better Modula-2 (with bits of Oberon); it's only better from the language standpoint because now it has type parameters, but GC definitely helps make writing it simpler.
- tptacek 1y ago
  People sometimes say this like it's a dunk, but there's a finite amount of complexity any given programming task can shoulder, you have to allocate it somehow between the programming environment, the problem domain you're working on, and the algorithmic sophistication you bring to bear on that problem, and it's not clear to me what the benefit is in allocating more than you need to your programming language. A lot of very smart stuff is written in Go by programmers who just want the language to get the hell out of their way. Go is some ways very good at that. Rough though if you want your programming language to model your problem domain or your algorithmic approach! TANSTAAFL.
  - zozbot234 1y ago
    Unfortunately, Golang has a whole lot of weird, pointless quirks in both its base language and standard library, compared to something with a more elegant and from-the-ground-up design, like Rust itself or perhaps OCaml/ReasonML. Not very good news if you want the language to just "get the hell out of your way". I suppose it's still way better than the "enterprise" favored alternative of Java/C# though!
    - devjab 1y ago
      I worked with C# for a decade and it's become a really great general purpose language. I'd still prefer never to work with it ever again after having worked with Go. This isn't for technical reasons at all, but because Golang is so easy to work with for "people reasons". There are brilliant parts of Go, but the only thing I find myself missing in other languages is the simplistic module isolation, where every folder is a module, every file within the folder is part of it and then you expose functions with capital letters at the beginning of their name. Holy hell did I wish Python had that. Anyway, the thing that makes Go nice to work with over time is the explicity of everything and a lot of the very opinionated decisions. With a piece of Go code I can jump in and immediately know what is going on regardless of who wrote it. With C# I'll often have to go down long "go to definition" paths. Often you will end up trying to figure out just how someone was trying to "fight" the implicit magic of the non-STL Microsoft dependencies they used. Usually because they didn't really understand what they were doing. All of these are human issues and no fault of C# or .Net as such. Of the few technical advantages Go had for us is that we don't need a single dependency outside of the standard library, which can't live in isolation. We use SQLC and Goose, both are run in containers that only have rights and access on the development side of things. I'm not sure I would say that Golang has a lot of weird, pointless quirks, but it has opinions and if you happen to dislike them, well... that sucks. I hate the fact that they didn't want runtime assertions as an example, so it's not like I don't understand why people dislike Go for various reasons. I've just accepted that those strong opinions is the reason Go is so productive. The challenge for us is that it's not exactly as productive as Python. So while you'll need to do a lot of toolchain work to get Python anywhere near Go's opinionated stucture, that is often a better choice if you're not a hardcore software engineering team. At least for us, it's been much easier to get our business intelligence people to adopt UV, pyrefly, ruff and specific VSC configs for their work than to have them learn Go. I suspect that is why Rust is also doing so well. Go is a better Java/C# for a lot of places, but are you really going to replace your Java/C# with Go if you have dacades worth? If you're not coming from Java/C# will you really pick Go over Rust? I'm not sure, but I do know, Go failed to become a Python replacement for us. It did replace our C#, but we didn't have a lot of C#. Eventually we'll likely replace our Go with C/Zig and Python to keep the language count lower.
Kranar 1y ago
I can't substantiate your claim about Erlang or weird syntax, is that either a proper quote or some kind of paraphrasing because nothing remotely close to it comes up. There are numerous interviews with Rob Pike about the design of Go from when Go was still being developed, and Erlang doesn't come up in anything that I can find other than this interview from 2010 where someone asks Rob Pike a question involving Erlang and Rob replies by saying he thinks the two languages have a different approach to are fairly different: https://www.youtube.com/watch?v=3DtUzH3zoFo https://www.youtube.com/watch?v=3DtUzH3zoFo It's at the 32 minute mark, but once again this is in response to someone asking a question. Here are other interviews about Go, and once again in almost every interview I'd say Rob kind of insinuates he was motivated by a dislike of using C++ within Google to write highly parallel services, but not once is Erlang ever mentioned: https://www.informit.com/articles/article.aspx?p=1623555 https://www.informit.com/articles/article.aspx?p=1623555 https://www.infoq.com/interviews/pike-google-go https://www.infoq.com/interviews/pike-google-go https://go.dev/blog/waza-talk https://go.dev/blog/waza-talk
- af78 1y ago
  The parent comment does not say that Go derives from Erlang, but that both Erlang and Go implement CSP (https://en.wikipedia.org/wiki/Communicating_sequential_processes https://en.wikipedia.org/wiki/Communicating_sequential_proce...), with the advantage for Go over Erlang that its syntax is more familiar to programmers who know C.
  - Kranar 1y ago
    Erlang does not implement CSP, and if you review the very Wikipedia link you presented it should be clear. Erlang implements the Actor model, which is more flexible for distributed, fault-tolerant systems, but lacks CSP's strict formalism and synchronization semantics. The very Wikipedia article you linked to has an entire section on how CSP differs from the Actor model. Similarly Go also does not implement CSP either, although it certainly is influenced by it. The point of my comment is that to say that Go is basically Erlang style CSP without the weird syntax is not justified as an actual quote nor as a paraphrasing or summary of anything that anyone involved in the design or promotion of Go has ever said. It's best to reserve quotes for situations where someone actually said something or as a way to summarize something for which there are ample references available. One should not use quotes as a way to present mostly original claims that are presented as if it's some kind of already well established knowledge.
rastignack 1y ago
I don’t think channels and goroutines suck. For example their usage in golang’s ssh server implementation is eminently readable. And performant enough. Engineers ship with them, and do not care if there’s a purer system elsewhere.
- jeeyoungk 1y ago
  Definitely agree that goroutines don't suck; it makes go into one of the only languages without "function coloring" problem; True N:M multithreading without a separate sync and async versions of the IO libraries (thus everything else). I think channels have too many footguns (what should its size be? closing without causing panics when there are multiple writers), thus it's definitely better "abstracted out" at the framework level. Most channels that developers interact with is the `Context.Done()` channel with <-chan struct{}. Also, I'm not sure whether the go authors originally intended that closing a channel would effectively have a multicast semantics (all readers are notified, no matter how many are); everything else have pub-sub semantics, and turns out that this multicast semantics is much more interesting.
  - binary132 1y ago
    The answer to your question is zero, unless there is a compelling reason for it to buffer, and if there is you’ll know it. Non-buffering channels are much simpler to reason about and have very useful semantics in pipelines.
gethly 1y ago
> but people realized channels kind of suck and goroutines are not really a lot better than threads in other languages Are these people here in the room with us right now?
pwdisswordfishz 1y ago
if err != nil every few lines is hardly "more concise"...
camgunz 1y ago
The "X is like Y but Z" game w languages is pretty fun, and kind of illuminating as to what one thing you pick. Go is like C but with concurrency/strings/GC/a good stdlib Go is like C++ but simpler/fast compilation/no generics/a good stdlib Go is like Python but statically typed/multithreaded/fast/single executable Go is like Java but native/no OO --- One thing Go haters rarely reckon with is that Go is the only popular modern language (ie from this millennium). Everything else is way older. Well, I would actually say that this is probably the cause of Go hate--if it weren't popular no one would care.
- tialaramex 1y ago
  > One thing Go haters rarely reckon with is that Go is the only popular modern language (ie from this millennium). This requires you to squint so that "popular" happens to identify only a handful of languages but conveniently catches Go and not say Swift or Rust. It's not difficult to do this, but it's not very honest to yourself.
  - naniwaduni 1y ago
    "Go is on the frontier of recency vs popularity (i.e. newer than all more popular languages, and more popular than all newer languages)" is honestly an "interesting" statement in its own right, but would be a distinction it has to share with Python, Java, some of JS/C#/VB/PHP depending on your popularity (and age...) metrics, and yes, Swift and Rust. And a long tail of very new languages, I suppose.
  - camgunz 1y ago
    Just searching for "programming language popularity": - TIOBE [0]: Go 7 :: Rust n/a (> 10) - IEEE Spectrum [1]: Go 8 :: Rust 11 - Stack Overflow [2]: Go 13 :: Rust 14 (they're pretty close here) - GitHub [3]: Go 10 :: Rust n/a (> 10) - PYPL [4]: Go 12 :: Rust 10 - HackerRank [5]: Go 8 :: Rust n/a (> 13) - Pluralsight [6]: Go 9 :: Rust n/a (> 10) - Redmonk [7]: Go 12 :: Rust 19 Although I admit we probably don't have great measures of this, there's clearly a sizable gap here. Maybe you'd want to argue about TypeScript, Swift or Kotlin? I consider TypeScript JavaScript (because TypeScript wouldn't be popular unless all JavaScript programs were TypeScript programs), and I think Swift and Kotlin only survive because of their mobile platforms (they're also all below Go in these lists, on average). [0]: https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/ [1]: https://spectrum.ieee.org/top-programming-languages-2024 https://spectrum.ieee.org/top-programming-languages-2024 [2]: https://survey.stackoverflow.co/2024/technology https://survey.stackoverflow.co/2024/technology [3]: https://github.blog/news-insights/octoverse/octoverse-2024/#the-most-popular-programming-languages https://github.blog/news-insights/octoverse/octoverse-2024/#... [4]: https://pypl.github.io/PYPL.html https://pypl.github.io/PYPL.html [5]: https://www.hackerrank.com/blog/most-popular-languages-2024/ https://www.hackerrank.com/blog/most-popular-languages-2024/ [6]: https://www.pluralsight.com/resources/blog/upskilling/top-programming-languages-2025 https://www.pluralsight.com/resources/blog/upskilling/top-pr... [7]: https://redmonk.com/sogrady/2025/06/18/language-rankings-1-25/ https://redmonk.com/sogrady/2025/06/18/language-rankings-1-2...
citrin_ru 1y ago
But gorutines are better than threads when you need you need many (say >100K) of them. Lightweight threads are not unique to Go but in Go they are easy to use and the default way to build network applications. Java is catching up with project Loom but it would never be as easy as Go to use.
- zozbot234 1y ago
  > are better than threads when you need many (say >100K) of them Stackless coroutines are even more efficient for that case, and Rust makes them comparatively easy. (And slated to get even easier in future versions, as the async support is improved further.) Moreover stackful coroutines/fibers as used in Golang also makes it infeasible to have seamless FFI with the standard C API/ABI, which cuts you off from the bulk of the ecosystem. There are other issues too with having fibers in a C-like systems programming language - see https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p1364r0.pdf https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p13... for a nice summary of them.
  - dfawcus 1y ago
    Alef (arguably one of the antecedent of Go) had stackful couroutines/fibers yet it could have had such a seamless FFI to the standard C API/ABI. The plan9 libthread (which reimplemented the Alef concurrency model for C) did have seamless use of the C API/ABI. The mechanism was that it had threads and coroutines, a function needing to make use of the C API in a seamless manner would simply run as a thread rather than a coroutine. It was then easy to share data as the CSP model (with channels) worked between both coroutines, threads, and coroutines within a thread. So if one wishes to use stackful coroutines, and still have that seamless compatibility, an approach mixing the Go and Alef approaches would seem necessary. i.e. the Go migrating coroutines as a default, but with the option to use Alef like thread bound coroutines when necessary.
    - zozbot234 1y ago
      > The mechanism was that it had threads and coroutines, a function needing to make use of the C API in a seamless manner would simply run as a thread rather than a coroutine. This reintroduces the colored functions that we were trying to get away from in the first place, by adopting stackful coroutines/fibers. Why not use async at that point? I can understand that Alef didn't, because stackless mechanisms were not well understood at the time. But it's plausible that we can do better.
rollcat 1y ago
> The actual core of OTP was the supervisor tree but that's too complicated so Golang is basically just more concise Java. Which is ironic, maybe kinda funny. The first "larger" project I've tackled in Go was a chat server. I wanted a simple supervisor for each connected client; in case a goroutine encountered a recoverable error but needed to be restarted. I don't have any practical experience with OTP, but I've always been a big fan of daemontools/runit/etc: just let it crash, restart, and recover. So in Go, you can't (easily) obtain a handle to a goroutine. The authors' entire argument seemed to be that this would allow developers to implement "bad" patterns, like thread-local storage. You can of course still come up with some wrapper code, like this: type Service struct { err <-chan error run func(*Service) } s := &Service{err: make(chan error)} realRun := func() error { ... } s.run = func(s *Service) { s.err <- realRun() } go s.run(s) err := <-s.err But what you really wanted was something like: run := func() error { ... } g := go run() err := <-g Now of course you still want some wrapper code to maintain client/connection state, etc. But if you wanted a "real" supervisor tree, you'd have to do this dance for every sub-goroutine you'd like to spawn. You'll soon end up with func(*Service, any) and throw away static typing along the way. Generics wouldn't be introduced until 18 releases after, and I don't think they would help all that much. Correct me if I'm missing anything obvious.
torginus 1y ago
Ahh finally someone has said it. Unfortunately I can't seem to voice this opinion without getting the critique of you're just not smart enough to get it. While I like the language, threads in Go are not any easier than any other language (which is to say, most devs can't use them correctly, and your program will have bugs), and suffer from a ton of ergonomic issues, like being hard to keep track of, difficult(ish) cancellation(how do you cancel a big synchronous I/O operation), and channels suffer from backpressure related hard-to-debug issues.
Mawr 1y ago
> goroutines are not really a lot better than threads in other languages They are though. Even Java people agree, Java recently got their implementation of goroutines (green threads). It's a superior model to async for application level programming.
noncoml 1y ago
> but people realized channels kind of suck and goroutines are not really a lot better than threads in other languages. The actual core of OTP was the supervisor tree Immutability is the actual core and power of Earlang
deleted 1y ago
[deleted]

pif 1y ago

[flagged]

xyse53 1y ago
I think that's harsh. IME Go excels in a business setting where the focus is on correct, performant, maintainable, business logic in larger organizations, that's easy to integrate with a bunch of other systems. You can't squeeze every last bit of low-level performance out of it but you can get ... 9x% of the way there with concurrent code that is easy to reason about.
- TylerE 1y ago
  What matters is being 100x faster than python, not 5x slower than C++ or 2x slower than Java. Performant enough that IO (or network) rather than CPU is the bottleneck (in my limited experience). Personally I just far prefer to work in a GCed langauge. Much simpler mental model.
- pif 1y ago
  > correct, performant, maintainable, business logic That's the requirement for 100% if professional software development.
mcdoogal 1y ago
Yikes, language flamebait in 2025?
- zozbot234 1y ago
  Flamebait? It's literally what the designers of Golang said publicly about the background of prospective developers, and how that constrained the language design: "The key point here is our programmers are Googlers, they’re not researchers. They're typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They're not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt."
  - Degorath 1y ago
    Nowhere in this quote are these fresh grads equated to "lousy programmers", though (which the flamebaity comment did). And interpreting the quote charitably I'm going to have to agree with it - I don't think many of my coworkers care enough to get to the point where they'd appreciate everything something like Haskell can do for them.
    - ModernMech 1y ago
      Have you ever worked with fresh grads? They're definitionally lousy programmers, if we take lousy mean "having a propensity to inject bugs into programs".
  - binary132 1y ago
    The more time you spend in software engineering the more you realize that this is actually brilliant and helpful, not bad. And IME, the more expressivity I have fluently at my disposal, the more complexity I tend to create. I’m not saying I don’t enjoy more complex languages, but reducing cognitive load and easing collaboration with more junior engineers are easily the best features of Go, hands down (although I can’t say the new generics necessarily always help with that).
  - 1y ago
Aeolun 1y ago
I don’t like writing golang, but I sure like reading it. It’s nearly impossible not to understand.
konart 1y ago
Serious being what? Most programmers are "lousy programmers" because most of the are not researchers and have no interest in theory. I can write in Go or Rust (or anything else given some time) but I won't ever use Rust to write any kind of business logic for my company - and this is what I do most of the time I actually write code. Why? Because Rust is terrible for the job (at least if we are talking about real life scenario where the job should be done in hours and not weeks)
- oneshtein 1y ago
  I can do business logic, like complex CRUD, in Rust much faster than in other languages. I assume, «lousy programmers» have problems with separation of concerns, which then cause problems with borrow checker, because developers need to perform different things in different ways on different parts of data structures (AKA «god object» anti-pattern).
  - konart 1y ago
    > separation of concerns but this would be a problem almost anywhere, no? This has nothing to do with Rust vs Go vs Ruby or something else. Rust makes this even bigger problem, ok, but I don't think we should call people not using Rust (c\c++ etc) "lousy". PS: tbh this kind of statements usually (from my experience) come from people who mainly write system level software or work with hardware directly.
binary132 1y ago
There are a lot of those for sure. There are far more in Python and Java. Any popular, simple-enough language will attract a horde of jobseeking mouthbreathers, that’s kind of inevitable and normal really.

fmbb 1y ago

> Golang is basically just more concise Java. That is exactly how it was sold. A safe C, or a nicer simpler Java. Nobody cared about Erlang back then and nobody does today. I write Erlang for a living.

gdbsjjdn 1y ago
I was an early Golang dev and people were _crazy_ with channels for a couple years. I remember the most popular Golang Kafka client was absolute spaghetti of channels and routines. It's never been "safe C" because it's garbage collected. Java is truly the comp because it's a great Grug language. I also wrote some Erlang in the past, I really enjoy it and I was sad that Go didn't borrow more.
- tptacek 1y ago
  This is "share by communicating, don't communicate by sharing". Pretty much everyone agrees it's a good thought. ~Most programs get there just fine with channels, because ~most code isn't so performance sensitive that channel limitations matter. Go leaves plenty of room for the rest of programs to do something else. Seems good.
nothrabannosir 1y ago
I remember very well one of the first public presentations about Go. It focused heavily on goroutines and channels and included a live demonstration of pushing an element through one million channels. It also included a demo of spinning up three racing queries to the Google search engine using the select statement, and picking whoever returned first. it was all about the new cool feature. They also had TCP-over-channels and eventually had to remove that because the model didn’t fit. Nobody may have known they cared about Erlang, but those features sure made people pay attention.
nine_k 1y ago
Writing Elixir for a living is seemingly a growing trend.
hardwaresofton 1y ago

nine_k 1y ago

Due to lack of many abstractions, and lack of exceptions, Go is a less concise Java. It's a language where the lack of expressiveness forces you to write simpler code. (Not that it helps too much.) Go's selling points are different: it takes a weekend to learn, and a week to become productive, it has a well-stocked standard library, it compiles quickly, runs quickly enough, and produces a single self-contained executable. I would say that Go is mostly a better Modula-2 (with bits of Oberon); it's only better from the language standpoint because now it has type parameters, but GC definitely helps make writing it simpler.

tptacek 1y ago
People sometimes say this like it's a dunk, but there's a finite amount of complexity any given programming task can shoulder, you have to allocate it somehow between the programming environment, the problem domain you're working on, and the algorithmic sophistication you bring to bear on that problem, and it's not clear to me what the benefit is in allocating more than you need to your programming language. A lot of very smart stuff is written in Go by programmers who just want the language to get the hell out of their way. Go is some ways very good at that. Rough though if you want your programming language to model your problem domain or your algorithmic approach! TANSTAAFL.
- zozbot234 1y ago
  Unfortunately, Golang has a whole lot of weird, pointless quirks in both its base language and standard library, compared to something with a more elegant and from-the-ground-up design, like Rust itself or perhaps OCaml/ReasonML. Not very good news if you want the language to just "get the hell out of your way". I suppose it's still way better than the "enterprise" favored alternative of Java/C# though!
  - devjab 1y ago
    I worked with C# for a decade and it's become a really great general purpose language. I'd still prefer never to work with it ever again after having worked with Go. This isn't for technical reasons at all, but because Golang is so easy to work with for "people reasons". There are brilliant parts of Go, but the only thing I find myself missing in other languages is the simplistic module isolation, where every folder is a module, every file within the folder is part of it and then you expose functions with capital letters at the beginning of their name. Holy hell did I wish Python had that. Anyway, the thing that makes Go nice to work with over time is the explicity of everything and a lot of the very opinionated decisions. With a piece of Go code I can jump in and immediately know what is going on regardless of who wrote it. With C# I'll often have to go down long "go to definition" paths. Often you will end up trying to figure out just how someone was trying to "fight" the implicit magic of the non-STL Microsoft dependencies they used. Usually because they didn't really understand what they were doing. All of these are human issues and no fault of C# or .Net as such. Of the few technical advantages Go had for us is that we don't need a single dependency outside of the standard library, which can't live in isolation. We use SQLC and Goose, both are run in containers that only have rights and access on the development side of things. I'm not sure I would say that Golang has a lot of weird, pointless quirks, but it has opinions and if you happen to dislike them, well... that sucks. I hate the fact that they didn't want runtime assertions as an example, so it's not like I don't understand why people dislike Go for various reasons. I've just accepted that those strong opinions is the reason Go is so productive. The challenge for us is that it's not exactly as productive as Python. So while you'll need to do a lot of toolchain work to get Python anywhere near Go's opinionated stucture, that is often a better choice if you're not a hardcore software engineering team. At least for us, it's been much easier to get our business intelligence people to adopt UV, pyrefly, ruff and specific VSC configs for their work than to have them learn Go. I suspect that is why Rust is also doing so well. Go is a better Java/C# for a lot of places, but are you really going to replace your Java/C# with Go if you have dacades worth? If you're not coming from Java/C# will you really pick Go over Rust? I'm not sure, but I do know, Go failed to become a Python replacement for us. It did replace our C#, but we didn't have a lot of C#. Eventually we'll likely replace our Go with C/Zig and Python to keep the language count lower.

Kranar 1y ago

I can't substantiate your claim about Erlang or weird syntax, is that either a proper quote or some kind of paraphrasing because nothing remotely close to it comes up. There are numerous interviews with Rob Pike about the design of Go from when Go was still being developed, and Erlang doesn't come up in anything that I can find other than this interview from 2010 where someone asks Rob Pike a question involving Erlang and Rob replies by saying he thinks the two languages have a different approach to are fairly different: https://www.youtube.com/watch?v=3DtUzH3zoFo https://www.youtube.com/watch?v=3DtUzH3zoFo It's at the 32 minute mark, but once again this is in response to someone asking a question. Here are other interviews about Go, and once again in almost every interview I'd say Rob kind of insinuates he was motivated by a dislike of using C++ within Google to write highly parallel services, but not once is Erlang ever mentioned: https://www.informit.com/articles/article.aspx?p=1623555 https://www.informit.com/articles/article.aspx?p=1623555 https://www.infoq.com/interviews/pike-google-go https://www.infoq.com/interviews/pike-google-go https://go.dev/blog/waza-talk https://go.dev/blog/waza-talk

af78 1y ago
The parent comment does not say that Go derives from Erlang, but that both Erlang and Go implement CSP (https://en.wikipedia.org/wiki/Communicating_sequential_processes https://en.wikipedia.org/wiki/Communicating_sequential_proce...), with the advantage for Go over Erlang that its syntax is more familiar to programmers who know C.
- Kranar 1y ago
  Erlang does not implement CSP, and if you review the very Wikipedia link you presented it should be clear. Erlang implements the Actor model, which is more flexible for distributed, fault-tolerant systems, but lacks CSP's strict formalism and synchronization semantics. The very Wikipedia article you linked to has an entire section on how CSP differs from the Actor model. Similarly Go also does not implement CSP either, although it certainly is influenced by it. The point of my comment is that to say that Go is basically Erlang style CSP without the weird syntax is not justified as an actual quote nor as a paraphrasing or summary of anything that anyone involved in the design or promotion of Go has ever said. It's best to reserve quotes for situations where someone actually said something or as a way to summarize something for which there are ample references available. One should not use quotes as a way to present mostly original claims that are presented as if it's some kind of already well established knowledge.

rastignack 1y ago

I don’t think channels and goroutines suck. For example their usage in golang’s ssh server implementation is eminently readable. And performant enough. Engineers ship with them, and do not care if there’s a purer system elsewhere.

jeeyoungk 1y ago
Definitely agree that goroutines don't suck; it makes go into one of the only languages without "function coloring" problem; True N:M multithreading without a separate sync and async versions of the IO libraries (thus everything else). I think channels have too many footguns (what should its size be? closing without causing panics when there are multiple writers), thus it's definitely better "abstracted out" at the framework level. Most channels that developers interact with is the `Context.Done()` channel with <-chan struct{}. Also, I'm not sure whether the go authors originally intended that closing a channel would effectively have a multicast semantics (all readers are notified, no matter how many are); everything else have pub-sub semantics, and turns out that this multicast semantics is much more interesting.
- binary132 1y ago
  The answer to your question is zero, unless there is a compelling reason for it to buffer, and if there is you’ll know it. Non-buffering channels are much simpler to reason about and have very useful semantics in pipelines.

gethly 1y ago

> but people realized channels kind of suck and goroutines are not really a lot better than threads in other languages Are these people here in the room with us right now?

pwdisswordfishz 1y ago

if err != nil every few lines is hardly "more concise"...

camgunz 1y ago

The "X is like Y but Z" game w languages is pretty fun, and kind of illuminating as to what one thing you pick. Go is like C but with concurrency/strings/GC/a good stdlib Go is like C++ but simpler/fast compilation/no generics/a good stdlib Go is like Python but statically typed/multithreaded/fast/single executable Go is like Java but native/no OO --- One thing Go haters rarely reckon with is that Go is the only popular modern language (ie from this millennium). Everything else is way older. Well, I would actually say that this is probably the cause of Go hate--if it weren't popular no one would care.

tialaramex 1y ago
> One thing Go haters rarely reckon with is that Go is the only popular modern language (ie from this millennium). This requires you to squint so that "popular" happens to identify only a handful of languages but conveniently catches Go and not say Swift or Rust. It's not difficult to do this, but it's not very honest to yourself.
- naniwaduni 1y ago
  "Go is on the frontier of recency vs popularity (i.e. newer than all more popular languages, and more popular than all newer languages)" is honestly an "interesting" statement in its own right, but would be a distinction it has to share with Python, Java, some of JS/C#/VB/PHP depending on your popularity (and age...) metrics, and yes, Swift and Rust. And a long tail of very new languages, I suppose.
- camgunz 1y ago
  Just searching for "programming language popularity": - TIOBE [0]: Go 7 :: Rust n/a (> 10) - IEEE Spectrum [1]: Go 8 :: Rust 11 - Stack Overflow [2]: Go 13 :: Rust 14 (they're pretty close here) - GitHub [3]: Go 10 :: Rust n/a (> 10) - PYPL [4]: Go 12 :: Rust 10 - HackerRank [5]: Go 8 :: Rust n/a (> 13) - Pluralsight [6]: Go 9 :: Rust n/a (> 10) - Redmonk [7]: Go 12 :: Rust 19 Although I admit we probably don't have great measures of this, there's clearly a sizable gap here. Maybe you'd want to argue about TypeScript, Swift or Kotlin? I consider TypeScript JavaScript (because TypeScript wouldn't be popular unless all JavaScript programs were TypeScript programs), and I think Swift and Kotlin only survive because of their mobile platforms (they're also all below Go in these lists, on average). [0]: https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/ [1]: https://spectrum.ieee.org/top-programming-languages-2024 https://spectrum.ieee.org/top-programming-languages-2024 [2]: https://survey.stackoverflow.co/2024/technology https://survey.stackoverflow.co/2024/technology [3]: https://github.blog/news-insights/octoverse/octoverse-2024/#the-most-popular-programming-languages https://github.blog/news-insights/octoverse/octoverse-2024/#... [4]: https://pypl.github.io/PYPL.html https://pypl.github.io/PYPL.html [5]: https://www.hackerrank.com/blog/most-popular-languages-2024/ https://www.hackerrank.com/blog/most-popular-languages-2024/ [6]: https://www.pluralsight.com/resources/blog/upskilling/top-programming-languages-2025 https://www.pluralsight.com/resources/blog/upskilling/top-pr... [7]: https://redmonk.com/sogrady/2025/06/18/language-rankings-1-25/ https://redmonk.com/sogrady/2025/06/18/language-rankings-1-2...

citrin_ru 1y ago

But gorutines are better than threads when you need you need many (say >100K) of them. Lightweight threads are not unique to Go but in Go they are easy to use and the default way to build network applications. Java is catching up with project Loom but it would never be as easy as Go to use.

zozbot234 1y ago
> are better than threads when you need many (say >100K) of them Stackless coroutines are even more efficient for that case, and Rust makes them comparatively easy. (And slated to get even easier in future versions, as the async support is improved further.) Moreover stackful coroutines/fibers as used in Golang also makes it infeasible to have seamless FFI with the standard C API/ABI, which cuts you off from the bulk of the ecosystem. There are other issues too with having fibers in a C-like systems programming language - see https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p1364r0.pdf https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p13... for a nice summary of them.
- dfawcus 1y ago
  Alef (arguably one of the antecedent of Go) had stackful couroutines/fibers yet it could have had such a seamless FFI to the standard C API/ABI. The plan9 libthread (which reimplemented the Alef concurrency model for C) did have seamless use of the C API/ABI. The mechanism was that it had threads and coroutines, a function needing to make use of the C API in a seamless manner would simply run as a thread rather than a coroutine. It was then easy to share data as the CSP model (with channels) worked between both coroutines, threads, and coroutines within a thread. So if one wishes to use stackful coroutines, and still have that seamless compatibility, an approach mixing the Go and Alef approaches would seem necessary. i.e. the Go migrating coroutines as a default, but with the option to use Alef like thread bound coroutines when necessary.
  - zozbot234 1y ago
    > The mechanism was that it had threads and coroutines, a function needing to make use of the C API in a seamless manner would simply run as a thread rather than a coroutine. This reintroduces the colored functions that we were trying to get away from in the first place, by adopting stackful coroutines/fibers. Why not use async at that point? I can understand that Alef didn't, because stackless mechanisms were not well understood at the time. But it's plausible that we can do better.

rollcat 1y ago

> The actual core of OTP was the supervisor tree but that's too complicated so Golang is basically just more concise Java. Which is ironic, maybe kinda funny. The first "larger" project I've tackled in Go was a chat server. I wanted a simple supervisor for each connected client; in case a goroutine encountered a recoverable error but needed to be restarted. I don't have any practical experience with OTP, but I've always been a big fan of daemontools/runit/etc: just let it crash, restart, and recover. So in Go, you can't (easily) obtain a handle to a goroutine. The authors' entire argument seemed to be that this would allow developers to implement "bad" patterns, like thread-local storage. You can of course still come up with some wrapper code, like this: type Service struct { err <-chan error run func(*Service) } s := &Service{err: make(chan error)} realRun := func() error { ... } s.run = func(s *Service) { s.err <- realRun() } go s.run(s) err := <-s.err But what you really wanted was something like: run := func() error { ... } g := go run() err := <-g Now of course you still want some wrapper code to maintain client/connection state, etc. But if you wanted a "real" supervisor tree, you'd have to do this dance for every sub-goroutine you'd like to spawn. You'll soon end up with func(*Service, any) and throw away static typing along the way. Generics wouldn't be introduced until 18 releases after, and I don't think they would help all that much. Correct me if I'm missing anything obvious.

torginus 1y ago

Ahh finally someone has said it. Unfortunately I can't seem to voice this opinion without getting the critique of you're just not smart enough to get it. While I like the language, threads in Go are not any easier than any other language (which is to say, most devs can't use them correctly, and your program will have bugs), and suffer from a ton of ergonomic issues, like being hard to keep track of, difficult(ish) cancellation(how do you cancel a big synchronous I/O operation), and channels suffer from backpressure related hard-to-debug issues.

Mawr 1y ago

> goroutines are not really a lot better than threads in other languages They are though. Even Java people agree, Java recently got their implementation of goroutines (green threads). It's a superior model to async for application level programming.

noncoml 1y ago

> but people realized channels kind of suck and goroutines are not really a lot better than threads in other languages. The actual core of OTP was the supervisor tree Immutability is the actual core and power of Earlang

deleted 1y ago

[deleted]