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.

https://github.com/splizard/tagged

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

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

https://xkcd.com/927/

It seems there's a big push happening behind the scenes.

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

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

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

[2]: https://github.com/nkanaev/pangram-machine-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.

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

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

I don't know why it's still like that but that's the original reasoning.

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 wonder if the Go fonts has been created just to get a trademark on the "Go" word...

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.

A goroutine that has to be killed (no other way to tell it to stop) is a bug.

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

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

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