4 ms·

The fact that he doesn't mention context as a huge failing of Go is very suspect... I also find the post a little too self-congratulatory for what was essentia

The fact that he doesn't mention context as a huge failing of Go is very suspect... I also find the post a little too self-congratulatory for what was essentially a reinvention of C with a GC at the right time, and not just C the language, but C's philosophy on programming. I think as Go has become more popular, the core of C has been drowned out by people coming from other languages who insist on too many libraries, too many abstractions, generic solutions at every level, and more features. Go today has essentially moved much closer to Java, and some projects like Kubernetes are without a doubt just Java projects with a slightly different syntax. Concurrency and interfaces I think are also a big fail in Go. Interfaces because they failed to add enough of them to the standard library for simple things like logging, filesystem access, etc, causing numerous incompatible implementations, which is something that wouldn't have happened if they hadn't been so gung-ho on interfaces being defined where they are used instead of having community interfaces. Concurrency is harder to summarize, but day to day you still get locking issues, libraries that don't expose interfaces that are easy to work with via coroutines (which is ironic given rob's finger pointing at async/await coloring), and as I said context is really a prime example of why CSP IS a bad model compared to mailboxes and the Erlang model of concurrency. Every function has to take an extra noisy argument, every function has to wait for a ctx cancellation, instead of just baking the semantics of cancellation into the language itself.

cangeroo 3y ago
Interestingly, several posts have already been flagged for having a similar perspective. I'd love to know why we're not allowed to discuss and elaborate on "what we got wrong" in fairly neutral technical terms.
- tptacek 3y ago
  It's language-war drama, which is deeply disfavored on HN, because it's boring and spreads like kudzu.
  - cangeroo 3y ago
    Fair enough. And the world would be a better place with a positive-bias. Except that this article purports to be self-critical, so arguably the very topic of this thread should cover both the positive and negative of the language, and our comments are merely expanding on it. But thanks for the explanation, I appreciate it.
- sesm 3y ago
  Slightly off-topic, but the most honest programming language book that describes “what we got wrong” is “Effective Java” by Josh Bloch. It also used to be the best book to learn Java before 1.7 (maybe still the best today, but I’m not following Java anymore).
the_gipsy 3y ago
> I also find the post a little too self-congratulatory Yes. I mean, the language is a huge success if you measure how far adoption has come. But I expect more from a "what we got right and what we got wrong" post. IMHO what went right is compiler/tooling speed. The async story ultimately is just crappy, the "no colored functions" is a lie that blows up in production. Go's interfaces also sound great in theory but don't really work so great when using them. They're mostly used for DI in UTs. Sometimes I wonder if I'd use any interfaces at all if there was a way to monkeypatch deps just for UTs (yes I would but 99% less).
OkayPhysicist 3y ago
The fact that Erlang has existed since the 80's really begs the question "Why do language designers keep fucking up concurrency?". It's a feature that's really painful to tack onto to a language after the fact (looking at you, Python and JavaScript), but is absolutely necessary for any programming language. I see goroutines as a solid "next best thing" after BEAM Processes, both of which are miles ahead of async/await, which is admittedly an improvement over any lower-level thread manipulation.
- techdragon 3y ago
  Because erlang is “weird” and not enough programmers learn it for it to have breached the cultural ramparts regarding what concurrency is in a programming language. I learned Erlang and Elixir and I’ve never been happy with any other languages’ concurrency mechanisms and primitives since then. Between multitasking features that let you avoid concurrent tasks causing CPU starvation, message passing allowing proper decoupling of concurrent tasks in both an asynchronous and synchronous ways and all the other little ways it does concurrent programming right… nothing holds a candle to it. There are some nice libraries in other languages but it’s not the same because it’s not built into the language at the same level. Async/Await, asynchronous IO, none of this is really the same kind of “concurrency”… it’s why I wish I had more chance to use the Erlang/Elixir+Rust combo… low level safety and high level concurrency are a match made in heaven.
  - zozbot234 3y ago
    Rust is getting async-in-traits in its newest release, that can also be seen as implementing this "message passing" model in an async context. It's super impressive how the language keeps evolving so fast and improving its relevance over time.
    - OkayPhysicist 3y ago
      A huge amount of the value-add of BEAM languages is the fact that the languages have built-in support for message-passing concurrency built in at very fundamental levels, which means that the "pretty path", the comfortable way to write code in those languages, simply supports the concurrency model. You cannot achieve this by tacking on half-baked support onto an already designed language. You can tack on Async/await, which is exactly why it's so popular.
deleted 3y ago
[deleted]
voidhorse 3y ago
It really is just C with a GC and slightly better support for generic programming, which is why I like it quite a lot as a default language for writing basic programs. I like Go, but I didn't like the post for somewhat similar reasons. I felt it pats itself on the back for several language design wheel reinventions that are basically lesser versions of counterparts in other languages. For example, interfaces are touted as some brilliant solution for polymorphism as though Haskell wasn't already doing the "sets of methods" (but with type arguments from the start) idea via type classes as early as 1988...sure interfaces are a bit different since they are implicitly implemented, but the basic idea is the same. The whole Erlang being a good prior in the concurrency space is another example. In general it left a bad taste in my mouth since it sort of felt like the language was designed in ignorance of the vast field of ideas already present in programming language theory. It really comes off as though the team thought that Java, C, and C++ were the only languages that existed before Go. Wadler's (eventual) involvement suggests otherwise (but then again, maybe they only knew about his work in relation to Java), and I realize there are constraints to giving live talks that force one to trim things down, but I really dislike this tendency to think in a vacuum, celebrate your own (re)discoveries as brilliance, and then to present it all without hardly a mention of the large body of research that went before you, and that you should have consulted during your creative process. Given the access we have to research today, there's little excuse for it. I doubt that Rob Pike actually falls into this camp or lacks this knowledge, but the talk (in essay form) really makes the team of language designers seem like it was a team of people that knew little about language design and happened to stumble onto analogues of good ideas that already existed in more mature form. I will say, though, that I like that the writing of a spec is touted as one of their best decisions, as I really wish more novel languages would bother to define specs these days.

cangeroo 3y ago

Interestingly, several posts have already been flagged for having a similar perspective. I'd love to know why we're not allowed to discuss and elaborate on "what we got wrong" in fairly neutral technical terms.

tptacek 3y ago
It's language-war drama, which is deeply disfavored on HN, because it's boring and spreads like kudzu.
- cangeroo 3y ago
  Fair enough. And the world would be a better place with a positive-bias. Except that this article purports to be self-critical, so arguably the very topic of this thread should cover both the positive and negative of the language, and our comments are merely expanding on it. But thanks for the explanation, I appreciate it.
sesm 3y ago
Slightly off-topic, but the most honest programming language book that describes “what we got wrong” is “Effective Java” by Josh Bloch. It also used to be the best book to learn Java before 1.7 (maybe still the best today, but I’m not following Java anymore).

the_gipsy 3y ago

> I also find the post a little too self-congratulatory Yes. I mean, the language is a huge success if you measure how far adoption has come. But I expect more from a "what we got right and what we got wrong" post. IMHO what went right is compiler/tooling speed. The async story ultimately is just crappy, the "no colored functions" is a lie that blows up in production. Go's interfaces also sound great in theory but don't really work so great when using them. They're mostly used for DI in UTs. Sometimes I wonder if I'd use any interfaces at all if there was a way to monkeypatch deps just for UTs (yes I would but 99% less).

OkayPhysicist 3y ago

The fact that Erlang has existed since the 80's really begs the question "Why do language designers keep fucking up concurrency?". It's a feature that's really painful to tack onto to a language after the fact (looking at you, Python and JavaScript), but is absolutely necessary for any programming language. I see goroutines as a solid "next best thing" after BEAM Processes, both of which are miles ahead of async/await, which is admittedly an improvement over any lower-level thread manipulation.

techdragon 3y ago
Because erlang is “weird” and not enough programmers learn it for it to have breached the cultural ramparts regarding what concurrency is in a programming language. I learned Erlang and Elixir and I’ve never been happy with any other languages’ concurrency mechanisms and primitives since then. Between multitasking features that let you avoid concurrent tasks causing CPU starvation, message passing allowing proper decoupling of concurrent tasks in both an asynchronous and synchronous ways and all the other little ways it does concurrent programming right… nothing holds a candle to it. There are some nice libraries in other languages but it’s not the same because it’s not built into the language at the same level. Async/Await, asynchronous IO, none of this is really the same kind of “concurrency”… it’s why I wish I had more chance to use the Erlang/Elixir+Rust combo… low level safety and high level concurrency are a match made in heaven.
- zozbot234 3y ago
  Rust is getting async-in-traits in its newest release, that can also be seen as implementing this "message passing" model in an async context. It's super impressive how the language keeps evolving so fast and improving its relevance over time.
  - OkayPhysicist 3y ago
    A huge amount of the value-add of BEAM languages is the fact that the languages have built-in support for message-passing concurrency built in at very fundamental levels, which means that the "pretty path", the comfortable way to write code in those languages, simply supports the concurrency model. You cannot achieve this by tacking on half-baked support onto an already designed language. You can tack on Async/await, which is exactly why it's so popular.

deleted 3y ago

[deleted]

voidhorse 3y ago

It really is just C with a GC and slightly better support for generic programming, which is why I like it quite a lot as a default language for writing basic programs. I like Go, but I didn't like the post for somewhat similar reasons. I felt it pats itself on the back for several language design wheel reinventions that are basically lesser versions of counterparts in other languages. For example, interfaces are touted as some brilliant solution for polymorphism as though Haskell wasn't already doing the "sets of methods" (but with type arguments from the start) idea via type classes as early as 1988...sure interfaces are a bit different since they are implicitly implemented, but the basic idea is the same. The whole Erlang being a good prior in the concurrency space is another example. In general it left a bad taste in my mouth since it sort of felt like the language was designed in ignorance of the vast field of ideas already present in programming language theory. It really comes off as though the team thought that Java, C, and C++ were the only languages that existed before Go. Wadler's (eventual) involvement suggests otherwise (but then again, maybe they only knew about his work in relation to Java), and I realize there are constraints to giving live talks that force one to trim things down, but I really dislike this tendency to think in a vacuum, celebrate your own (re)discoveries as brilliance, and then to present it all without hardly a mention of the large body of research that went before you, and that you should have consulted during your creative process. Given the access we have to research today, there's little excuse for it. I doubt that Rob Pike actually falls into this camp or lacks this knowledge, but the talk (in essay form) really makes the team of language designers seem like it was a team of people that knew little about language design and happened to stumble onto analogues of good ideas that already existed in more mature form. I will say, though, that I like that the writing of a spec is touted as one of their best decisions, as I really wish more novel languages would bother to define specs these days.