New `encoding/json/v2` package (hidden behind `GOEXPERIMENT=jsonv2` flag)! It brings perf improvements and finally allows devs to implement custom marshalers for external types:
> Alternatively, users can implement functions that match MarshalFunc, MarshalToFunc, UnmarshalFunc, or UnmarshalFromFunc to specify the JSON representation for arbitrary types. This provides callers of JSON functionality with control over how any arbitrary type is serialized as JSON.
Awesome stuff.
tete · 9h ago
> We expect the design of encoding/json/v2 to continue to evolve. We encourage developers to try out the new API and provide feedback on the proposal issue.
Does anyone have more knowledge on what this refers to? I thought v2 being in as an experiment means they are happy with it, but "we expect it to evolve" sounds like "we know it's not good yet". Maybe I am understanding it the wrong way though. Just because other experiments were more like "this is new code, please test" and not "this will change".
LambdaComplex · 9h ago
Just because the Go maintainers think it's in an okay state doesn't mean the wider community won't have good ideas on how to improve it.
arccy · 7h ago
Other experiments did change though: arena got dropped, synctest Run -> Test
MadcapJake · 4h ago
Where is it mentioned that the arena experiment has been dropped?
typical182 · 2h ago
The arena experiment was essentially placed on indefinite hold:
> The proposal to add arenas to the standard library is on indefinite hold due to concerns about API pollution.
I think the parent comment was using arenas as an example that GOEXPERIMENTs don't always move forward (like arenas), or can change while still GOEXPERIMENTs in a way that would normally not be allowed due to backward compatibility (like synctest).
The arena GOEXPERIMENT has not yet been dropped as of Go 1.25, but as I understand it, the plan is to remove arenas from the runtime when 'regions' are introduced, which have similar performance benefits but a much lower API impact:
As discussed there, seeing how people actually used the arena GOEXPERIMENT influenced the 'regions' design.
pbnjay · 11h ago
Yes I was very excited to see the new json encoding changes land, can’t wait to try them out! The new omitempty and map key marshalling in particular will help clean up some of my ugly code.
zx8080 · 14h ago
Wow, top comment about json. (Edit: not top 1 anymore, but still the point).
It's ironic that the information technology and software engineering industry is so much "json parsing and repacking" one.
trenchpilgrim · 13h ago
To be fair, the existing json package in Go's standard library is somewhat infamous because it is non-streaming, so it has performance issues with large documents. one of the goals of json/v2 was to remedy this.
the_gipsy · 5h ago
The irony is that go has taken the "web backend" niche, yet it sucks notoriously at JSON.
It's a complete joke TBH, and no amount of patching can ever fix zero-values, the root of all evil in go.
majewsky · 4h ago
Zero values can, for the most part, be caught with a custom UnmarshalJSON implementation (and the new UnmarshalJSONFrom interface ought to remove most of the performance penalty associated with that). The one problem is what to do when the field is missing entirely, because then UnmarshalJSON(From) will never be invoked.
I have been thinking about suggesting a new struct field tag for JSON parsing: `json:',required'` that throws an error when the struct field is absent in the respective JSON object. The artifice is mostly in how to phrase that proposal in a way that makes it more likely for the Go devs to accept it. If I just come in like "I hate zero values", that may have some truth to it, but it's not going to be conducive to the discussion going the way I want.
pjmlp · 4h ago
On my little corner of the universe, "web backend" means Java, .NET or nodejs, the set of languages that can run on top of any of those runtimes.
the_gipsy · 3h ago
You're right, go has not "taken it over". I meant more that it has moved into that niche since its conception, while being really bad at dealing with JSON correctly.
gwd · 7h ago
I mean, I get what you're saying, but the fact is
1. Golang is used in web and api servers
2. Json is the lingua franca of data for the web, so golang does a lot of json processing
2. The golang stdlib json packages haven't had much attention in the last decade
I was just thinking recently that my biggest pain point with the upstream JSON packages was the fact that you can't add easily add custom marshal / unmarshal code to objects in a package you don't control. I'm actually really excited about this change.
The other reason this is at the top of the list, of course, is that there are no major interesting language features being added. This is a combination of the fact that golang is a pretty mature language, and the slowness of the team to adding new language features; both of which I appreciate.
disintegrator · 17h ago
I just love how this language marches forward. I have so many colleagues that hate many aspects of it but I sit here combining Go, Goa and SQLc writing mountains of code and having a fairly good compiler behind me. I understand what I’m missing out on by not using stricter languages and so often it’s a totally fine trade off.
gottorf · 14h ago
Go is the only language where I've come back to a nontrivial source code after 10 years of letting it sit and have had zero problems building and running. That alone, for me, more than makes up for its idiosyncrasies.
Grokify · 2h ago
This. Maintainability and refactorability are some of the major Go superpowers for me which enables getting into any code base and updating it. These are supported by features like static typing, fast compile times, etc.
Of note, I've found this to be very important with AI generated code, where it's easy to grok and refactor AI code.
pjmlp · 4h ago
I have worked in C++, Java and .NET codebases older than many HNer and still keep going strong.
doublepg23 · 11h ago
As a more sysadmin/ops focused guy it really is the killer feature.
Static binaries and a more Java-esque resource profile than say Python are the cherries on top.
zaphirplane · 7h ago
In all fairness 10 years ago the deps would have been vendored in. Which side steps a whole set of problems if security, remote api version compat and features are not a major need
tete · 10h ago
Yes, but with all the v2 in stdlib popping up we will get a lot of outdated code and a lot of "I need to know v1 and v2, because I will come across both".
Chiron1991 · 8h ago
But "outdated code" isn't inherently bad, is it? v1 code is still supported by the stdlib and it still does its job, at least until Go 2.x drops.
ayuhito · 5h ago
In fact, v1 code usually uses v2 code under the hood, but with different options to maintain backwards compatibility.
You still get performance improvements even if you don’t switch over to the new import!
Grokify · 5h ago
A good example is io/ioutil. It's useful to migrate to eliminate the deprecation messages, but you don't need to do it right away.
majewsky · 4h ago
Also, most of this can be automated with `go install golang.org/x/tools/gopls/internal/analysis/modernize/cmd/modernize@latest && modernize -fix ./...`
josephg · 11h ago
I’ve had the same experience with old rust packages. But nothing quite so old - at least not yet!
fuzztester · 11h ago
i have read that same point said multiple times on hn about both common lisp and perl, including in a recent thread about perl.
keyle · 11h ago
The difference is that going back to Go code you've written a few years ago, isn't nearly as bad as going back to Perl code you've written a few years ago!
fredrikholm · 10h ago
And having written a lot of Common Lisp, Go code is extraordinarily straight forward in a sense where every developer writes in almost the exact same style.
This is not true for Common Lisp (even though it's not as bad as people make it out to be).
I feel the exact same way with C versus C++, even if I was the person to write the C++.
thiht · 7h ago
If someone said that about Perl, they're lying.
danudey · 16h ago
I've gotten used to golang, though it's still not my favourite language to program in by any stretch. One issue I've been having, though, is the documentation.
Documentation for third-party modules in Python is fantastic, almost universally so. In nearly every case of using a third-party library, large or small, there's sufficient documentation to get up and running.
Golang libraries, however, seem to be the opposite. In most cases there's either no documentation whatsoever on how to use things, or, more commonly, there is example code in the readme which is out of date and does not work at all.
The IDE integration with golang is great, and it makes some of this a bit easier, but I also still get a ton of situations where my editor will offer some field or function that looks like what I want (and is what I'm typing to see if it will autocomplete) but once I select it it complains that there's no such field or function. Still haven't figured that out.
So yeah, I dunno. The language is 'great'; it certainly has some extreme strengths and conveniences, like the fact that 'run this function with these arguments in a separate thread' is a language keyword and not some deep dive into subprocess or threading or concurrent.futures; the fact that synchronization functionality is trivially easy to access; Sync.Once feels so extremely obvious for a language where concurrency is king, and so on.
Still, the ecosystem is... a bit of a mess, at the best of times. Good modules are great, all other modules are awful.
marcus_holmes · 11h ago
I think Go de-emphasises the ecosystem a lot.
Generally gophers just use the standard library as much as possible. There isn't the usual set of "must-have" dependencies, and generally speaking when a gopher tries to solve a problem, the first step isn't to search for a 3rd party library that solves it for them.
Obviously this is a broad generalisation and there are plenty of gophers who swear by using one or more libraries, and there are plenty of gophers who do rely on third-paarty dependencies. But this is still noticeably less prevalent than in many other languages, especially the more popular ones in web dev.
As others have said, it also helps that Go code is easy to read and emphasises simplicity. The code is often more readable than the documentation, for sure. Whether you consider this bad documentation is up to you ;)
Grokify · 5h ago
I enjoy the Go ecosystem quite a bit and haven't found many issues with documentation. I love how open source modules are documented on pkg.go.dev, including those from major providers, like AWS, Google, etc. Every library has the same references. When examples are useful, such as with charting modules, I've found that the projects do provide them. On the occasion where the README.md code is out of date, it's been easy for me to check pkg.go.dev and update it myself.
leoqa · 15h ago
I quite frankly will just read the code. Go generally discourages abstractions so any code you jump into is fairly straightforward (compared to a hierarchy of abstract classes, dependency injected implementations, nested pattern matching with destructuring etc etc).
Regarding your IDE issues- I’ve found the new wave of copilot/cursor behavior to be the culprit. Sometimes I just disable it and use the agent if I want it to do something. But it’ll completely fail to suggest an auto complete for a method that absolutely exists.
treyd · 14h ago
> Go generally discourages abstractions so any code you jump into is fairly straightforward
This is a really anti-intellectual take. All of software engineering is about building abstractions. Not having abstractions makes the structure less easy to understand because they're made implicit, and forces developers to repeat themselves and use brittle hacks. It's not a way to build robust or maintainable software.
bjt · 14h ago
Go does have plenty of abstractions.
I think the more charitable interpretation is "Go generally discourages metaprogramming." Which I would agree with, and I think positively distinguishes it from most popular languages.
packetlost · 13h ago
Go discouraging abstracts is sorta just... wrong anyways. Go doesn't discourage building abstractions, it discourages building deep / layered abstractions.
cryptos · 7h ago
That is a key point in my opinion. A typical stack trace of a Spring (Java) application can easily be 1000 to 2000 lines long. That is not so common in Go, as far as I know (I'm not a Go expert ...).
tcfhgj · 7h ago
Building abstractions and adding more layers goes hand in hand, e.g. see OSI layers.
So GI indeed discourages abstractions.
packetlost · 1h ago
Not really, it's more like it encourages "wide" abstraction (lots of shallow abstractions) that get pieced together vs heavily nested abstractions that encapsulate other abstractions. It's a very imperative language.
Mawr · 14h ago
Did you cherry pick that part of the sentence and ignored "(compared to a hierarchy of abstract classes, dependency injected implementations, nested pattern matching with destructuring etc etc)." on purpose or?
treyd · 52m ago
Yeah this is exactly the stuff that you'll have to reinvent yourself on an ad-hoc basis in any sufficiently large project.
Of course, you'll probably retreat and say "Go is better for small projects", but every large project started as a small one, and it's really hard to justify rewriting a project in a new language in a business context.
jen20 · 3h ago
Nor is Spring Boot with hidden implicit behaviour all over the show. Nor are AbstractProxyFactoryBeans, or IOC containers.
Code you can read and understand linearly and end to end is hugely underrated.
osigurdson · 13h ago
>> Go generally discourages...
Really, there is nothing in the language that prevents you from creating crazy AbstractFactoryFactories or doing DI. What really prevents this is the community. In enterprise C# / Java, insanity is essentially mandated.
mayama · 14h ago
Generally I found updated example in one of the test files. Or I could understand how to use library by reading test files in the repo. For me it's the opposite problem, python documentation is too long in some cases and it's not intuitive to find what I want if it's not trivial, and had to use websearch or llm.
cmckn · 14h ago
I wrote a lot of Java in a past life, and the documentation situation is night and day, for sure. I think it's partly a syntax/tooling issue, and partly a cultural thing. Luckily Go's standard library (+ `/x/` modules) lets me avoid third-party dependencies in many cases. The documentation from the Go team is very good in my opinion.
antibios · 13h ago
This is so true and unfortunate because golang has an inbuilt example function that closely follows the test functions. It means that all that really needs to change is how godoc promotes or badges libraries with examples.
djfobbz · 12h ago
Any language that helps me put food on my family table is a good language. For me, that has been the case with both Ruby and Go.
christophilus · 4h ago
I love it because the average Go project has so few dependencies.
jen20 · 3h ago
While I agree, one thing that would really help there is the notion of test dependencies separate from ones that will end up in a production binary.
Testify in particular is widely used in tests yet pulls in an entire YAML parser.
devmor · 17h ago
I did not like it at first but it has grown on me. I still have my gripes, which are mostly things that come from its overall architecture and will never be resolved, but it is pretty enjoyable to use for the limited domain I use it in at work.
dotwaffle · 11h ago
Just watch as most libraries now update their go.mod to say 1.25, despite using no 1.25 features, meaning those who want to continue on 1.24 (which will still have patch releases for six months...) are forced to remain on older versions or jump through lots of hoops.
It's a "minimum" version, not a dependency lock!
bitbasher · 1h ago
This is a common issue with Rust projects as well. At least with Rust you have the idea of "MSRV" (minimum supported rust version). I've never heard it discussed within Go's community.
There's no MSGV. Everyone pins the latest.
This also plagues dependencies. People pin to specific version (ie, 1.23) instead of the major version (at least 1.0 or at least 1.2, etc).
konart · 11h ago
>Just watch as most libraries now update...
Haven't seen anything like this. Most packages actually have 1.13 in their go.mod
Rarely do I see at least 1.19
dotwaffle · 10h ago
Now that I think about it more, when I've seen it happen before, it tends to be on projects that use dependabot / renovate. If any of those updates depend (directly or transitively) on a later version of Go, the go.mod would be bumped accordingly for them.
I have a vague feeling it was related to testcontainers or docker, and at the time that job's Go install was always at least 6 months behind. At least with recent Go, it'll switch to a later version that it downloads via the module proxy, that would have helped a lot back then :S
lordofgibbons · 10h ago
Never seen this happen. Most popular libraries support at least 2 previous versions
Gobd · 18h ago
Yay new version! Not the most exciting (as Go releases tend to be which is good), but hopefully jsonv2 and greentea can get some testing and be standard in 1.26
latchkey · 17h ago
> greentea
I didn't know what it is and had to look it up. Looks like a new GC.
Is reading the posted article just something we don't do anymore?
rs186 · 13h ago
To be fair, I read the article but still don't know what greentea is. The article never directly refers to the new GC by this name. It appears in a command line option value, that's about it.
vips7L · 11h ago
> The new garbage collector may be enabled by setting GOEXPERIMENT=greenteagc at build time
I don’t know if you’d count that as directly referring to it by name but it’s there.
latchkey · 13h ago
Haven't done that in ages. I open both the page and the comments. The first few comments usually dictate if I'm going to bother with the page.
What I want next is just an AI summary of the comments with vibe analysis ("Is this worth reading?).
awesome_dude · 13h ago
If people were intended to read we wouldn't have to yell at them to RTFM!!
abtinf · 12h ago
WaitGroup.Go looks great. Going to be able to delete a lot of code, replacing boilerplate with calls to it.
> LookupMX and Resolver.LookupMX now return DNS names that look like valid IP address, as well as valid domain names. Previously if a name server returned an IP address as a DNS name, LookupMX would discard it, as required by the RFCs. However, name servers in practice do sometimes return IP addresses.
This one is interesting; which servers return an IP address as a record? Why would they want to do this?
Go is one of the last languages I'd think about when considering access to the AST. The first would be Lisp.
tonymet · 36m ago
there are tons of utilities. and the fact that i've written some means it's pretty easy
whartung · 12h ago
JDK, I believe, has first class support for accessing the Java AST.
cryptos · 7h ago
There are some internal compiler APIs (so, not officially supported) and some external tools to do so.
trenchpilgrim · 11h ago
Lisp and Lua both have good AST support.
gsck · 2h ago
Not sure where youve learnt that Lua gives you access to the AST considering Lua doesn't build an AST
trenchpilgrim · 2h ago
I gotta admit I never formally learned Lua in any rigorous way, I just picked up enough to script with it in existing codebases. I'll often write Python scripts that manipulate Lua programs, for example.
tete · 10h ago
> LookupMX and Resolver.LookupMX now return DNS names that look like valid IP address, as well as valid domain names. Previously if a name server returned an IP address as a DNS name, LookupMX would discard it, as required by the RFCs. However, name servers in practice do sometimes return IP addresses.
Ah, intentionally making code not standards compliant.
thiht · 7h ago
Reality compliant > standards compliant.
porridgeraisin · 5h ago
Standards are toilet paper in the general case. Only in the rare cases where reality matches it does it matter.Anyone can write anything on a piece of paper. What code is executing on the DNS server at the end of the day is what matters.
truth_seeker · 7h ago
> TLS servers now prefer the highest supported protocol version, even if it isn’t the client’s most preferred protocol version.
>Both TLS clients and servers are now stricter in following the specifications and in rejecting off-spec behavior. Connections with compliant peers should be unaffected.
This is nice.
nikolayasdf123 · 5h ago
have been looking toward this release for quite some time!
> Alternatively, users can implement functions that match MarshalFunc, MarshalToFunc, UnmarshalFunc, or UnmarshalFromFunc to specify the JSON representation for arbitrary types. This provides callers of JSON functionality with control over how any arbitrary type is serialized as JSON.
Awesome stuff.
Does anyone have more knowledge on what this refers to? I thought v2 being in as an experiment means they are happy with it, but "we expect it to evolve" sounds like "we know it's not good yet". Maybe I am understanding it the wrong way though. Just because other experiments were more like "this is new code, please test" and not "this will change".
> The proposal to add arenas to the standard library is on indefinite hold due to concerns about API pollution.
I think the parent comment was using arenas as an example that GOEXPERIMENTs don't always move forward (like arenas), or can change while still GOEXPERIMENTs in a way that would normally not be allowed due to backward compatibility (like synctest).
The arena GOEXPERIMENT has not yet been dropped as of Go 1.25, but as I understand it, the plan is to remove arenas from the runtime when 'regions' are introduced, which have similar performance benefits but a much lower API impact:
https://github.com/golang/go/discussions/70257
As discussed there, seeing how people actually used the arena GOEXPERIMENT influenced the 'regions' design.
It's ironic that the information technology and software engineering industry is so much "json parsing and repacking" one.
It's a complete joke TBH, and no amount of patching can ever fix zero-values, the root of all evil in go.
I have been thinking about suggesting a new struct field tag for JSON parsing: `json:',required'` that throws an error when the struct field is absent in the respective JSON object. The artifice is mostly in how to phrase that proposal in a way that makes it more likely for the Go devs to accept it. If I just come in like "I hate zero values", that may have some truth to it, but it's not going to be conducive to the discussion going the way I want.
1. Golang is used in web and api servers
2. Json is the lingua franca of data for the web, so golang does a lot of json processing
2. The golang stdlib json packages haven't had much attention in the last decade
I was just thinking recently that my biggest pain point with the upstream JSON packages was the fact that you can't add easily add custom marshal / unmarshal code to objects in a package you don't control. I'm actually really excited about this change.
The other reason this is at the top of the list, of course, is that there are no major interesting language features being added. This is a combination of the fact that golang is a pretty mature language, and the slowness of the team to adding new language features; both of which I appreciate.
Of note, I've found this to be very important with AI generated code, where it's easy to grok and refactor AI code.
You still get performance improvements even if you don’t switch over to the new import!
This is not true for Common Lisp (even though it's not as bad as people make it out to be).
I feel the exact same way with C versus C++, even if I was the person to write the C++.
Documentation for third-party modules in Python is fantastic, almost universally so. In nearly every case of using a third-party library, large or small, there's sufficient documentation to get up and running.
Golang libraries, however, seem to be the opposite. In most cases there's either no documentation whatsoever on how to use things, or, more commonly, there is example code in the readme which is out of date and does not work at all.
The IDE integration with golang is great, and it makes some of this a bit easier, but I also still get a ton of situations where my editor will offer some field or function that looks like what I want (and is what I'm typing to see if it will autocomplete) but once I select it it complains that there's no such field or function. Still haven't figured that out.
So yeah, I dunno. The language is 'great'; it certainly has some extreme strengths and conveniences, like the fact that 'run this function with these arguments in a separate thread' is a language keyword and not some deep dive into subprocess or threading or concurrent.futures; the fact that synchronization functionality is trivially easy to access; Sync.Once feels so extremely obvious for a language where concurrency is king, and so on.
Still, the ecosystem is... a bit of a mess, at the best of times. Good modules are great, all other modules are awful.
Generally gophers just use the standard library as much as possible. There isn't the usual set of "must-have" dependencies, and generally speaking when a gopher tries to solve a problem, the first step isn't to search for a 3rd party library that solves it for them.
Obviously this is a broad generalisation and there are plenty of gophers who swear by using one or more libraries, and there are plenty of gophers who do rely on third-paarty dependencies. But this is still noticeably less prevalent than in many other languages, especially the more popular ones in web dev.
As others have said, it also helps that Go code is easy to read and emphasises simplicity. The code is often more readable than the documentation, for sure. Whether you consider this bad documentation is up to you ;)
Regarding your IDE issues- I’ve found the new wave of copilot/cursor behavior to be the culprit. Sometimes I just disable it and use the agent if I want it to do something. But it’ll completely fail to suggest an auto complete for a method that absolutely exists.
This is a really anti-intellectual take. All of software engineering is about building abstractions. Not having abstractions makes the structure less easy to understand because they're made implicit, and forces developers to repeat themselves and use brittle hacks. It's not a way to build robust or maintainable software.
I think the more charitable interpretation is "Go generally discourages metaprogramming." Which I would agree with, and I think positively distinguishes it from most popular languages.
So GI indeed discourages abstractions.
I would argue it's sorta related to Greenspun's tenth rule: https://en.m.wikipedia.org/wiki/Greenspun%27s_tenth_rule
Of course, you'll probably retreat and say "Go is better for small projects", but every large project started as a small one, and it's really hard to justify rewriting a project in a new language in a business context.
Code you can read and understand linearly and end to end is hugely underrated.
Really, there is nothing in the language that prevents you from creating crazy AbstractFactoryFactories or doing DI. What really prevents this is the community. In enterprise C# / Java, insanity is essentially mandated.
Testify in particular is widely used in tests yet pulls in an entire YAML parser.
It's a "minimum" version, not a dependency lock!
There's no MSGV. Everyone pins the latest.
This also plagues dependencies. People pin to specific version (ie, 1.23) instead of the major version (at least 1.0 or at least 1.2, etc).
Haven't seen anything like this. Most packages actually have 1.13 in their go.mod
Rarely do I see at least 1.19
I have a vague feeling it was related to testcontainers or docker, and at the time that job's Go install was always at least 6 months behind. At least with recent Go, it'll switch to a later version that it downloads via the module proxy, that would have helped a lot back then :S
I didn't know what it is and had to look it up. Looks like a new GC.
https://github.com/golang/go/issues/73581
I don’t know if you’d count that as directly referring to it by name but it’s there.
What I want next is just an AI summary of the comments with vibe analysis ("Is this worth reading?).
This one is interesting; which servers return an IP address as a record? Why would they want to do this?
Looks like the original poster on that thread is making it because Mailgun uses Go, and was running into issues related to this: https://github.com/golang/go/issues/56025#issuecomment-26720...
[1] https://github.com/golang/go/issues/72991
[2] https://www.datadoghq.com/blog/engineering/go-memory-regress...
[3] https://news.ycombinator.com/item?id=44597550 (24 days ago)
So.. was the software released? Schrodinger's release.
https://docs.python.org/3/library/ast.html
Ah, intentionally making code not standards compliant.
>Both TLS clients and servers are now stricter in following the specifications and in rejecting off-spec behavior. Connections with compliant peers should be unaffected.
This is nice.