-
Go 1.24 Release Notes 3 go.dev
Go 1.24 is released go.dev via
j3s
28 days ago
Go 1.24's `omitzero` is another one of the best additions to the ecosystem in years jvt.me via
telemachus
28 days ago
I think the most important feature for me will be tracking tool dependencies with the
gocommand directly. No more problems caused due to different tooling versions when collaborating with other people :)I was lucky that most tools I am using for my projects can be used as libraries and can be used with my own little command line executable, which then can be used in a versioned manner. Here is an example where I’m using
//go generatewhich wraps an internal command, which usesesbuildfor building JavaScript and CSS assets.One possible downside is if the tool dependencies clash with the dependencies of your package.
I’ve never had this problem, but you can use a separate mod file for tools if you’re worried about that.
Although I wrote a post, being very excited about
go tool, this is still an unfortunate side effect of the pattern. Using a separatego.modfor them works, but has it’s own tradeoffs 🙃That’s a possibility but you can always go back to what people were doing before with a
toolspackage or doinggo install @versionon its own.I haven’t run into an issue with the common dependency graph yet. The unfortunate thing about it is not being able to discern quickly your own dependencies from the tools’ in
go.mod.In fact I seem to have problems now with different tools having conflicting dependencies
On one side I am always impressed by the improvements that each release brings.
On the other side I feel that some of the energy spent to add new features should be better spent by polishing existing features (thinking of https://github.com/golang/go/issues/60940 which is “accepted”, but stuck for months…)
I agree. Honestly I think there seems to be a shift in focus of the paid development. Go n used to be developed more as a general language focused on certain goals, reflected in design decisiont and language changes.
However that appears to have basically replaced with *Go is a language by and die Google “. This isn’t bad in and if itself and probably not all that surprising.
However for people whose ideals aligned with the initial design, goals and essentially the people around it (the plan 9 fols, etc.) it feels a bit like a slap in the face.
This ranges from “don’t expect more big language changes other than generics” (which btw was mentioned to probably come in there faq since before 1.0), as well as trying to get people away from thinking about the garbage collector, and trying to make it hard to impossible to really affect it to more and more exported runtime methods regarding such topics. Compabiloty has also shifted a bit towards “let’s find hacks and rationales so we technically keep it” which to be fair is a whole lot better than what you find elsewhere.
Please don’t misunderstand me. I’m not angry at these changes per se, but for people who trusted claims and promises made it’s still not a good picture. If people wanted a different language of course they’d have chosen it. It’s not like there’s a shortage of them. I remember how basically the reason for creating Go was not liking C++ (and Java) and regardless of one thinks about them it seems obvious that pushing C++ and Java people (and others) into the language makes Go go into that direction.
This isn’t meant to put hate on Go and certainly not people and work, time and effort. I think they are great. This is meant as an observation of shifts in priorities that might also explain why that issue standing is still there. The issue mentioned is from a claim made in a proposal process. It was claimed that this would be covered, which one has to assume is part of the reason why it has been accepted in the first place and while the majority of the proposal have been implemented this part wasn’t.
Isn’t that easily achievable from user code? Why do you think this needs to be in the standard library?
(If you’re looking for the “reverse” module, I created a caching
http.RoundTripperthat can make use of the caching headers and lower the impact of multiple requests on remote servers. Feedback always welcome on it.)That’s beside the point. My statement was on how it was put into a proposal for acceptance, but put into a separate, still unresolved issue during the implementation, which is considered complete.
And on the why I’d argue it’s to align with the already existing fileserver code which does take care of such things. Also because this is somewhat tied to embedding so such things would make sense to be in code, just like the files are rather than at runtime.
But again I’m not really arguing about the issue here but about the fact that reaching consensus by claiming features and then not implementing what is decided on kind of makes the consensus process/getting acceptance part kind of pointless.
Alas, in the last few years, I began to receive ever increasing push back on architecture; as if all of a sudden the community valued clean, (big 4) design patterns etc. It’s been frustrating to encounter. Unwilling to defend the community’s old consensus and relitigate old debates, it slowly pushes me away from Go. (And in spite of my love for DSLs and more exotic production systems, I actually don’t want new e.g. functional features in Go.)