71–80 of 82 posts
Earlier quoted context omitted.
If this was true, why did they add generics?
The generics that they eventually added, because of programming language market pressure, Kubernetes had an whole code generation gizmo to work around it, are a clunky implementation versus what could have been done if done from the get go.
Earlier quoted context omitted.
It's not really a hack. It's a hint to a static analyser, that's all.
Nah... I like Go, but this is a hack. Wiktionary --not the ultimate authority, I know, but still-- defines to hack as: To make a quick code change to patch a computer program, often one that, while being effective, is inelegant or makes the program harder to maintain. I could accept having an anonymous embedding as a kind of syntax directive. So many languages have had directives bolted on later, so that wouldn't be…
Earlier quoted context omitted.
I've not seen this in my experience tbh, the extra code that Go requires is ugly but not complex, the lack of ergonomics actively discourages "clever" solutions and, as a result of this, people tend to write the kind of straightforward code that doesn't end up needing lengthy programming or intense debugging. At my workplace we've used many languages over the years (C#, Python, Go) and Go teams are the ones that by f…
I’ve always felt like the lack of many complex language features nudges teams to also keep their code simple. There is always two aspects to a language works in practice: how it formally works, and how the community uses it. Go is (was?) simple, and also (encouraged by the language and influence from its developers) the community mostly aims to keep the usage simple.
For example, in typescript you can define a json value as something like:
type JSON = null | bool | string | number | [JSON] | {[k:string]: JSON}
The decision is baffling. Especially given go now has generics, which are waaay more complex than enums. And sum types in go could be used to fix the constant (result | error) boilerplate. And remove nullability. Sigh.
Earlier quoted context omitted.
The generics that they eventually added, because of programming language market pressure, Kubernetes had an whole code generation gizmo to work around it, are a clunky implementation versus what could have been done if done from the get go.
The generics implementation is perfectly fine. The fact that you completely dodged my question is telling. But please, keep living in your alternate reality.
"Market pressure for language adoption".
Just like all the features they keep adding where they said that Go doesn't need them in first place, turns out those features exist in other programming languages for a reason.
Earlier quoted context omitted.
The generics implementation is perfectly fine. The fact that you completely dodged my question is telling. But please, keep living in your alternate reality.
I did not dodge the question at all, you just didn't like the answer. "Market pressure for language adoption". Just like all the features they keep adding where they said that Go doesn't need them in first place, turns out those features exist in other programming languages for a reason.
2009 Go released.
June 2010 https://github.com/golang/proposal/blob/master/design/15292/...
Jan 2011 https://github.com/golang/proposal/blob/master/design/15292-...
March 2011 https://github.com/golang/proposal/blob/master/design/15292/...
Oct 2013 https://github.com/golang/proposal/blob/master/design/15292/...
Dec 2013 https://github.com/golang/proposal/blob/master/design/15292/...
April 2016 https://github.com/golang/go/issues/15292
Aug 2018 https://github.com/golang/proposal/blob/master/design/go2dra...
Aug 2018 https://github.com/golang/proposal/blob/master/design/go2dra...
June 2020 https://go.dev/blog/generics-next-step
Jan 2021 https://github.com/golang/go/issues/43651
Jan 2021 https://github.com/golang/proposal/blob/master/design/43651-...
Feb 2021 Proposal accepted.
March 2022 Ships in Go 1.18.
You could criticize Go for moving too slow. But I'm pretty happy with the way they landed. They definitely don't feel bolted-on.
Earlier quoted context omitted.
I did not dodge the question at all, you just didn't like the answer. "Market pressure for language adoption". Just like all the features they keep adding where they said that Go doesn't need them in first place, turns out those features exist in other programming languages for a reason.
This idea that they just caved and added them due to pressure is a false narrative invented by detractors like yourself. Here is a timeline if you're interested: 2009 Go released. June 2010 https://github.com/golang/proposal/blob/master/design/15292/... Jan 2011 https://github.com/golang/proposal/blob/master/design/15292-... March 2011 https://github.com/golang/proposal/blob/master/design/15292/... Oct 2013 https://g…
> In three years of Go surveys, lack of generics has always been listed as one of the top three problems to fix in the language.
https://blog.golang.org/why-generics
> 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://github.com/golang/proposal/blob/master/design/go2dra...
And naturally Rob Pike's pearl,
> think the transition to getting polymorphism into the language through generics is has still got some years to work through there's still things that don't quite work right
Earlier quoted context omitted.
This idea that they just caved and added them due to pressure is a false narrative invented by detractors like yourself. Here is a timeline if you're interested: 2009 Go released. June 2010 https://github.com/golang/proposal/blob/master/design/15292/... Jan 2011 https://github.com/golang/proposal/blob/master/design/15292-... March 2011 https://github.com/golang/proposal/blob/master/design/15292/... Oct 2013 https://g…
Ah the usual barrage of links from Go folks, luckily we have also come prepared. > In three years of Go surveys, lack of generics has always been listed as one of the top three problems to fix in the language. https://blog.golang.org/why-generics > 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++ concep…
Earlier quoted context omitted.
Ah the usual barrage of links from Go folks, luckily we have also come prepared. > In three years of Go surveys, lack of generics has always been listed as one of the top three problems to fix in the language. https://blog.golang.org/why-generics > 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++ concep…
If they didn't want to add generics, why were they actively working on generics proposals and designs since the inception of the language? Was it a hedge against the potential of being pressured into adding them in the future?
Earlier quoted context omitted.
If they didn't want to add generics, why were they actively working on generics proposals and designs since the inception of the language? Was it a hedge against the potential of being pressured into adding them in the future?
Go survey results....
Earlier quoted context omitted.
Go survey results....
The survey started in 2016. But even if it didn't, that still wouldn't make a difference. You're clearly not a serious person, so I think I'm done responding.
Seriousness is a hard topic among Gophers, what today does not matter, is apparently quite relevant tomorrow, and generics aren't the only example where this kind of pivots take place.
So whatever.