One of my engineering highlights was Russ reviewing a few of my contributions to Golang (to the core http library). He's a super cool and nice guy. I don't really write that much Go anymore, but it was a fun & cute language when it first came out.
I 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.
While I'm highly sympathetic to competing priorities crowding out movement to pq cryptography. At the same time it's not sudden at all. It's been 10 years since nist first said "move shit over"?
Unfortunately for people SELECTing UUIDs out of a DB directly into a uuid struct, the built-in uuid structs don't implement the necessary interface for that, so you'll have to continue using the google package, or a plain string.
The database/sql package gained native support[1] for the uuid.UUID type so it will Just Work even without the methods. This probably should have been mentioned in the release notes and database/sql package docs.
Repeating the package name is fine if it's exactly the same name (modulo capitalization) and there's nothing better to name the type anyway. The style issue would arise with e.g. uuid.UUIDVersion, which should just be named uuid.Version. There used to be a gopls lint that would flag names like uuid.UUID but it got relaxed awhile ago.
> First, generic methods are now supported
> Generic functions can now be used without explicit type arguments
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
I 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.
There's a reason for this. Rob Pike was asked about it and said that syntax highlighting reminds him of the bright colors of children's toys and he personally disables it so that he can focus on the text.
I don't know why it's still like that but that's the original reasoning.
> Syntax highlighting is juvenile. When I was a child, I was taught
arithmetic using colored rods
(http://en.wikipedia.org/wiki/Cuisenaire_rods). I grew up and today I
use monochromatic numerals.
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.
That does exist, it's called semantic highlighting.
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.
That makes sense as a personal preference for him, but it's odd for that to still be the company/project stance. Like, surely he knows he's the minority for not wanting highlighting?
that's an extremely odd explanation and it makes me think that he has some hidden PTSD. it's also insane that one person's preference trumps the rest of the world's.
I understand and respect this position. I think syntax highlighting
is a highly subjective matter, bordering on personal preference with regard to shell interactions, editor configurations, bindings, shortcuts, snippets, and the like. It's also... insignificant somehow, like quibbles over formatting rules that Go settled once and for all with `go fmt`.
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.
> Second, a key in a struct literal may now be any valid field selector for the struct type, allowing fields in nested or embedded structs to be initialized directly
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
It will be very nice working with code generators like oapi-codegen that can generate either nested structs or very unwieldy struct names. So big in that context, but like you said just a nice qol improvement most of the time.
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.
This is only a small piece of the story for what people say when they want tagged unions. Without all of the ancillary support in the language, like exhaustive pattern matching, it really doesn't count.
That is a LOT of code (very ugly code, I would add) that could be replaced by `type Float = float32 | float64` in a language with actual support for union types.
Tagged unions are not union types. A union type is a supertype for any arbitrary collection of types, but a tagged union aka sum type is a single type with multiple data constructors, and does not require subtyping to be implemented.
The C++ committee said the same thing, and gave us std::variant. They are painful to work with and do not really deliver most of the benefits people want.
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.
I'm so glad the new uuid package landed - it's overdue but a very welcome addition! I've already replaced github.com/google/uuid with `uuid` in several projects
Agreed. I've recently translated a pangram generator project written in Rust [1] leveraging SIMD to do the same in Go [2] to see how it fairs in terms of speed - the results are pretty close. In my local machine I'm getting ~3GHz in Rust vs ~2.4GHz in Go, which I think is really impressive.
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 mean one thing frontier models are really good at is porting code with pretty low level of supervision. Provided there are enough fans porting packages from other ecosystems should not be a big challenge.
Used to code primarily in Java. Now my app stack is about 80% Go. I love that it enables lightweight application development. Glad to see the platform evolving with a focus on resource efficiency.
I love Go because even minor versions deliver great value like this. The struct literal inits and generic methods are great conveniences to clean up clumsy boilerplate.
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
Minor versions are basically major versions for Go. They’ll “never” create a Go v2 because they prioritise maintaining backwards compatibility as a language feature, thus following semver rules, no majors.
Being on the HN's homepage isn't as simple as "most upvoted articles in last X hours". They take into account upvote velocity: 40 upvotes in 40 minutes isn't the same as 40 upvotes in 4 yours.
Would you rather have yet another LLM-generated slop article in its place instead of an article covering a major release for a widely-used language? Out of all the articles that reach the HN front page, this is the one you have a problem with?
Wasn'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 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.
reply