I’m so happy Russ still contributes even though he isn’t lead anymore. I always enjoy reading his blog posts
dvt 5 hours ago [-]
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.
freakynit 9 minutes ago [-]
As I've always said: every non-functional programming language, as it matures, it's adoption rises in enterprise, eventually starts to become more and more like Java in terms of it's syntax and feature-set.
teabee89 7 hours ago [-]
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"?
hoppp 3 hours ago [-]
Yeah the deadline to move everything is drawing near I am actually not impressed by how fast things are going but all progress is good.
Valodim 6 hours ago [-]
Yes, and at that time the answer was "move over where?" now it's 2026 and x-wing is a draft still
halJordan 4 hours ago [-]
Ah. This is a bold faced lie. There were plenty of options in 2016. Nist released final candidates in 2024 and published the candidates this year.
ssh (as noted in tfa) has had pq defaults since 2022.
blandflakes 4 hours ago [-]
In case you wanted to know, the expression is actually "bald-faced lie", i.e. unmasked, shameless.
stryan 2 hours ago [-]
"bold-faced lie" and "bald-faced lie" are both valid expressions. The original expression is "bare-faced lie" but they're all pretty similar to each other.
blandflakes 2 hours ago [-]
bold-faced lie is just the usual English drift that was actually questioned as incorrect when it first surfaced. If a lie is bold, you don't have to suggest that the user's face is bold when doing it. You can in thirty seconds of google searching find numerous sources explaining that "bold-faced" is a malapropism.
stryan 1 hours ago [-]
It's the usual English drift perhaps, but "bold faced lie" has been used since the 17th century, which is also apparent from "thirty seconds of Google searching". Three hundred years is enough usage for me to count it as correct.
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.
Joel_Mckay 3 hours ago [-]
They are also lying, it is an Italics-Faced lie... thank you, I will see myself out. =3
taybin 4 hours ago [-]
Calling it a lie is pretty heavy.
calvinmorrison 1 hours ago [-]
its ok we are still rawdogging ftp every day in the business world. The fax machines of the future truly
eterm 5 hours ago [-]
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.
stackskipton 4 hours ago [-]
US Government is starting to push hard so code first needs to support it.
amelius 4 hours ago [-]
Ok, but when is it coming to our web browsers and email clients?
adastra22 36 minutes ago [-]
It’s been on by default for 2 years in Chrome.
Retr0id 4 hours ago [-]
I don't know about mail clients, but it's in most web browsers already.
guessmyname 6 hours ago [-]
Brace for a wave of drive-by pull-requests swapping google/uuid [1] out for the now-standard uuid package [2].
Kubernetes project will be the first one [3] I guarantee it.
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.
agwa 5 hours ago [-]
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.
Doesn’t the type name uuid.UUID violate go’s style guide for type naming? I seem to recall a fairly specific prohibition on stutter-types.
kbolino 3 hours ago [-]
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.
coder543 3 hours ago [-]
No. What else could it reasonably be named? Hard to imagine.
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`.
whateveracct 4 minutes ago [-]
> No. What else could it reasonably be named? Hard to imagine.
Ocaml often just has it be T
so uuid.T
deepsun 6 hours ago [-]
Or just a number (128-bit).
reactordev 6 hours ago [-]
Oooof… well played go team, well played.
dabber21 6 hours ago [-]
will 'go fix' take care of this?
Xeoncross 7 hours 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
Thanks for the link, looks like a very pleasant framework to use! I was interested to see "Mid-fasthttp" on the slower end in the benchmarks at the bottom, do you know why that is?
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.
Xeoncross 16 minutes ago [-]
Due to the fact that fasthttp is not net/http compatible it is due to the conversion being required from a https://pkg.go.dev/net/http#Handler. It was included for information purposes as I though someone would be curious.
tugback 8 minutes ago [-]
Generic methods finally landing is huge. Having to write a separate typed method for every integer type was one of the most annoying boilerplate patterns in Go.
xavdid 5 hours ago [-]
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.
treyd 5 hours ago [-]
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.
tester457 4 hours ago [-]
> 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.
> 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
whateveracct 3 minutes ago [-]
he is insufferable. it's his thing lol.
IshKebab 4 hours ago [-]
That must be why traffic lights and electrical wires and transit maps are all black and white...
abtinf 4 hours ago [-]
That’s an interesting point.
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.
IshKebab 3 hours ago [-]
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.
It's completely absurd to say that colours are childish because they can help children.
wredcoll 34 minutes ago [-]
I want to downvote this for being one of the stupidest things I've read this week but you're just quoting it so I guess I'll just seethe silently.
jeremyjh 3 hours ago [-]
What is childish is holding up one guy's editor preferences as a religious sacrament when 99.9% of your readers have different preferences.
dotwaffle 51 minutes ago [-]
Well, there's kind of a precedent at least...
> Gofmt's style is no one's favorite, yet gofmt is everyone's favorite.
xavdid 4 hours ago [-]
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?
jeremyjh 3 hours ago [-]
Oceania had always been at war with Eastasia.
mparnisari 4 hours ago [-]
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.
pigeonhole123 4 hours ago [-]
He also doesn't capitalize his sentences.
zanderwohl 4 hours ago [-]
Welcome to Go as a project.
tayo42 4 hours ago [-]
Child hood trauma led to if err != nil and now the rest of us get to share that trauma? Makes slight sense I guess.
3 hours ago [-]
parsd 4 hours ago [-]
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.
ClikeX 4 hours ago [-]
I just have a tampermonkey profile for go.dev to fix that for me.
olingern 7 hours ago [-]
> 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
andreimackenzie 4 hours ago [-]
This will shorten many test files!
konart 6 hours ago [-]
This is quite a QoL issue, but is it big? Nothing changes from functional point of view.
onionisafruit 4 hours ago [-]
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.
piinbinary 7 hours ago [-]
This makes me want to find a side project for an excuse to give Go another try (I last used it professionally pre-generics).
I do still wish it had discriminated unions (algebraic data types) and some better error handling ergonomics.
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.
Splizard 6 hours ago [-]
Tagged unions can be implemented in user code, you dont actually need language support to use them.
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.
Splizard 6 hours ago [-]
You can also add support for exhaustive switches on tags.
shhsshs 6 hours ago [-]
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.
kccqzy 5 hours ago [-]
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.
kccqzy 5 hours ago [-]
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.
codegeek 6 hours ago [-]
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.
osigurdson 6 hours ago [-]
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.
fragmede 5 hours ago [-]
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.
tyho 6 hours ago [-]
The SIMD stuff is incredible. I have been having lots of fun with it. You can use LLMs as a scalar to SIMD transpiler, it works amazingly well.
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.
nkanaev 5 hours ago [-]
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'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
sethops1 7 hours ago [-]
FYI golangci-lint and gopls are both broken if you try using generic methods.
adonovan 3 hours ago [-]
Broken how? Please report an issue. The latest gopls should support generic methods.
sethops1 3 hours ago [-]
Ah my bad gopls is fine; I forgot to run
go install golang.org/x/tools/gopls@latest
after upgrading Go itself.
atsjie 7 hours ago [-]
Thank you for the headsup!
tschellenbach 7 hours ago [-]
Every release CPU load becomes a bit lower. Love it :)
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.
fmbb 7 hours ago [-]
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.
qaq 6 hours ago [-]
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.
Generic methods are a huge win for the language. I've been waiting on these kinds of improvements to the type system before resuming work on my database toolkit.
drivebyhooting 1 hours ago [-]
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.
AdieuToLogic 36 minutes ago [-]
> 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]
One of the language features C++ provides, "templates", was explicitly rejected by the language authors as being antithetical to Go philosophy[1]. Thompson put it bluntly:
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]
Rejecting templates does not mean rejecting generics.
Fervicus 2 hours ago [-]
I really want to like Go, but I can't stand looking at Go code. The error handling is such a turn off.
vrosas 2 hours ago [-]
Why would you say something so controversial yet so brave?
kajika91 2 hours ago [-]
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)
ameliaquining 1 hours ago [-]
C++23 introduces std::expected, which is a simpler alternative to std::variant designed specifically for the result-or-error use case. You still don't get pattern matching, but Go-style tuples don't give you that either.
whalesalad 2 hours ago [-]
Personally I feel go has many issues and is ugly as hell but the error handling is really the least of my worries.
tschellenbach 7 hours ago [-]
New JSON is amazing, and SIMD will be big for json, audio/video etc.
ejboy 4 hours ago [-]
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.
jeanbza 7 hours ago [-]
I have been waiting for generic methods and can't wait to use them!
The `go fix` modernisers are also great, have already run them in several repos.
tonymet 7 hours ago [-]
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
radicalriddler 6 hours ago [-]
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.
tonymet 5 hours ago [-]
true that, but we get a couple of these a year it seems, so their overall velocity is excellent, and without breaking anything. a dream language.
BeriV2 3 hours ago [-]
does it have goroutine termination, i recently found out you need a runtime patch for it
ameliaquining 1 hours ago [-]
What exactly do you mean by "goroutine termination"?
Hasz 7 hours ago [-]
I have recently been spending time learning go, really really liking the language, awesome standard lib, excellent tooling and great experience.
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.
kar1181 5 hours ago [-]
Go - the language no one likes, but frankly everyone needs.
amelius 4 hours ago [-]
Python is already the language everyone needs.
dude250711 4 hours ago [-]
Quarterly reminder that Go still exists.
IshKebab 4 hours ago [-]
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.
aliasxneo 4 hours ago [-]
A large portion of the DevOps/Platform Engineering world uses Go.
DisceetPlug 1 hours ago [-]
[dead]
DisceetPlug 1 hours ago [-]
[dead]
CurbStomper 6 hours ago [-]
[dead]
fatty_patty89 7 hours ago [-]
[flagged]
simlevesque 7 hours ago [-]
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.
fatty_patty89 7 hours ago [-]
no, it wasnt 40 upvotes in 40 minutes, it was at 8 upvotes after 34 minutes posted
applfanboysbgon 7 hours ago [-]
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?
SpaceManNabs 6 hours ago [-]
Wait generics? What changed? Why is golang accepting of generics now?
The tl;dr boils down to a combination of valuing both compilation speed and execution speed.
pregnenolone 6 hours ago [-]
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.
pansa2 3 hours ago [-]
> 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.
I would argue that languages like Java (C#, Kotlin, etc.) strike a very good compromise between modeling ability and comprehension, which is why they are popular and people gravitate toward them.
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.
kermatt 5 hours ago [-]
A problem was so many others were screaming about the lack of generics, as though there were not other language options that provided them.
bikelang 2 hours ago [-]
Go genetics are still incredibly simple compared to languages with a rich type system.
https://research.swtch.com/fp
https://github.com/golang/go/blob/go1.27.0/src/internal/strc...
[1] https://words.filippo.io/crqc-timeline/
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.
It seems there's a big push happening behind the scenes.
Kubernetes project will be the first one [3] I guarantee it.
[1] https://pkg.go.dev/github.com/google/uuid
[2] https://go.dev/pkg/uuid
[3] https://github.com/kubernetes/kubernetes/blob/2220c3853a2402...
[4] https://github.com/google/uuid/issues/221
[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
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...
> 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
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.
> Gofmt's style is no one's favorite, yet gofmt is everyone's favorite.
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.
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
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.
https://github.com/splizard/tagged
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.
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.
[1]: https://github.com/tuzz/pangram-machine
[2]: https://github.com/nkanaev/pangram-machine-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.
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/
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:
One of the language features C++ provides, "templates", was explicitly rejected by the language authors as being antithetical to Go philosophy[1]. Thompson put it bluntly: And now, years later, generics are "a huge win."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.
I try to avoid exceptions, is there any better ways? (Variant looks a bit more complicated but could be a totally OK alternative)
The `go fix` modernisers are also great, have already run them in several repos.
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
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.
The tl;dr boils down to a combination of valuing both compilation speed and execution speed.
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.