4 ms·

Seems many people mistake “well-designed” to mean “perfect”. Read the article: he doesn’t claim that. No language is perfect, they are all trade offs. Furtherm

Seems many people mistake “well-designed” to mean “perfect”. Read the article: he doesn’t claim that. No language is perfect, they are all trade offs. Furthermore, it’s fine to not like the design. It might not be to your taste or your requirements. But that doesn’t mean it wasn’t well designed. I can point to lots of things that I don’t like the design of that work great for others. Go is super productive, has a great ecosystem, has great concurrency, produces good machine code, compiles as fast as anything out there, has great tools, and is growing in popularity. Flaws? Of course. Perfect? No. But, it’s well designed.

kerkeslager 2y ago
> No language is perfect, they are all trade offs. Uh, no they're actually not. A tradeoff means you accept some downside and get some upside in return. Initially go was designed without generics. The tradeoff here was you got a single pass compiler which was faster. Well, actually, you could have a single-pass compiler with backpatching, but I get it, that's hard. It's a crap tradeoff, but okay, I can accept it's a tradeoff. And everybody at the time said, "Go doesn't need generics, they complicate the language." So we casted our nested types in and out of object and lost all type safety in that code, but hey, tradeoffs. Except everyone kinda realized it was a crap tradeoff and so `go generate` was proposed as a solution. In a 1984-esque revision of the past, suddenly, having a second pass is okay! Never mind how important it was that go is a single-pass compiler. Nevermind that this is basically macros with all their pitfalls. But now we can generate 3 different versions of the parameterized type, one for each nested type, so we get type safety. 2 passes, macros, downsides, type safety, upside, and a pretty big upside at that. But, here's the problem: now you have two different systems that are used for doing a lot of the same things that don't interoperate with each other very well. And that's not a tradeoff, because there's no upside. It's not "I don't like this but it works great for others" because it doesn't work great for anyone. It's not a tradeoff, it's a side effect of having chosen wrong the first time. And... now Go has generics. And yeah, generics aren't really a tradeoff, they're just obviously pretty good. But, now we've got 3 different systems for doing a lot of the same things, which again, don't interoperate all that well with each other. And here's the thing: from a language design perspective, this was extremely obvious that Go was going to need generics. Generics are pretty much the clearest win from the ML-family languages which had already made it into C# and Java by the time Go was conceived. It's absurd that this feature wasn't included in Go from the beginning.
- relistan 2y ago
  [flagged]
  - guappa 2y ago
    Replying to that extremely well argumented comment with what is basically "NO I AM RIGHT!" is disrespectful.
    - relistan 2y ago
      lol replying “uh no, they’re actually not“ is disrespectful. And I did reply with an argument. The “extremely well reasoned” argument is about trade offs, despite the claim otherwise.
  - kerkeslager 2y ago
    > You might not like the decision but trading flexibility for simplicity was a win for people learning the language. So I'm gathering you didn't read the entire post you're responding to. I fully agree that trading flexibility for simplicity is a tradeoff and never said otherwise. Sorry, buddy, this is an adult conversation and if you want to disagree with me you have to actually know what you're disagreeing with. Until you can be bothered to actually read the post and repeat back to me what I'm saying isn't a tradeoff, I'm not going to respond in any other way expect to restate the fact that your opinion on a post you haven't read is ignorant. So, what am I saying isn't a tradeoff?
guappa 2y ago
> has a great ecosystem A great ecosystem is one where there is good 1 library to do a thing and you just pick that one. A bad ecosystem is one where there are 25 libraries to do some things and 0 to do some other things, and none of the 25 libraries are very good.
- physicsguy 2y ago
  I feel like Go falls much into the latter category. I needed to write some code recently that did DSP. There is not any equivalent for this like SciPy in Go that bundles together lots of the common DSP operations you need. There are lots of partial implementations in different libraries of for e.g. filters, all of which use different interfaces. A lot of this I think is because of the lack of SIMD, you can't get brilliant performance out of the box with a Go implementation because the standard compiler doesn't support it.
stouset 2y ago
“Well-designed” involves making good tradeoffs where the upsides are useful and the downsides have manageable workarounds. Go certainly has its fair share of these. Go also has countless own-goals where a serious concession was made with zero or almost-zero upside. I won’t repeat them here. You can like go and you can feel that go is a productive language. But given the sheer number of outright mistakes which should have been avoided in the early days of the language’s design and which are now frozen for all eternity, you can’t in good faith call it well-designed.

kerkeslager 2y ago

> No language is perfect, they are all trade offs. Uh, no they're actually not. A tradeoff means you accept some downside and get some upside in return. Initially go was designed without generics. The tradeoff here was you got a single pass compiler which was faster. Well, actually, you could have a single-pass compiler with backpatching, but I get it, that's hard. It's a crap tradeoff, but okay, I can accept it's a tradeoff. And everybody at the time said, "Go doesn't need generics, they complicate the language." So we casted our nested types in and out of object and lost all type safety in that code, but hey, tradeoffs. Except everyone kinda realized it was a crap tradeoff and so `go generate` was proposed as a solution. In a 1984-esque revision of the past, suddenly, having a second pass is okay! Never mind how important it was that go is a single-pass compiler. Nevermind that this is basically macros with all their pitfalls. But now we can generate 3 different versions of the parameterized type, one for each nested type, so we get type safety. 2 passes, macros, downsides, type safety, upside, and a pretty big upside at that. But, here's the problem: now you have two different systems that are used for doing a lot of the same things that don't interoperate with each other very well. And that's not a tradeoff, because there's no upside. It's not "I don't like this but it works great for others" because it doesn't work great for anyone. It's not a tradeoff, it's a side effect of having chosen wrong the first time. And... now Go has generics. And yeah, generics aren't really a tradeoff, they're just obviously pretty good. But, now we've got 3 different systems for doing a lot of the same things, which again, don't interoperate all that well with each other. And here's the thing: from a language design perspective, this was extremely obvious that Go was going to need generics. Generics are pretty much the clearest win from the ML-family languages which had already made it into C# and Java by the time Go was conceived. It's absurd that this feature wasn't included in Go from the beginning.

relistan 2y ago
[flagged]
- guappa 2y ago
  Replying to that extremely well argumented comment with what is basically "NO I AM RIGHT!" is disrespectful.
  - relistan 2y ago
    lol replying “uh no, they’re actually not“ is disrespectful. And I did reply with an argument. The “extremely well reasoned” argument is about trade offs, despite the claim otherwise.
- kerkeslager 2y ago
  > You might not like the decision but trading flexibility for simplicity was a win for people learning the language. So I'm gathering you didn't read the entire post you're responding to. I fully agree that trading flexibility for simplicity is a tradeoff and never said otherwise. Sorry, buddy, this is an adult conversation and if you want to disagree with me you have to actually know what you're disagreeing with. Until you can be bothered to actually read the post and repeat back to me what I'm saying isn't a tradeoff, I'm not going to respond in any other way expect to restate the fact that your opinion on a post you haven't read is ignorant. So, what am I saying isn't a tradeoff?

guappa 2y ago

> has a great ecosystem A great ecosystem is one where there is good 1 library to do a thing and you just pick that one. A bad ecosystem is one where there are 25 libraries to do some things and 0 to do some other things, and none of the 25 libraries are very good.

physicsguy 2y ago
I feel like Go falls much into the latter category. I needed to write some code recently that did DSP. There is not any equivalent for this like SciPy in Go that bundles together lots of the common DSP operations you need. There are lots of partial implementations in different libraries of for e.g. filters, all of which use different interfaces. A lot of this I think is because of the lack of SIMD, you can't get brilliant performance out of the box with a Go implementation because the standard compiler doesn't support it.

stouset 2y ago

“Well-designed” involves making good tradeoffs where the upsides are useful and the downsides have manageable workarounds. Go certainly has its fair share of these. Go also has countless own-goals where a serious concession was made with zero or almost-zero upside. I won’t repeat them here. You can like go and you can feel that go is a productive language. But given the sheer number of outright mistakes which should have been avoided in the early days of the language’s design and which are now frozen for all eternity, you can’t in good faith call it well-designed.