3 ms·

I totally get that. Java is my favorite language for exactly that reason. They are a deliberate "late mover language" and adopt what other languages have proven

I totally get that. Java is my favorite language for exactly that reason. They are a deliberate "late mover language" and adopt what other languages have proven right. But looking at how adamant Go used to be on the whole "No Generics" stance and the path and the troubles they are having... it all seemes so preventable?

farfatched 3mo ago
I think it was. Go without generics was ok. I say that as a fan of generics in other languages. There is room for languages with simpler feature sets. It takes a strong leader (and the good and bad that comes with that) to continue to deny features. Go had that. Does it still? (I genuinely don't know.) I'm not sure what Go's value proposition is now. Developers can't pick it up in a week, as it used to be. Maybe that's okay too, since Go already has critical mass.
- ako 3mo ago
  Go value proposition for me, when developing with Claude code: 1) fast compilation times, faster iterations, 2) user friendly to install, one single binary per platform, 3) feels safer than JavaScript/typescript, which have too many npm vulnerabilities. Go comes with more functionality included, less need to use 3rd party libraries.
  - farfatched 3mo ago
    That's fair. In addition, I'd add the great compatibility guarantees, and a community that makes easy-to-learn libraries.
- LVB 3mo ago
  I don’t feel like the learning curve has shifted dramatically for mainstream development. Besides generics—which tend to not show up that often in app code even now—I can’t think of any substantial language change since I Iearned it in 2014. (Well, modules, but that’s more tooling.) Where I do see the shock is jumping to def of a std lib function and landing in indecipherable type soup.
- kamma4434 3mo ago
  > Go without generics was ok. I say that as a fan of generics in other languages. Well kinda. I found it very annoying every time you want to print a sorted map which keys are strings that you could not abstract the operation. It felt like paying a stupidity tax. (And I quite like go. It’s the only language where write once run everywhere actually works. Cross compiling for all targets is as easy as creating a local binary)
- hwc 3mo ago
  > Developers can't pick it up in a week... I don't think any of the new additions to the library have seriously made the learning curve more difficult. I suspect that most projects don't use templates at all. There have always been parts of the standard library I'm not familiar with. when I read code that uses it, I just go read the documentation. Now the standard library is just larger.
  - kubanczyk 3mo ago
    > I don't think any of the new additions to the library have seriously made the learning curve more difficult. Ah, so you haven't looked into json/v2 yet.
deleted 3mo ago
[deleted]
win311fwg 3mo ago
Does it? It was only preventable by not releasing Go, which isn't exactly the greatest of solutions. As you know from when Go was first broadcast to the world, they hadn't figured out how to make generics fit[1]. It is not like they weren't trying. Ian Lance Taylor is regarded for beginning work on generics before anyone outside of Google had even heard of Go. "In short: not yet" What was surprising is that after Go was released as an open source project, nobody across the whole wide world ever came up with a workable solution. You can sense the optimism in that original announcement that later turned to "Go might never get generics" dispair. As you'll recall, it finally took convincing Philip Wadler (of Haskell and Java generics fame) to help. Without that lucky break, which almost certainly never would have happened if Go was still some basement project used by nobody, Go probably still wouldn't have generics. [1] https://youtu.be/rKnDgT73v8s?t=3267 https://youtu.be/rKnDgT73v8s?t=3267
- pjmlp 3mo ago
  More like no one on the world was able to change their mind, and then they had to ask help to someone that could already have provided help before Go released 1.0 version. "They are likely the two most difficult parts of any design for parametric polymorphism. In retrospect, we were biased too much by experience with C++ without concepts and Java generics. We would have been well-served to spend more time with CLU and C++ concepts earlier." https://go.googlesource.com/proposal/+/master/design/go2draft-generics-overview.md https://go.googlesource.com/proposal/+/master/design/go2draf...
  - win311fwg 3mo ago
    Quite right. If the Go team somehow magically had the right technical background Go would have had generics earlier, but they didn't and weren't going to magically get it, so we're back to the only preventable way was to not release it at all. But one would think that of the billions of people in the world that someone outside of the Go team would have had that familiarity to quickly change that, but no proposals came from that direction for over a decade and a lot of begging. I suppose those who had the chops were too busy constantly posting on HN about how Go doesn't have generics to lend their expertise. Priorities. It's great to reflect back in hindsight about where you failed, but it's always easy to see where you failed after someone else finally shows you the way. The simple fact that the Go team did not have the technical capability to be able to add generics at the time remains. Being able to create a relatively popular programming language (or set of popular programming languages for some of them) certainly does not imply that you are a programming language expert. There may even be an inverse correlation. Those who show to be programming language gods appear most likely to end up creating esoteric languages that end up on the pile of languages that remain unknown and unused.
shikck200 3mo ago
Go never was "no generics". It had generics rusted in from the get-go, but never implemented them as it was a complex feature and one that made the compiler slower. Im glad they waited. Compare to PHP, where every feature is bolted on and then you end up supporting it forever.
- TZubiri 3mo ago
  A very common trap I find myself falling into is forgetting that there's a difference between the language, and the most common compiler/interpreter implementation. It's a very practical simplification since 99% of the time, that's what we use. 'It's in the language, we just don't use it' does sound like copeful technicality, until it isn't and it's an actually impactful difference.

farfatched 3mo ago

I think it was. Go without generics was ok. I say that as a fan of generics in other languages. There is room for languages with simpler feature sets. It takes a strong leader (and the good and bad that comes with that) to continue to deny features. Go had that. Does it still? (I genuinely don't know.) I'm not sure what Go's value proposition is now. Developers can't pick it up in a week, as it used to be. Maybe that's okay too, since Go already has critical mass.

ako 3mo ago
Go value proposition for me, when developing with Claude code: 1) fast compilation times, faster iterations, 2) user friendly to install, one single binary per platform, 3) feels safer than JavaScript/typescript, which have too many npm vulnerabilities. Go comes with more functionality included, less need to use 3rd party libraries.
- farfatched 3mo ago
  That's fair. In addition, I'd add the great compatibility guarantees, and a community that makes easy-to-learn libraries.
LVB 3mo ago
I don’t feel like the learning curve has shifted dramatically for mainstream development. Besides generics—which tend to not show up that often in app code even now—I can’t think of any substantial language change since I Iearned it in 2014. (Well, modules, but that’s more tooling.) Where I do see the shock is jumping to def of a std lib function and landing in indecipherable type soup.
kamma4434 3mo ago
> Go without generics was ok. I say that as a fan of generics in other languages. Well kinda. I found it very annoying every time you want to print a sorted map which keys are strings that you could not abstract the operation. It felt like paying a stupidity tax. (And I quite like go. It’s the only language where write once run everywhere actually works. Cross compiling for all targets is as easy as creating a local binary)
hwc 3mo ago
> Developers can't pick it up in a week... I don't think any of the new additions to the library have seriously made the learning curve more difficult. I suspect that most projects don't use templates at all. There have always been parts of the standard library I'm not familiar with. when I read code that uses it, I just go read the documentation. Now the standard library is just larger.
- kubanczyk 3mo ago
  > I don't think any of the new additions to the library have seriously made the learning curve more difficult. Ah, so you haven't looked into json/v2 yet.

deleted 3mo ago

[deleted]

win311fwg 3mo ago

Does it? It was only preventable by not releasing Go, which isn't exactly the greatest of solutions. As you know from when Go was first broadcast to the world, they hadn't figured out how to make generics fit[1]. It is not like they weren't trying. Ian Lance Taylor is regarded for beginning work on generics before anyone outside of Google had even heard of Go. "In short: not yet" What was surprising is that after Go was released as an open source project, nobody across the whole wide world ever came up with a workable solution. You can sense the optimism in that original announcement that later turned to "Go might never get generics" dispair. As you'll recall, it finally took convincing Philip Wadler (of Haskell and Java generics fame) to help. Without that lucky break, which almost certainly never would have happened if Go was still some basement project used by nobody, Go probably still wouldn't have generics. [1] https://youtu.be/rKnDgT73v8s?t=3267 https://youtu.be/rKnDgT73v8s?t=3267

pjmlp 3mo ago
More like no one on the world was able to change their mind, and then they had to ask help to someone that could already have provided help before Go released 1.0 version. "They are likely the two most difficult parts of any design for parametric polymorphism. In retrospect, we were biased too much by experience with C++ without concepts and Java generics. We would have been well-served to spend more time with CLU and C++ concepts earlier." https://go.googlesource.com/proposal/+/master/design/go2draft-generics-overview.md https://go.googlesource.com/proposal/+/master/design/go2draf...
- win311fwg 3mo ago
  Quite right. If the Go team somehow magically had the right technical background Go would have had generics earlier, but they didn't and weren't going to magically get it, so we're back to the only preventable way was to not release it at all. But one would think that of the billions of people in the world that someone outside of the Go team would have had that familiarity to quickly change that, but no proposals came from that direction for over a decade and a lot of begging. I suppose those who had the chops were too busy constantly posting on HN about how Go doesn't have generics to lend their expertise. Priorities. It's great to reflect back in hindsight about where you failed, but it's always easy to see where you failed after someone else finally shows you the way. The simple fact that the Go team did not have the technical capability to be able to add generics at the time remains. Being able to create a relatively popular programming language (or set of popular programming languages for some of them) certainly does not imply that you are a programming language expert. There may even be an inverse correlation. Those who show to be programming language gods appear most likely to end up creating esoteric languages that end up on the pile of languages that remain unknown and unused.

shikck200 3mo ago

Go never was "no generics". It had generics rusted in from the get-go, but never implemented them as it was a complex feature and one that made the compiler slower. Im glad they waited. Compare to PHP, where every feature is bolted on and then you end up supporting it forever.

TZubiri 3mo ago
A very common trap I find myself falling into is forgetting that there's a difference between the language, and the most common compiler/interpreter implementation. It's a very practical simplification since 99% of the time, that's what we use. 'It's in the language, we just don't use it' does sound like copeful technicality, until it isn't and it's an actually impactful difference.