does it have goroutine termination, i recently found out you need a runtime patch for it
No. You're down a very bad path if you 're seeking that.
Go 1.27
261–270 of 277 posts
Re: Go 1.27
#262Earlier quoted context omitted.
Personally I feel go has many issues and is ugly as hell but the error handling is really the least of my worries.
It's the ugly as hell part that gets me.
Pretty childish. People have no trouble looking past it when they care about actually shipping reliable software that properly handles all code paths. Including error paths that are ignored in so many codebases.
Re: Go 1.27
#263Wasn't Go supposed to be "simple"? I remember how Go advocates used to boast about not having generics and now it almost seems like Go is trying to become some sort of C# or Java Frankenstein. I'm not even trying to badmouth Golang - just legitimately confused.
> almost seems like Go is trying to become some sort of C# or Java Frankenstein The original Go team was trying to avoid this: "Java, JavaScript (ECMAScript), Typescript, C#, C++, Hack (PHP), and more [...] actively borrow features from one another. They are converging into a single huge language." [0] That team has since moved on, and now Go has begun to join that convergence. The problem is that most programmers se…
One can hope that the Go maintainers won't keep caving as they did for generics.
Re: Go 1.27
#264Earlier quoted context omitted.
Go is extremely easy to pickup. If you know any language you probably know Go already for the most part (channels notwithstanding). I wouldn't say it is a "beautiful" language however. Though that is in the eye of the beholder, I don't think the Go designers were even really going for beauty.
They were going for readability. You can make some impossible to read code with C++ because the programmer was too clever, and the designers of golang wanted to avoid that.
Exactly. I was talking more about readability.
Re: Go 1.27
#265Earlier quoted context omitted.
The only, single, complaint is that this possible source of bugs should be part of go vet, just like in other programming languages static analysis tooling, Sonar, PVS, clang-tidy, Roslyn, Checkstyle, clippy, PMD,.... catch such kind of flaws. However I see that I crash again in the Go versus other programming languages ecosystems mindset.
You, or $YOU, could add that as a linter and integrate it into golangci-lint [1]. There are many things in golangci-lint that I abhor and can't even imagine turning on, things that default to false that I can't imagine working without, and some things I think just bizarre... and everyone will have their own distinct list of such things. While one can argue about the virtues of things being in linters versus in the la…
Fair enough.
Re: Go 1.27
#266Earlier quoted context omitted.
It's the ugly as hell part that gets me.
Pretty childish. People have no trouble looking past it when they care about actually shipping reliable software that properly handles all code paths. Including error paths that are ignored in so many codebases.
I don't think it's childish to dislike verbosity in a language. Readability is important. There is a reason why there are so many programming languages that compile to Go: https://github.com/ubavic/compiles-to-go
Re: Go 1.27
#267Earlier quoted context omitted.
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 i…
The core of newer methods like yy, xjb and zmij is remarkably simple: https://vitaut.net/posts/2026/yy-dtoa/. Shortest uscale is basically Schubfach or, rather, it's variant called Teju Jagua and has 2-3 wide multiplications compared to 1 for newer methods.
The complexity is optional and comes from squeezing the last few nanoseconds =).
Re: Go 1.27
#268Earlier quoted context omitted.
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 i…
The core of newer methods like yy, xjb and zmij is remarkably simple: https://vitaut.net/posts/2026/yy-dtoa/ . Shortest uscale is basically Schubfach or, rather, it's variant called Teju Jagua and has 2-3 wide multiplications compared to 1 for newer methods. The complexity is optional and comes from squeezing the last few nanoseconds =).
Right, that's basically what I was trying to say (in so many words). I learned a lot from your dtoa blog posts and Zmij's implementation. Thank you!
> has 2-3 wide multiplications compared to 1 for newer methods.
As written, the `shortFloat()` function always calls `uscale()` two times, followed by an optional third call. Each `uscale()` does two wide multiplications (one full 64x64->128 and one 64x64->hi64, in case we want to make that distinction), so that works out to either 4 or 6 wide multiplications in total. I think `shortFloat()` could be rewritten to always do exactly 2 wide multiplications (both 64x64->128) at the cost of some more ALU operations. However, I don't see how that could be further reduced to only one wide multiplication.
EDIT: Going back to look at Zmij's to_decimal, I just realized that it also doesn't do just one wide multiplication in the sense I originally meant, so what you're saying is likely correct in the first place. I overzealously used a different definition of "wide multiplication", which I probably should've realized, given the fact that my numbers are exactly double yours, but alas. My apologies.
Re: Go 1.27
#269Nice additions to go. 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.
> I like to imagine that one day we'll have a language that launched with all the features languages eventually add.
Don't most languages on the heap of languages nobody uses fulfill that?
Re: Go 1.27
#270Earlier quoted context omitted.
> Generics were always planned, of course ... 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 t…
"May well be added at some point" it said and added they were at some point.
> "May well be added at some point" it said and added they were at some point.
That is a very selective quote which does not reflect the context I provided. So I will extract a selective quote which negates the above:
We haven't yet found a design that gives value
proportionate to the complexity ...