7 ms·

The author fundamentally misunderstands language design. He picks an arbitrary design constraint, in this case correctness, and argues that any language that do

by Mawr 5y ago

The author fundamentally misunderstands language design. He picks an arbitrary design constraint, in this case correctness, and argues that any language that does not provide 100% correctness is bad. He uses Rust for his examples, a language that has correctness as one of its top design goals, and contrasts it with Go, for which correctness is not that important. So of course Rust will come out on top when the only metric you care about is correctness. As usual with such one-sided rants, the downsides to the supposed clearly right alternative are omitted. How long would it take for me to learn Rust + write a given program vs Go? How long does it take to model problems 100% correctly vs merely well-enough? > It [Go] constantly lies about how complicated real-world systems are, and optimize for the 90% case, ignoring correctness. Yes, exactly. Optimizing for the 90% case, not simplicity, is the primary design goal of Go. In other words, pragmatism or the 80/20 rule. Go attempts to provide 80% of the benefit for only 20% of the cost. This is pervasive throughout the language: - the author's examples, - a GC, - merely good-enough error handling. The sweet spot Go attempts to strike between speed of coding, correctness, safety, performance, and mental overhead is the reason it's so polarizing. You may like this approach or not, but let's not pretend that Go is all bad or that say Rust is some perfect holy grail that will save us all.

sfvisser 5y ago
The author clearly does understand language design. He probably even agrees with your description of go above, but simply describes it really doesn’t work for him.
fasterthanlime 5y ago
What an extremely convenient template to dismiss any nuanced argument against "worse is better". You even get to question my credentials a couple times! (I apparently pick metrics that are convenient to my argument, and fundamentally misunderstand programming language design). Even if I accept the premise that "I'm challenging Go on things it doesn't promise to deliver" (which is disingenuous to begin with — correctness underpins /everything/, it's not a hobby), I can't help but notice you carefully use the word "attempt" when referring to the promises Go /does/ make. One of the things I'm saying is that Go does not deliver on those. It does not deliver on "speed of coding", precisely because everyone, even seasoned Go developers, keep hitting its many design pitfalls. It does not lower mental overhead, because it prevents you from building abstractions, and pushes complexity out of the language and into your head. There's a lot to be said about safety and performance, which gets bleaker real quick once CGo enters the picture (hence why the Go team likes to remind folks that CGo is not Go). But say we disagree there and you truly find it a breeze to write large amounts of Go code: as soon as you deploy something to production and others start to rely on it: you don't get to choose not to care about "correctness". If you don't, you're just pushing the problem onto someone else. You may be pushing the problem onto ops people, other devs, or your customers, but it does land on someone. And nowadays that someone is often me: my frustration is fueled by years of real world use, I do not, like you seem to imply, enjoy thinking about these things in the abstract, just for the fun of it. Of course, you can choose to ignore that too, and that's fine! But let's please drop the pretense that this kind of response is anything other than "I refuse to think about this".
- golergka 5y ago
  I think it's a matter of different goals. What you describe is pains of a very senior developer who has worked on a lot of very subtle bugs and never questioned their desire to deliver the best software possible. Parent comment, however, talks about a situation where you have to hire dozens (if not hundreds) of $10/hour developers to ship software that is just good enough. I mean folks who may be great people and deserving overall respect, but who can't actually solve FizzBuzz. For such a situation, this: > You may be pushing the problem onto ops people, other devs, or your customers is quite alright and much more preferable than paying the market rate for developers who are actually capable of learning Rust.
  - philosopher1234 5y ago
    I'm not fond of this framing, which suggests that go is for bad programmers and rust is for good programmers. If Go makes it easier for bad programmers to write decent code, it also makes it easier for good programmers. Good programmers aren't good because they're insanely clever and whip up brilliant combinations of abstractions. They're good because they write maintainable, understandable, simple, and effective code. Or: they write code that understands the problem and solves it, not code that is stylish. Go helps good devs do this.
    - deleted 5y ago
      [deleted]
    - chrisoverzero 5y ago
      > I'm not fond of this framing, which suggests that go is for bad programmers and rust is for good programmers. Right, go is for inexperienced programmers. > 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. Or so Rob Pike thinks. However, as I get more and more experienced, the shortcomings of go become too much to bear.
Fritsdehacker 5y ago
I think describing this article as a one sided rant isn't really fair. The author shows that Go makes a few design decisions that make it easy to shoot yourself in the foot. This is generally a bad idea. Rust may be the summum of correctness. In my view that makes it an ideal candidate for comparison. It shows the reader what a better solution would look like. And that this can work in practice. Does that mean you shouldn't write code in Go? No of course not. But I think the author has done a great job of showing why they don't want to use Go anymore.
- philosopher1234 5y ago
  It’s one sided when it points out the pitfalls without bothering to describe why they’re there, and what the upside is. There are sloppy mistakes in Go, just like in anything, but many of the common criticisms of go are about trade offs not about mistakes.
  - Fritsdehacker 5y ago
    Sure, but the way I read the article, that's what the author shows. They don't like trade-offs that are made. Maybe the tone of the article feels a little aggressive towards Go, I don't know. To me it felt more like an outcry of frustration with the chosen trade-offs.
mirceal 5y ago
> He picks an arbitrary design constraint, in this case correctness, and argues that any language that does not provide 100% correctness is bad I'm sorry, WHAT? This is not about correctness (and IMHO if you have something that makes this tradeoff you should not use it anyway), it's about pretending that correctness does not matter and that unexpected bad behavior is okay... cause you know 80/20. IMHO Go has its use cases but it's definitely not a panacea. I don't mind people pragmatically picking it and using it. I am bothered by the zealots that think this is the best thing since sliced break (spoiler alert: it's not). Its authors and the community also seem to have an elitist / better than you default attitude when being humble and open would actually serve them better (package management and generics come into mind - what disasters)

by Mawr 5y ago

sfvisser 5y ago

The author clearly does understand language design. He probably even agrees with your description of go above, but simply describes it really doesn’t work for him.

fasterthanlime 5y ago

What an extremely convenient template to dismiss any nuanced argument against "worse is better". You even get to question my credentials a couple times! (I apparently pick metrics that are convenient to my argument, and fundamentally misunderstand programming language design). Even if I accept the premise that "I'm challenging Go on things it doesn't promise to deliver" (which is disingenuous to begin with — correctness underpins /everything/, it's not a hobby), I can't help but notice you carefully use the word "attempt" when referring to the promises Go /does/ make. One of the things I'm saying is that Go does not deliver on those. It does not deliver on "speed of coding", precisely because everyone, even seasoned Go developers, keep hitting its many design pitfalls. It does not lower mental overhead, because it prevents you from building abstractions, and pushes complexity out of the language and into your head. There's a lot to be said about safety and performance, which gets bleaker real quick once CGo enters the picture (hence why the Go team likes to remind folks that CGo is not Go). But say we disagree there and you truly find it a breeze to write large amounts of Go code: as soon as you deploy something to production and others start to rely on it: you don't get to choose not to care about "correctness". If you don't, you're just pushing the problem onto someone else. You may be pushing the problem onto ops people, other devs, or your customers, but it does land on someone. And nowadays that someone is often me: my frustration is fueled by years of real world use, I do not, like you seem to imply, enjoy thinking about these things in the abstract, just for the fun of it. Of course, you can choose to ignore that too, and that's fine! But let's please drop the pretense that this kind of response is anything other than "I refuse to think about this".

golergka 5y ago
I think it's a matter of different goals. What you describe is pains of a very senior developer who has worked on a lot of very subtle bugs and never questioned their desire to deliver the best software possible. Parent comment, however, talks about a situation where you have to hire dozens (if not hundreds) of $10/hour developers to ship software that is just good enough. I mean folks who may be great people and deserving overall respect, but who can't actually solve FizzBuzz. For such a situation, this: > You may be pushing the problem onto ops people, other devs, or your customers is quite alright and much more preferable than paying the market rate for developers who are actually capable of learning Rust.
- philosopher1234 5y ago
  I'm not fond of this framing, which suggests that go is for bad programmers and rust is for good programmers. If Go makes it easier for bad programmers to write decent code, it also makes it easier for good programmers. Good programmers aren't good because they're insanely clever and whip up brilliant combinations of abstractions. They're good because they write maintainable, understandable, simple, and effective code. Or: they write code that understands the problem and solves it, not code that is stylish. Go helps good devs do this.
  - deleted 5y ago
    [deleted]
  - chrisoverzero 5y ago
    > I'm not fond of this framing, which suggests that go is for bad programmers and rust is for good programmers. Right, go is for inexperienced programmers. > 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. Or so Rob Pike thinks. However, as I get more and more experienced, the shortcomings of go become too much to bear.

Fritsdehacker 5y ago

I think describing this article as a one sided rant isn't really fair. The author shows that Go makes a few design decisions that make it easy to shoot yourself in the foot. This is generally a bad idea. Rust may be the summum of correctness. In my view that makes it an ideal candidate for comparison. It shows the reader what a better solution would look like. And that this can work in practice. Does that mean you shouldn't write code in Go? No of course not. But I think the author has done a great job of showing why they don't want to use Go anymore.

philosopher1234 5y ago
It’s one sided when it points out the pitfalls without bothering to describe why they’re there, and what the upside is. There are sloppy mistakes in Go, just like in anything, but many of the common criticisms of go are about trade offs not about mistakes.
- Fritsdehacker 5y ago
  Sure, but the way I read the article, that's what the author shows. They don't like trade-offs that are made. Maybe the tone of the article feels a little aggressive towards Go, I don't know. To me it felt more like an outcry of frustration with the chosen trade-offs.

mirceal 5y ago

> He picks an arbitrary design constraint, in this case correctness, and argues that any language that does not provide 100% correctness is bad I'm sorry, WHAT? This is not about correctness (and IMHO if you have something that makes this tradeoff you should not use it anyway), it's about pretending that correctness does not matter and that unexpected bad behavior is okay... cause you know 80/20. IMHO Go has its use cases but it's definitely not a panacea. I don't mind people pragmatically picking it and using it. I am bothered by the zealots that think this is the best thing since sliced break (spoiler alert: it's not). Its authors and the community also seem to have an elitist / better than you default attitude when being humble and open would actually serve them better (package management and generics come into mind - what disasters)