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

51–60 of 164 posts

Re: Go 1.22

#51

Post by tommiegannert »

> 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 against the Go 1 compatibility promise?

> It is intended that programs written to the Go 1 specification will continue to compile and run correctly, unchanged, over the lifetime of that specification.

Re: Go 1.22

#52

Post by lnxg33k1 »

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’ve worked for a while at a client using typescript, after a while I started calling it “Tricks Driven Development”, every time I had to do something I’d read the docs, but then someone would communicate some trick not on the docs that was possible to use

Re: Go 1.22

#54

Post by shakow »

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

> anything ambiguous is probably going to haunt me at 3am some day

Man, I hope you never wondered how ERRNO behaves with CGo or that you didn't miss to update any initialization of that struct you recently added a new field to, that haunts me at 3AM.

Re: Go 1.22

#55

Post by zaphodias »

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…

Usually the Go team scrapes from GitHub and open source programs how people use something before breaking them; I suspect they found little usage of { and } in HTTP handler paths. They also provide a way of opting out the new behaviour, so they don't force you to change anything in your code (but yes, it does require you to set a new env var).

The change to the for loop semantic is another example in this release; it effectively is a breaking change.

All Go programs continue to compile and run, though with minor behavioural changes. I think Go took a pragmatic approach, and that was one of the reasons for its success.

Re: Go 1.22

#56

Post by fbdab103 »

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…

Because then they would lose their pithy advertising slogan. Minor or not, it is a non-compatible change.

Re: Go 1.22

#57

Post by divan »

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). Depending on the final/const/static/late prefix, there are multiple ways to init it in the constructor or factory or initState() method of Flutter's StatefulWidget, and god forbid you to refactor any of that – you'll be forced to rehaul all the initialization. Dart's getter feature (which makes functions look like variables) also adds confusion, especially with a new codebase. I constantly find it embarrassing how much time I need to spend on such a straightforward thing as variable/field initialization. I often find myself missing the simplicity of Go.

2) Compared to Go, Dart has all the juicy stuff like maps/streams/whatever for packing all in a single line. It's very tempting to use those for quickly creating singleliners with hard-to-understand complexity. Sometimes I even start feeling that I'm missing those in Go. But when I get to debugging those or, especially, junior developers looking at these write-only singleliners, with an array of ugly hacks like .firstWhereOrNull or optional '(orElse: () => null)' parameters, they are very confused, especially when cryptic null safety or type errors stops them. Rewriting those singleliners as a simple Go-style for loop is such a relief.

Re: Go 1.22

#58

Post by doctor_eval »

I’m super excited to see range over functions - iterators. It’s one of the only things I miss from Java.

It took me a few reads to understand how the work, but in typical Go style (once I got it) it was so much simpler than the equivalent in most other languages I’ve used. Looking forward to it being promoted out of experimental.

Re: Go 1.22

#59

Post by doctor_eval »

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…

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 don’t care about the lack of constructors; mostly, I just wish I could have bools initialise to true sometimes.

Re: Go 1.22

#60

Post by Jean-Papoulos »

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…

Tip about Dart : Don't use initState for stuff that doesn't directly concern UI (setting the hint of a text field, for example).

Most of my Flutter pages rely either on having very few things to do, or having a MyPageController object such that the parent creates a controller, initializes it however it likes and the child page's behavior is dependent on that controller. A typical example of this would be the parent being a page containing a list, and the user wanting to edit a list element. Create a controller, give it the element, and send the controller to a child page where the user does the editing. On return, the parent can look at the element or other variables/callbacks in the controller to decide what should change in the UI.

This also allows finely-controlled interactions between widgets without having to delete with InheritedWidget or the likes. Of course you should use a state management library with this, even though a lot of the time I don't.

Post reply on HN