However I’ve not had much success running it on CI, with at least the 1.27rcs. I encountered some panic deep within staticcheck, and ended up turning off that specific linter on CI (better than not running it at all).
There was a tracking issue for go1.27 support at [1]. However that is now closed, which might imply that it should be working.
go install golang.org/x/tools/gopls@latest
I like to imagine that one day we'll have a language that launched with all the features languages eventually add. The whole ecosystem of packages would be built on them instead of a legacy of more primitive language feature sets.
Standard ML is a perfect programming language from the 90s. It unfortunately does not have a great eco system of packages.
I just had excellent success migrating a go code base to rust completely AI driven. It led to a healthy performance boost too, as now I don’t need to worry about GC pressure contortions.
It's funny that you and many others have found the introduction of "generics" in Go to be highly valuable, considering one of the motivations for Go's existence was:
Its designers were primarily motivated by their shared dislike of C++[0]
DDJ: In the presentation before the awarding of the Japan
Prize today, you were quoted on the distinction between
reasearch and development. [The former, Thompson stated,
was directionless, whereas development had a specific goal
in mind.] So in that context, is Go experimental?
KT: Yes. When the three of us [Thompson, Rob Pike, and
Robert Griesemer] got started, it was pure research. The
three of us got together and decided that we hated C++.
[laughter] [2]
0 - https://en.wikipedia.org/wiki/Go_(programming_language)#Hist...
1 - https://commandcenter.blogspot.com/2012/06/less-is-exponenti...
2 - https://web.archive.org/web/20110521080746/http://drdobbs.co...
Rejecting templates does not mean rejecting generics.
This is provably incorrect.
The position held for many years by the language authors was[0]:
Generics may well be added at some point. We don't feel an
urgency for them, although we understand some programmers
do.
Generics are convenient but they come at a cost in
complexity in the type system and run-time. We haven't yet
found a design that gives value proportionate to the
complexity, although we continue to think about it.
Meanwhile, Go's built-in maps and slices, plus the ability
to use the empty interface to construct containers (with
explicit unboxing) mean in many cases it is possible to
write code that does what generics would enable, if less
smoothly.
The Go 1.18 release added type parameters to the language.
This permits a form of polymorphic or generic programming.
By run-time they mean compile-time? There shouldn't be a run-time penalty right?
Also, is there some measure of the additional compilation cost now that generics has been added?
However, the original announcement makes the intent of the project clear: "Not yet", not "never". They were always planned to be accepted into Go. But not before an acceptable solution was found.
They have successfully been able to add major features such as generics without breaking 1.0 compatibility, and the trend is to continue than way. Well there is no major language feature in sight in fact.
Also major figures of the Go team (Russ, Ian, Rob, Ken) are gone.
The `go fix` modernisers are also great, have already run them in several repos.
It sounds like the dumbest thing in the world, but I love the import system auto-adding stuff inside of vscode when I need it. just slick.