Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go 1.22

go.dev

Post reply on HN
Print view View original

91–100 of 164 posts

Re: Go 1.22

#91

Post by rat9988 »

bheadmaster wrote: post #68
carstenhag wrote: post #62

Earlier quoted context omitted.

I don't see the point of using semver (or at least telling us about the same guarantees) and then not making use of it. If there were 10 breaking chances we should be at 11.x now, not at 1.x with 20 environment variables.

From a purist perspective, you're right - the contract has been broken, and a major version should've been incremented. However, Go has always been more of a pragmatic than a purist language. For example, they've analyzed tons of code and found that most of them had bugs caused by having `for` loop with a single variable being mutated. So they changed the `for` loop (in a technically backwards incompatible way) in or…

This has nothing to do with pragmatism. Just update the version number. This is the pragmatic way.

Re: Go 1.22

#92

Post by lloeki »

EdiX wrote: post #72
tommiegannert wrote: post #51

> Enhanced routing patterns > This change breaks backwards compatibility in small ways, some obvious—patterns with "{" and "}" behave differently— and some less so—treatment of escaped paths has been improved. The change is controlled by a GODEBUG field named httpmuxgo121. Set httpmuxgo121=1 to restore the old behavior. That's a great enhancement now that the future of Gorilla Mux is shaky. But why doesn't that go ag…

The way they are using to route around the Go 1 compatibility promise is to gate these backwards incompatible changes on the value of the go directive in go.mod. If it says 1.22 or later you get the new library behavior, otherwise you get the old one. We'll see how well this ends up working in practice.

This mimics Perl's "use 5.x", although the latter is scoped per module. Perl's backward compatibility track record validates the soundness of this approach.

Perl can also selectively enable features, in a way not dissimilar to Python's "from _future_ import X", except the latter is about forward compatibility with a future default, whereas Perl is all about backwards compatibility as a sane default.

I guess Go does it at the mod consistent level because it needs a global view of features whereas Perl can dynamically alter itself (including its parser) live.

Re: Go 1.22

#93

Post by doctor_eval »

divan wrote: post #73
doctor_eval wrote: post #59

Earlier quoted context omitted.

I agree, Go’s simplicity is the best thing about it. I think the same thing about ranges, I think I end up typing the same number of characters - but spreading it over three lines makes it feel “longer” than a comprehension like “forEach(f)”. But then I write the range longhand, and it’s no big deal. Speaking of initialisation though, I do wish Go had an idiomatic way to initialise struct fields to specific values. I…

Sure, it's always a tradeoff. Yet my pet peeve is that people rarely talk about the social aspects of the programming language. It's called "language" for a reason. We express our thoughts using this language ("I intend this code to do such and such"), and we expect other people to be able to understand what we intended, and we want to make sure that they understand exactly as we want them to. I judge languages on th…

I don't know Dart at all, but I used Java from version 1.0, and watched as it morphed and morphed again - from for-loops, to collections with iterators, then "upwards" to list and map comprehensions, closures, function pointers. My younger colleagues were writing code I could barely understand; having left that world several years ago, I still find idiomatic modern Java difficult to mentally map to intent, as you put it. The feature set is undisciplined.

So I completely agree with you. I think it's unfortunate that some people appear to mistake simplicity of construction with simplicity of thought. Go's ingenious simplicity - its elegance - is a virtue. Unfortunately it also reflects what Dijkstra said: "Why has elegance found so little following? ... Elegance has the disadvantage if that's what it is that hard work is needed to achieve it and a good education to appreciate it".

Re: Go 1.22

#94

Post by [deleted] »

moondev wrote: post #50

Still holding out hope for a "go run" flag to easily run module programs with replacements in go.mod go run k8s.io/kubernetes/cmd/kubectl@v1.28.2

[deleted]

Re: Go 1.22

#95

Post by leonheld »

BillyTheKing wrote: post #34

I've been mostly writing Typescript the past 3 years - and recently started writing code in Go. Initially I was a little apprehensive, lack of array functions, slightly less flexible type-system, etc. But after spending some time writing Go I now had to re-initialise a typescript project for a small-ish team (4-5 devs). The amount of time spent on things such as linting, selecting the correct library for server routi…

Go is beautiful, productive, readable. I love Go. It's my "C with niceties".

Re: Go 1.22

#96

Post by c2xlZXB5Cg1 »

puika wrote: post #85
hambos22 wrote: post #64

Earlier quoted context omitted.

> can't wait for some map/filter/find slice functions though Till that day comes, you could use the "lo" library (inspired from lodash). It's my goto Swiss army knife for golang projects. https://github.com/samber/lo

On the other hand, I advise you NOT to use this kind of library and write simple, fast go code most of the time, with the occasional generics helper. Why the hell would I clutter my code with, for example: https://github.com/samber/lo?tab=readme-ov-file#fromentries-...

Klingonization of go code. I don't like it.

Re: Go 1.22

#97

Post by scns »

nalgeon wrote: post #2

If you find the official release notes a bit dry, I've made an interactive version: https://antonz.org/go-1-22

The Compact and Replace examples leave me puzzled, are they correct?

Re: Go 1.22

#98

Post by KingOfCoders »

simiones wrote: post #89
KingOfCoders wrote: post #38

Earlier quoted context omitted.

In my CTO newsletter I recently wrote about TS vs Go releases, with Go 1.22 as an example. TS gets more and more complicated with each release, catering to the power users. Go adds things that makes it simpler to use, like the (missing) range over integers. It's like game sequels, they add more and more canon and game mechanics, then game sequels (or comics) need to reset to make them more accessible to newcomers aga…

All languages that keep evolving get more complex over time. The changes are always intended to make programs written in the language simpler. Go moves at a pretty slow pace, adding only minor new features (and thus minor complications) in most releases. Even in 1.22, they are previewing a new feature, range-over-functions, which seem to be basically C#/Python's iterator functions - a feature which will, of course, c…

"range-over-functions"

Yes, something people coming to Go would have assumed worked before looking at all range cases, but didn't.

Re: Go 1.22

#99

Post by frankjr »

norman784 wrote: post #61
pjmlp wrote: post #48

Earlier quoted context omitted.

The thing with Typescript is that it is only a fancy JavaScript linter, so the only way to justify newer releases is to keep adding up the type system, there is nothing else when language features that aren't type system related are supposed to come from JavaScript evolution. So they either say they are done, or keep adding type theory stuff until it implodes, I fear. Actually I am looking forward to type annotations…

Do you know if the Javascript type annotations is progressing? I didn't hear anything after the initial proposal.

They held a meeting a few months ago so it's alive but probably still years away.

https://github.com/tc39/proposal-type-annotations/issues/184

Re: Go 1.22

#100

Post by heywire »

jadayesnaamsi wrote: post #88
bheadmaster wrote: post #65

Earlier quoted context omitted.

One example that comes to mind is building a single-binary full-stack application. You can use whatever frontend framework you want, and just embed the html/css/js/asset files inside the binary with go:embed. In case of dynamic set of files, you can also write a Go utility to generate the embeddings with go:generate. In addition to the ease of distribution (no more assets/ directory - just a single binary executable!…

A good example of a Go project using embed to pack its html/css/js assets in a single binary is PocketBase: https://github.com/pocketbase/pocketbase/blob/master/ui/embe...

Last I checked, AdGuard Home also did this.

https://github.com/AdguardTeam/AdGuardHome

Post reply on HN