https://github.com/golang/go/blob/go1.27.0/src/internal/strc...
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).
The complexity is optional and comes from squeezing the last few nanoseconds =).
> 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.
ssh (as noted in tfa) has had pq defaults since 2022.
On a side note, "bold faced" does not mean the persons face is bold, only that it is said boldly, which implies a level of rudeness that "bald-faced" or "bare-faced" does not.
You're probably referencing https://english.stackexchange.com/questions/137551/bald-face... — but see in particular the "Update" section of the top answer.
Modern references seem to align (for instance, Garner's): Bald-faced and bare-faced have slightly different connotation than bold-faced. Despite "bold-faced lie" being in somewhat common use, "bald-faced lie" is more common (over 2x according to google stats), and overwhelmingly agreed upon as the "literate" choice, unless an author intends to refer to the sort of lie that would headline an article.
Generally, something to be avoided by people striving for clearer communication. =3
Their communication seemed pretty clear to me. If anyone actually claims that they didn't understand what they meant but would have understood it by using the other form of the expression, I think that's a bold-faced lie.
It seems there's a big push happening behind the scenes.
> BoringSSL is a fork of OpenSSL that is designed to meet Google's needs.
> Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.
OpenSSL itself is a clusterfuck that doesn't really meet anyone's needs: https://cryptography.io/en/latest/statements/state-of-openss...
Kubernetes project will be the first one [3] I guarantee it.
[1] https://pkg.go.dev/github.com/google/uuid
[3] https://github.com/kubernetes/kubernetes/blob/2220c3853a2402...
[1] https://cs.opensource.google/go/go/+/refs/tags/go1.27.0:src/...
The rule has always been intended to cover types that have another word in them but still choose to pointlessly repeat the package name.
`uuid.UUIDGenerator` is a hypothetical example of the anti-pattern that would instead be better named as `uuid.Generator`.
Ocaml often just has it be T
so uuid.T
https://pkg.go.dev/github.com/domonda/go-types@v0.0.0-202607...
If you want to keep your package implementation agnostic, use [16]byte as argument type; that's assignment-compatible with any other type that is such an array underneath:
For an example, see the UUID logging of golog: https://pkg.go.dev/github.com/domonda/golog#Message.UUID
Great! This was an ergonomic code issue I hit when trying to create a universal handler/controller generic that could hydrate/populate function arguments (from a request body) without having an actual copy of the arguments: https://github.com/xeoncross/mid/blob/main/handler.go#L12
Btw, the Gin and Echo examples reference an "input" variable but it doesn't seem to be defined there? Maybe it was intentional, since the examples are just to give a general idea of how the handler looks in each library, but thought I would let you know just in case it wasn't.
I don't know why it's still like that but that's the original reasoning.
https://groups.google.com/g/golang-nuts/c/hJHCAaiL0so/m/kG3B...
The reason traffic lights are colored is because they are showing distinct states of the same thing and the color is the means of differentiating.
Same for transit maps: different routes are colored to distinguish them from other routes, which is especially useful if they overlap.
But that’s not what syntax highlighting does.
The equivalent of your examples would be to not highlight the syntax at all, but only use color coding to distinguish variables.
The equivalent of how syntax highlighting currently works for your examples would be if the light fixture was one color, and the light pole was another, but then all the actual lights were the same color.
I actually think highlighting only the variables with distinct colors could be extremely valuable. Would certainly help avoid mistakes with nested i/j loop counters.
Edit to add: come to think of it, it would have been even more valuable in Go, until recently anyway. The variable color coding would expose the common loop variable instance bugs, because a programmer would be instantly puzzled by the unexpected coloring.
In any case, my analogy was not perfect, but neither was Russ's! The point is it's totally normal and not "childish" to use colours to help distinguish things. Traffic lights do not technically need colours (you can use the position of the lights - I assume that's what badly colourblind people do). Nor do transit maps technically need colours - you could just label the lines, or use patterns.
https://www.flickr.com/photos/gywst/1407078279
It's completely absurd to say that colours are childish because they can help children.
Despite its huge size and it installing several services that constantly run in the background, it's still one of my favorite "languages" of all time. It's the only one I've ever seen people going from never having programmed before to making simple but meaningful contributions in within a single day.
I wonder if traffic lights were invented today, would it be just one light changing colour?
> Gofmt was written to reduce the number of pointless discussions about code formatting. It succeeded admirably. I'm sad to say it had no effect whatsoever on the number of pointless discussions about syntax highlighting, or as I prefer to call it, spitzensparken blinkelichtzen.
> When I was a child, I used to speak like a child, think like a child, reason like a child; when I became a man, I did away with childish things.
I sincerely hope Rob Pike was being sarcastic/ironic, because otherwise, he sounds insufferable
https://www.biblegateway.com/passage/?search=1%20Corinthians...
Oh come on, I like syntax highlights, but this is not "insufferable". It's just opinions expressed strongly, with probably some tounge-in-cheek
"Everyone who uses syntax highlighting is a child"
I mean, maybe he was genuinely trying to make a joke, but I'm well past the point of assuming random strangers are joking when they're being offensively dumb.
> Gofmt's style is no one's favorite, yet gofmt is everyone's favorite.
Opinionated standard formatting is now the default.
https://groups.google.com/g/golang-nuts/c/hJHCAaiL0so/m/6STj...
I often prefer not to enable syntax highlighting just for color. Occasionally I'd choose some minimal theme that only highlights string literals and keywords. So it has two or three colors. But some of the color schemes I see are a festival of lights where every special element of syntax has its own color. I don't understand how that is supposed to help me parse anything and why the rules are complex. The `range` keyword needs to be purple, and `chan` must be navy blue. Why exactly? And every site has a different color scheme? There is no consensus, and there shouldn't be.
For a serious community-driven project like Go, dealing with the question of syntax highlighting is strange. The creators deliberately avoided the questions of IDEs and editors for Go, leaving them to the community. I think the same principle applies here.
Exactly. This is fundamentally about accessibility (in the broadest sense). Do people have opinionated screenreader settings they like to force on others too?
Personally I can't say when I was last actually aware of syntax highlighting. The only time I'm actively engaged with it is to change the default low contrast comment color that a lot of themes have (for some reason, as if comments are unimportant / noise) to something better. For Go, I don't really notice when it has or doesn't have syntax highlighting, at least not on e.g. go's website.
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 fledged IDE encourages you to just throw more code at the problem.
I think the ACME way should be used for love of code and ideally when you want to create libraries that stand the test of time. When you just want to get things done fast bring the full IDE and now some LLM vibes and it’s done.
I experience something similar with system design, where the act of creating a diagram helps me to understand much faster than trying to read someone else’s diagram. It’s not because only I can create good diagrams (I cannot) but again because the act of creating one helps me internalize the design.
I think a lot of people lose this over time because it's easier to use templates, autocomplete and LLMs, work from a higher level. But it's nice to go back to basics. Consider also firing up Pico-8 and writing some really really bad code. It's got a very rudimentary editor, 40 columns of code, no syntax highlighting, and you're limited in how much total code you can write. It also helps with leetcode since a lot of leetcode uses game coding tricks like modulo operators, min/max/clamp, etc (that's as far as I got, don't judge).
I wonder if the Go fonts has been created just to get a trademark on the "Go" word...
It's more likely that they don't feel the need to use the font they gave you (for your code editor) on code samples on their own web pages. As it's a custom font, the text would be susceptible to pop-in, or would visibly switch from one font to another, both of which are ugly.
Their CSS says this:
#blog .Article[data-slug='/blog/go-fonts'] code {
font-family: 'Go Mono', monospace;
}
#blog pre,
#blog code {
font-family: monospace;
}
EDIT: just force reload https://go.dev/blog/go-fonts and look at the first hyperlink, "golang.org/x/exp/shiny". Watch it visibly switch from generic monospace font to Go Mono as the page loads. Janky! They probably don't want that for all their code samples ever.
type Habitat struct { Burrow string }
type Gopher struct { Name string Burrow string Habitat }
It will not initialise what one expects, here it is a contrived example, however it may not be easy to spot in more complex source code.
https://go.dev/play/p/dsY6tK5S8Ie
Better generics and improved SIMD are nice additions as well.
Your contrived example doesn't initialise the embedded struct that also contains a "Burrow" field. If it did that at all, even without naming the Burrow field... you would not be allowed to initialise the struct, because of the ambiguity.
https://go.dev/ref/spec#Composite_literals
> A key must not denote a promoted field inside an embedded struct if that struct is also specified by another key.
> Given the declarations
type Object struct { name, color string }
type Point3D struct { Object; x, y, z float64 }
type Line struct { Object; p, q Point3D }
obj := Object{"edge", "black"}
line3 := Line{Object: obj, name: "diagonal"} // invalid: name denotes a field inside Objecthttps://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}
./prog.go:20:29: cannot specify promoted field name and enclosing embedded field Object
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.
The rule errs in favour of the developer and the struct they can see. Initialising (or accessing!) a named field always picks the one in the top-level struct if you have one there. It'll be there because you added it. Promoted fields can only get promoted if they are unambiguous.
If you don't want to take advantage of that, you can write in full:
g := Gopher{
Name: "Gopher",
Burrow: "Burrow #42",
Habitat: Habitat{Burrow: "Wild Acres"},
}
fmt.Println("Your burrow: ", g.Burrow)
fmt.Println("I mean your _real_ burrow: ", g.Habitat.Burrow)
Most of them are very happy that they can embed some other type they don't know the full contents of, knowing they can access (and now initialise!) fields in it they care about, and thus don't give the fields in their own types the same name, while resting assured that if that other type later gains new fields they've never heard of, it's not going to clash with their own naming choices and break their code and force them to rename something. Their types' field names always come out on top, in their code.
You're doing "but what if I deliberately named my type's fields the same as the embedded type's fields?", which is like "but what if I deliberately stuck my hand in the meat grinder?" -- don't do that
However I see that I crash again in the Go versus other programming languages ecosystems mindset.
In the before times this would be not very helpful but in 2026 this is probably about 30 minutes of your actual time and maybe a couple of hours of AI time. The code isn't too hard to write but there are a number of edge cases to cover, as there always is in this sort of thing.
I understand the need not to break existing code that might have such fields.
It's been a while since I've written more than anything trivial in golang, but this seems like a big deal to me. As in, I can define a struct that is consistent and reusable in other structs
Sure a SIMD expert writing assembly can probably do a better job than an LLM using these new intrinsics, but it’s still massively faster.
It's relatively straightforward to read and to write code using Go's SIMD package (the caveat being that you have to convert your data to SoA manually), and it gives comparable performance to other languages, since there's little in the way of GC overhead, bounds checking, etc, in this case.
So SIMD not only increases performance on its own, but it also closes the performance gap between Go and C++ / Rust, which has been a major cause for rewrites in the past. The memory usage overhead due to GC doesn't go anywhere of course, so there are still performance reasons to "Rewrite in Rust", but it's now become much easier to just optimise the hell out of Go code instead.
I do still wish it had discriminated unions (algebraic data types) and some better error handling ergonomics.
https://github.com/golang/go/issues/76920
You might want to follow this proposal, if you aren't already. It's the most recent one, and it's supported by quite a few “core members” of the Go Team. I don't think it'll land in 1.28, but I like the fact that it's still a feature that's being actively discussed.
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.
Not to mention it’s just a dream language to work with , especially when building concurrent applications. I love engaging all of my cores. And memory is so expensive nowadays
go install golang.org/x/tools/gopls@latest
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.
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.
Don't most languages on the heap of languages nobody uses fulfill that?
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.
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.
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.
> However, the original announcement makes the intent of the project clear: "Not yet", not "never". They were always planned to be accepted into Go.
This is an exceedingly charitable interpretation of the position held by at least one Go language designer (Rob Pike)[0]:
Notice that Robert said C was the starting point, not C++.
I'm not certain but I believe he meant C proper, especially
because Ken was there. But it's also true that, in the end,
we didn't really start from C. We built from scratch,
borrowing only minor things like operators and brace
brackets and a few common keywords.
In the end of course it came out quite different from
either C or C++. More different even than many realize. I
made a list of significant simplifications in Go over C and
C++:
...
- no templates
...
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.
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 ...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?
I laughed at the thought in the moment and now understand the wisdom shared with me.
0 - https://en.wikipedia.org/wiki/Lisp_(programming_language)
The `go fix` modernisers are also great, have already run them in several repos.
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 seem to want to write Java, more-or-less. New, simpler languages come along, but once they get popular, the pressure is on to turn them into Java-likes. It happened to Python and now it’s happening to Go. It takes a strong will for language maintainers to say “no”, and their language will suffer in popularity as a result - see, for example, Ruby.
[0] https://go.dev/talks/2015/simplicity-is-complicated.slide#5
You can have more complex languages like Scala that provide stronger modeling ability, but at the cost of complexity. Golang started off as extremely naive/simplistic, and is now converging in some ways. But it still has a ways to go: no generics on interfaces, no unions/ADTs, no pattern matching, no proper enums, error handling leaves much to be desired, and much more.
A goroutine that has to be killed (no other way to tell it to stop) is a bug.
(Having the go statement return a handle that you can block on would of course be completely fine, but at this point they're probably not going to do that either.)
I have run both Go and Python backends in production for years. There is an entire class of bugs present in Python services (missing error handling) that simply does not happen in my Go services.
Python puts the burden of knowing what exception types a function call will raise on the caller, in Go I just check for err. Even if I do not anticipate every failure mode the Go call will raise, I will always log the error and handle it in a controlled manner. I couldn’t count the number of times I’ve encountered an unhandled exception in my Python code, and often in such a case the logging will be lacklustre because you will just see a huge stack trace, but lose the contextual logging I would have automatically added in Go.
Perhaps a syntactic sugar is in order to reduce verbosity.
I try to avoid exceptions, is there any better ways? (Variant looks a bit more complicated but could be a totally OK alternative)
The tl;dr boils down to a combination of valuing both compilation speed and execution speed.