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

61–70 of 164 posts

Re: Go 1.22

#61

Post by norman784 »

pjmlp wrote: post #48
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…

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.

Re: Go 1.22

#62

Post by carstenhag »

zaphodias wrote: post #55
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…

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.

Re: Go 1.22

#63

Post by avtolik »

cookiengineer wrote: post #43
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 feel very similar to your experience. What made me stay in go is its amazingly unified build toolchain. The things you can do with go:embed and go:generate blow my mind in every other project. The golang.org/x package is also another thing, where there is pretty much every internet RFC related implementation available, ready to use.

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

Re: Go 1.22

#64

Post by hambos22 »

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

Re: Go 1.22

#65

Post by bheadmaster »

avtolik wrote: post #63
cookiengineer wrote: post #43

Earlier quoted context omitted.

I feel very similar to your experience. What made me stay in go is its amazingly unified build toolchain. The things you can do with go:embed and go:generate blow my mind in every other project. The golang.org/x package is also another thing, where there is pretty much every internet RFC related implementation available, ready to use.

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!), it also increases speed of the application, as it no longer has to perform file system reads in order to serve a webpage.

Re: Go 1.22

#66

Post by gotbeans »

avtolik wrote: post #63
cookiengineer wrote: post #43

Earlier quoted context omitted.

I feel very similar to your experience. What made me stay in go is its amazingly unified build toolchain. The things you can do with go:embed and go:generate blow my mind in every other project. The golang.org/x package is also another thing, where there is pretty much every internet RFC related implementation available, ready to use.

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

Not OP, used embedded to add ebpf code compiled for a project, helps to only ship the binary. Same thing for shipping swagger static html stuff to host an OpenAPI server.

Re: Go 1.22

#67

Post by ken47 »

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…

Yes, but TS users can stay on the "type-newbie" path, which is still a huge improvement over vanilla JS and doesn't take much effort. What I've had issues with is devs who came from the vanilla JS world and love it, so they go out of their way to avoid utilizing more complex types when they would add no-cost safety (aside from the initial minutes or hour spent learning the feature).

Re: Go 1.22

#68

Post by bheadmaster »

carstenhag wrote: post #62
zaphodias wrote: post #55

Earlier quoted context omitted.

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…

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 order to make all those bugs disappear. In a way, they modified the formal contract to make it more aligned with the de-facto contract that users were expecting.

I personally think that kind of pragmatism beats purism any day. Maybe the fact that I've never personally been affected by Go backwards incompatibilities also plays a role... But I've yet to find a single person who has :)

Re: Go 1.22

#69

Post by kubb »

Range over function is actually good. Now we can implement proper iterators for collections. In particular, it should be possible to have abstractions like clojure-style lazy sequences.

Re: Go 1.22

#70

Post by falsandtru »

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…

They just keep adding new features for fear of losing their position because they can't decorate the release notes. MS doesn't give high marks for bug fixes. Thus the bugs keep growing.
Post reply on HN