I didn't know what it is and had to look it up. Looks like a new GC.
What I want next is just an AI summary of the comments with vibe analysis ("Is this worth reading?).
I don’t know if you’d count that as directly referring to it by name but it’s there.
The new garbage collector may be enabled by setting [blurred] at build time
to me, where exact flag value is automatically ignored, because I don't care what's in there. I don't pay attention to such irrelevant details
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.
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.
A case in point is that arrays and maps (and the 'make' function etc) were always generic, but as a user until fairly recently you couldn't define your own generic data structures and algorithms.
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.
So GI indeed discourages abstractions.
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.
It's madness.
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 ;)
Are you using copilot?
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++.
and ...
different strokes for different folks.
qed.
hey, chatgpt, quick, what's the shrug emoji? ah disremember.
You still get performance improvements even if you don’t switch over to the new import!
I imagine you can _make_ a project compile with some amount of effort (thinking maybe a week at most) but they wouldn't be exactly "unzip the old archive and execute ./build.bat".
Before it was a common procedure to have central package management, we used to store libraries (jars and dlls), on source control directly in some libs folder.
Afterwards, even with central package management, enterprise software when done right, is not calling the Internet in every build, rahter there are internal repositories that are curated by legal and IT, and only those packages are allowed to be used in projects.
So the tooling is naturally around after 20+ years, no one is doing YOLO project management when playing with customer's money.
As for the "...latest version of the SDKs..", that is moving the goal posts, there is no mention of it on,
> 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.
> As for the "...latest version of the SDKs..", that is moving the goal posts, there is no mention of it on [...]
I thought it was implied since tooling & library breakages over the years happen and sometimes you can't just get the old SDK to run on the latest Windows / macOS. If the languages and Ant/Maven are backwards compatible to that extent, that's actually pretty good!
I had to deal with moving a .NET Framework 4.7 project to .NET Standard 2.0 and it wasn't effortless (although upgrading to each new .NET release after that has been pretty simple so far). We took a couple of weeks even though we had minimal dependencies since we're careful about that stuff.
For example, I worked on a project that just stopped being able to be built with Maven one day, with no changes to the JVM version, any of the dependencies, or the Maven version itself. After a while I gave up trying to figure it out, because the same project was able to be built with Gradle!
Older Scala projects were a pain in the ass to build because the Typesafe repositories stopped accepting plain HTTP connections, requiring obscure configuration changes to sbt. I've never had to deal with things like that in the world of Go.
Of note, I've found this to be very important with AI generated code, where it's easy to grok and refactor AI code.
Testify in particular is widely used in tests yet pulls in an entire YAML parser.
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...
> 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.
It's ironic that the information technology and software engineering industry is so much "json parsing and repacking" one.
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.
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.
Because there is no standard or convention, everybody brings their own "nullable" wrappers between JSON, SQL, and whatnot, that are all half-baked and incompatible.
Look at rust/serde to see what it could have been.
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.
In the case of encoding/json/v2, enabling GOEXPERIMENT=jsonv2 has two major effects:
1. It flips encoding/json (the original, not /v2) to use the new implementation. This is supposed to be a fully backwards-compatible change, modulo some changes to the text of some errors. We're very interested to hear of any cases of existing programs breaking when the experiment is turned on, because (aside from the aforementioned error text, which you shouldn't be depending on) it likely indicates a bug that needs fixing. This is the "new code, please test" half of the change.
2. It enables the new API (encoding/json/v2, encoding/json/jsontext, some new options in encoding/json). This is the "unstable API, might change in response to feedback" half of the change.
[1] https://github.com/golang/go/issues/27179#issuecomment-22899...
[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)
It's a "minimum" version, not a dependency lock!
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
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).
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.
bitbasher•5mo ago
cryptos•5mo ago
bitbasher•5mo ago
So.. was the software released? Schrodinger's release.