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

81–90 of 164 posts

Re: Go 1.22

#81

Post by catherinecodes »

emmanueloga_ wrote: post #3

For those using Go for production, do you get to switch to the latest versions quickly, or do you get stuck in older releases? In the open a lot of projects seem to avoid newish features. I like to use `any` (from 1.18 ~ 2 years ago) where before we had to use `interface{}`, even if I'm not using generics (although I've been told the latter is more "idiomatic" :-/).

At work, we upgrade when there's a compelling reason (structured logging in 1.21 came close; we haven't finished migrating from our old logger yet). Before deploying that version, we typically bump versions in all our Go repos and run the tests in those repos. Having the same version across apps gives some people on our team a bit of comfort (with Go, it's not as important as some other runtimes).

Re: Go 1.22

#82

Post by usrbinbash »

On the risk of sounding like a massiv fanboy (which I, unashamedly, am):

    - Range over Integer
    - Direct support for methods and wildcards in the path directly in `net/http`
    - More free optimization
    - Improved tooling
Sorry again for the fanboism, but Go really is the gift that just keeps giving :D

Re: Go 1.22

#83

Post by kromem »

emmanueloga_ wrote: post #3

For those using Go for production, do you get to switch to the latest versions quickly, or do you get stuck in older releases? In the open a lot of projects seem to avoid newish features. I like to use `any` (from 1.18 ~ 2 years ago) where before we had to use `interface{}`, even if I'm not using generics (although I've been told the latter is more "idiomatic" :-/).

Our CI builds and tests using the 'latest' container for Go, and we have a fairly robust test suite so it essentially auto-updates as things go and breaks the pipeline if anything doesn't work, at which time we either decide to pin the latest working version while we update or hold off on the update to fix breaking changes.

Very rarely, like once every few years, there's some subtle edge case bug that shows up with a third party package and the new version, but honestly we'd never catch that if we were manually upgrading anyways, as by definition these bugs avoided our test suite.

Re: Go 1.22

#84

Post by konart »

KingOfCoders wrote: post #37

I love how easy upgrading Go has become. Change 1.21.6 to 1.22.0 in your go.mod, done.

What does this have to do with upgrading? Your go.mod just specifies the minimum version you need to build the code.

If you do not use new things available in in 1.22 your go.mod may have 1.21 (or even 1.13 if you are not using generics and can't be bothered with a few deprecated things. Like ioutil.ReadAll() which was deprecated since. 1.16)

Re: Go 1.22

#85

Post by puika »

hambos22 wrote: post #64
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…

> 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-...

Re: Go 1.22

#86

Post by konart »

adtac wrote: post #21
tptacek wrote: post #13

Earlier quoted context omitted.

for i := 0; i

I must be getting old because I almost wish they didn't add this as it's slightly ambiguous whether it's ranging from [0, 10) or [1, 10] and anything ambiguous is probably going to haunt me at 3am some day

It iterates 10 times staring with 0, seems pretty clear that the result is [0,10).

Re: Go 1.22

#87

Post by __loam »

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…

I love go. It's just so simple.

Re: Go 1.22

#88

Post by jadayesnaamsi »

bheadmaster wrote: post #65
avtolik wrote: post #63

Earlier quoted context omitted.

Can you give some examples how are you using go:embed and go:generate?

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...

Re: Go 1.22

#89

Post by simiones »

KingOfCoders wrote: post #38
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…

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, complicate the language - but make certain programs simpler.

As a general rule, the more features a language has, the shorter program that implements a particular algorithm can be, but the harder it is to learn, and the bigger the chance that it will be misunderstood. There are exceptions where certain features make languages more verbose (e.g. access modifiers), but typically only in minor ways.

Re: Go 1.22

#90

Post by mhd »

maximus-decimus wrote: post #9
shakow wrote: post #4

> "For" loops may now range over integers The future is now, old man!

While the phrasing is funny, it's really more "we now have a direct equivalent to 10.times in ruby"

Algol 68 had a loop where pretty much any part was optional, so both "TO 10" and "FOR i TO 10" (if you needed a loop variable) were possible.

(Back when Go came out, there were some Algol 68 comparisons, IIRC)

Post reply on HN