Earlier quoted context omitted.
I'm pretty sure there is a silent majority of Go users who don't want/need/know about generics.
And they can simply not use them ?
Indeed ! So I don't see what the problem is here...
Go 1.27
191–200 of 277 posts
Re: Go 1.27
#192I love these release notes but I really wish they would add syntax highlighting to the Go blog. I'm always a little bit surprised/disappointed whenever I land on a go.dev link since I know the code will be just a little harder to visually parse than it needs to be.
When I started learning Go I went all in including using the recommended editor (acme editor) which has no syntax highlighting, no autocomplete and a very different way of writing code. My production went down a lot but the quality of the code went up a lot. I think the lack of syntax highlighting was one reason for that. It makes you think more about the code you write and how it should compose, while a fully fledge…
Are you using the Go fonts?
Re: Go 1.27
#193Earlier quoted context omitted.
Which error? https://go.dev/play/p/CFWVXkFBOEX Note that I added a name field to Line. Data: {edge black} -- {{edge black} {{ } 0 0 0} {{ } 0 0 0} diagonal} Oops now Object.name is empty, which is my point.
./prog.go:20:29: cannot specify promoted field name and enclosing embedded field Object Which is what you get if you don't add a direct "name" field to Line, because it's then completely unambiguous, the deeper "name"s are not promotable.
Yeah, but that isn't what I am talking about.
The whole point is the implicit bug, when the field is added and initialisation code rewritten to take advantage of this feature, without the developer realising the clash in first place.
Re: Go 1.27
#194Earlier quoted context omitted.
> Generics are convenient but they come at a cost in complexity in the type system and run-time. 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?
The “runtime” as in the compiler runtime which provides the scheduler, garbage collector, etc.
The runtime also includes reflection, so preserving compatibility of the type system while adding generics was definitely a challenge, so adding generics to Go was definitely a great achievement.
Re: Go 1.27
#195I love how proactive the crypto team is about post quantum. They released https://pkg.go.dev/crypto/mldsa . The lead maintainer Filippo Valsorda wrote a nice piece here[1] to urge the tech world to start deploying good enough versions of post quantum crypto. [1] https://words.filippo.io/crqc-timeline/
The .NET team have been similarly busy on post-quantum lately, it completely dominated the .NET API reviews for the dotnet 11 release. It seems there's a big push happening behind the scenes.
And Java implementations as well.
Re: Go 1.27
#196Earlier quoted context omitted.
Considering that Ian was already working on them before 1.0, and never stopped until a solution was found, we know for certain they were planned by at least one person on the Go team. If you are struggling to say that Go people are not a single monolith then sure. Nobody has ever thought people are a single monolith. However, the original announcement makes the intent of the project clear: "Not yet", not "never". The…
Do we know if Go team is working in 2.0 release?
We know they aren't.
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.
Re: Go 1.27
#197Not mentioned: Floating-point parsing and formatting now uses Russ Cox's uscale algorithm. https://research.swtch.com/fp https://github.com/golang/go/blob/go1.27.0/src/internal/strc...
I’d love to see how that compares to zmij: https://github.com/dtolnay/dtoa-benchmark
The upstream fmtlib dtoa-benchmark integrates uscale (https://fmtlib.github.io/dtoa-benchmark/results/). It uses C code from Russ Cox's original fpfmt repository (https://github.com/rsc/fpfmt/tree/main/bench/uscalec), which is slightly different from the Go code upthread.
Zmij and xjb are in a league of their own. Broadly speaking, dtoa first has to find the shortest decimal representation of the floating-point input, and then format that decimal representation into a string. Zmij and xjb pull far ahead of the others mostly by speeding up the second part of that process.
uscale is quite good without the stringification, as are many other algorithms. I would say uscale's main strength isn't its speed, but rather its simplicity and, more importantly, the fact that it does both formatting and parsing using a single ~11 KiB table, which no other state-of-the-art algorithm offers (although yy comes close).
Re: Go 1.27
#198Re: Go 1.27
#199does it have goroutine termination, i recently found out you need a runtime patch for it
The rule is to start a goroutine only if you know how it will end.
A goroutine that has to be killed (no other way to tell it to stop) is a bug.
Re: Go 1.27
#200Not mentioned: Floating-point parsing and formatting now uses Russ Cox's uscale algorithm. https://research.swtch.com/fp https://github.com/golang/go/blob/go1.27.0/src/internal/strc...
See also this recent (Aug 6th) interview of Russ Cox: