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

131–140 of 164 posts

Re: Go 1.22

#131

Post by KingOfCoders »

simiones wrote: post #123
KingOfCoders wrote: post #117

Earlier quoted context omitted.

Yes might depend on where you come from. As someone with decades of Java experience - not a fancy language over most of its lifecycle - I was mystified why there is no Iterator support as in Java for loops.

Oh, now I understand what you mean - you're thinking of this as a way to do `for (T x : collection)` in Java. I see this as more like the `yield return` functions of C#, which I definitely wasn't expecting. That can of course also be used to implement an iterator for a collection, but it seems much more general. Given that before generics Go had exactly 3 types of collections, and that those were all iterable with ra…

Iterator is not only about collections. Its not as powerful as a yield around continuations but you can return whatever you like.

~15 (?) years ago I wrote a "famous" blog post on how to use Iterator as a poor man Maybe/Option.

   for (String s: m Option) {
     // Executed on Some
   }

Re: Go 1.22

#132

Post by cpuguy83 »

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.

That's fine if you don't have any downstreams. Painful when upstreams change this for no functional gain.

Re: Go 1.22

#133

Post by xyzzy_plugh »

konart wrote: post #84
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)

https://go.dev/blog/toolchain

Re: Go 1.22

#134

Post by zellyn »

zellyn wrote: post #25
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 Square, we typically wait until the first point release before updating the default version in our Go monorepo. Individual application owners are free to upgrade sooner. This time, we had some wiggles, so the Go team beat us to 1.22 before we could upgrade our default to 1.21 :-) Waiting is more or less just customary at this point; Go releases seldom break things.

Benjamin Wester (whom I just found out reads this and saw my comment, so now I don't feel weird randomly mentioning by name!) is the true hero of our monorepo's upgrades.

Re: Go 1.22

#135

Post by Zach_the_Lizard »

shirogane86x wrote: post #127
puika wrote: post #85

Earlier quoted context omitted.

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

I've had many cases in the past (not in go) where I've had to make use of that exact same function (in typescript, in F#, and in C#). it is actually quite useful when doing any amount of data manipulation (map/filter/reduce chain that often ends up into a list of key-value pairs, which then get turned into a map/dictionary of sorts). At least in my job(s over the years), turning a flat list of db records into a more…

Part of the issue is that Go has a variety of design choices / limitations that conspire to produce different design patterns in this area than what you might see with e.g. Java.

For example: let's say we want to implement something akin to Java's Comparator interface.

Java allows interfaces to be extended with default implementations. It also allows methods to specify their own generics separate from the entire interface / class.

Thus the "comparing()" method can take in a Function that extracts a value of type U from T that is used for comparison purposes. The return type is Comparator.

(Generics simplified a bit, there are other overloads, etc.)

There's also thenComparing(), which allows chaining Comparator instances and / or chaining Function.

As a consequence, one can use .thenComparing() to build up a Comparator from the fields on a class pretty quickly. Especially with lambda syntax.

Go doesn't support methods having different type parameters than the overall interface / struct.

Go also doesn't have default implementations. It doesn't allow function or method overloading.

Go does have first class functions, however.

To build the equivalent capability, you'd most likely build everything around a comparison function (func[T any](a, b T) int) and write a bunch of functions to glue them together / handle useful operations.

That impacts the readability of a long chain of calls, especially since Go doesn't have a lambda syntax to make things a bit tighter.

Getting rid of the limitation on method-level generics would make this _significantly_ more ergonomic.

Re: Go 1.22

#136

Post by eweise »

buzer wrote: post #41
eweise wrote: post #24

Earlier quoted context omitted.

Curious when you need to know when null is intentional or not. There's no corresponding type like that in the db.

For example when you are using partially populated record to update the database. If field is null intentionally it means it should be updated to it. If it's not set the update statement should not touch it.

Thanks. That makes sense. I don't have that pattern in my code but I can see that some might.

Re: Go 1.22

#137

Post by sitzkrieg »

dont get me wrong, i enjoy go and use it professionally with little complaints.

but its kinda funny seeing several of the examples people used for go's pick-up-simplicity being added to the language, like generics and apparently generators etc.

but im still fine with it as long as there is no extreme hidden logic on the level if operator overloading, crazy ctor chains, etc

Re: Go 1.22

#138

Post by bradleyishungry »

divan wrote: post #57

I've been writing Go for 9+ years, but for the last 4 years, I had to write a lot of Dart (for Flutter). I consider these two languages to be on the opposite sides of the complexity stance. Dart tries to add and implement every feature possible, but Go is the opposite. Two observations: 1) I'm spending a lot of time fighting multiple ways to init stuff in a class (i.e., declare the variable and set the value). Depend…

initstate is an override of statefulwidget, its no different than any other frameworks lifecycle events and its a flutter thing, so its not really something you would confuse with a constructor or something. I can understand not knowing if you should create a normal constructor or a factory i guess, but getting confused about initstate is not a reason go is superior.

Re: Go 1.22

#139

Post by peter_l_downs »

buzer wrote: post #41
eweise wrote: post #24

Earlier quoted context omitted.

Curious when you need to know when null is intentional or not. There's no corresponding type like that in the db.

For example when you are using partially populated record to update the database. If field is null intentionally it means it should be updated to it. If it's not set the update statement should not touch it.

This is a great explanation. Sqlboiler allows you to send an update that will infer which values have changed and should be written — I bet that’s related to this. TIL!

Re: Go 1.22

#140

Post by konart »

KingOfCoders wrote: post #105
konart wrote: post #84

Earlier quoted context omitted.

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)

Sorry not a native speaker. My understanding of "upgrading" a toolchain or dependecy in a project means, changing to a new version of the toolchain or dependency and make the project work again? With 1.22 memory consumption should be less and PGO has better performance from my understanding. When I change the minimum version in my project to 1.22.0 it will download 1.22.0 and use this for compilation. I would call th…

No need to be sorry. Not a native speaker either.

I get your point. I'm just to used to the fact that Homebrew updates packages on the machine and services are build during CI\CD pipelines inside of a container.

Post reply on HN