Hacker News

See also this recent (Aug 6th) interview of Russ Cox:

https://www.acm.org/articles/people-of-acm/2026/russ-cox

https://news.ycombinator.com/item?id=49327408

I’m so happy Russ still contributes even though he isn’t lead anymore. I always enjoy reading his blog posts

I seriously wonder why this isn't mentioned in release notes.

I’d love to see how that compares to zmij: https://github.com/dtolnay/dtoa-benchmark

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"?

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.

This person was public on the recent nist list against hybrid solutions. I simply don't understand why they would oppose the safer option. Yes I've read the mailing list, it just all seems quite suspicious.

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.

will 'go fix' take care of this?

Go has had this behaviour for promoting fields (provided they don't clash) for some time, this is just extending the language feature to initialisers.

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 Object

I'd say it is as expected https://go.dev/play/p/sy6SMrOiw4y

Mhm, probably worth a golang-ci check for duplicate field names which are accessed by methods on the embedded type.

Can proper Result/Option types be created for Go now?

Neat, stealing this.

[delayed]

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.

The Go official web site doesn't even use the Go fonts: https://go.dev/blog/go-fonts

I wonder if the Go fonts has been created just to get a trademark on the "Go" word...

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 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 just have a tampermonkey profile for go.dev to fix that for me.

This will shorten many test files!

This is quite a QoL issue, but is it big? Nothing changes from functional point of view.

Re unions:

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.

Having worked a couple of greenfield go shops post generics, it’s still quite rare to find them in first party code. They’re just not that useful outside of library APIs. Proper algebraic data types would be a huge game changer.

Do it. It is just a beautiful language to write and much simpler to pickup than many others. I am a fan boy of course but I love Go.

Tagged unions can be implemented in user code, you dont actually need language support to use them.

https://github.com/splizard/tagged

I still believe that SIMD support is one of the most underrated new features in Go.

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.

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.

[1]: https://github.com/tuzz/pangram-machine

[2]: https://github.com/nkanaev/pangram-machine-go

“Do a breakthrough and make this SIMD fastest”

Keeping priorities right!

I’ve been able to run golangci-lint locally just fine.

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.

[1] https://github.com/golangci/golangci-lint/issues/6643

Broken how? Please report an issue. The latest gopls should support generic methods.

Thank you for the headsup!

I don’t think launching Go today would have been better than 15 years ago.

Standard ML is a perfect programming language from the 90s. It unfortunately does not have a great eco system of packages.

Obligatory XKCD reference:

https://xkcd.com/927/

I know this is an extremely unwelcome comment but I just have to ask… have you considered rust? Especially for a DB.

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.

> Generic methods are a huge win for the language. I've been waiting on these kinds of improvements to the type system ...

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...

I think the fact that package names are URLs is simultaneously genuis and horrifying.

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.

Why would you say something so controversial yet so brave?

Not that I like go at all but because of it my C++ is starting to look like it as I am returning tuples of [result, error].

I try to avoid exceptions, is there any better ways? (Variant looks a bit more complicated but could be a totally OK alternative)

its simple and it works

Personally I feel go has many issues and is ugly as hell but the error handling is really the least of my worries.

Python is already the language everyone needs.

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.

What exactly do you mean by "goroutine termination"?

The release cycle is semi-annually.

I can imagine using it for simple web stuff. E.g. its perfect for something like Forgejo. But yeah... Seems like the world has moved on mostly.

They landed half a decade ago...

There are some details here about the history of how generics finally came to Go: https://golang.design/under-the-hood/en/part2lang/ch08generi...

The tl;dr boils down to a combination of valuing both compilation speed and execution speed.

> 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.

[0] https://go.dev/talks/2015/simplicity-is-complicated.slide#5

I'm pretty sure there is a silent majority of Go users who don't want/need/know about generics.

A problem was so many others were screaming about the lack of generics, as though there were not other language options that provided them.

Go genetics are still incredibly simple compared to languages with a rich type system.

because functional languages already have those features?