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

101–110 of 164 posts

Re: Go 1.22

#101

Post by gwd »

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

You wouldn't write that exact function. You'd have some complicated pipeline that ended up in a map; and it might be easier to follow the logic using map / filter / fromentries.

Re: Go 1.22

#102

Post by WA »

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…

Is there a more simple JS linter that does 90% of what basic TypeScript does? I mostly use simple types (basic times, Promises, arrays, and a bunch of interfaces) and I find TypeScript valuable for that. It saved me a few times from accidentally treating a Promise as Whatever for example – and other things.

But I heard an interesting argument: It's not TypeScript vs. vanilla JS; it is TypeScript vs. whatever else full-blown linting/IDE comfort you can get by still writing vanilla JS with no transpile step.

Re: Go 1.22

#103

Post by ctz »

everybodyknows wrote: post #30
adtac wrote: post #21

Earlier quoted context omitted.

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

Interestingly, this does not raise any error, rather has no effect. for i := range -10 { panic(i) }

"yes, please run this loop minus 10 times" - statements dreamed up by the utterly Deranged

Re: Go 1.22

#104

Post by gwd »

kristianp wrote: post #12
shakow wrote: post #4

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

for i := range 10 { What was the syntax for this before?

I'm not sure what the syntax is now; the release notes say "see the spec for details[link]", but in the link I don't see anything in there about using integers as a range expression.

Re: Go 1.22

#105

Post by KingOfCoders »

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)

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 that "upgrading"

  ~/Development/inkmigo$ go version
  go version go1.22.0 linux/amd64

Re: Go 1.22

#106

Post by pjmlp »

WA wrote: post #102
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…

Is there a more simple JS linter that does 90% of what basic TypeScript does? I mostly use simple types (basic times, Promises, arrays, and a bunch of interfaces) and I find TypeScript valuable for that. It saved me a few times from accidentally treating a Promise as Whatever for example – and other things. But I heard an interesting argument: It's not TypeScript vs. vanilla JS; it is TypeScript vs. whatever else ful…

I guess the recent movement started by some projects to go back to JSDoc type annotations kind of answers that.

Re: Go 1.22

#107

Post by d0gsg0w00f »

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

Yes. Many times I've forgotten to remove my local "replace" in go.mod before git pushing. Would be nice to have a runtime replace for local dev.

Re: Go 1.22

#108

Post by nalgeon »

scns wrote: post #97
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?

They are correct.

> Functions that shrink the size of a slice (Delete, DeleteFunc, Compact, CompactFunc, and Replace) now zero the elements between the new length and the old length.

Re: Go 1.22

#109

Post by jhanschoo »

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…

> TS gets more and more complicated with each release, catering to the power users.

My understanding about the use of advanced/more expressive TR features is that it's OK if you don't use them, and don't bother wasting time for most products. Bot if you are writing a library of framework in TS, go ahead especially since they are meant to improve the experience of consumers.

Re: Go 1.22

#110

Post by maximus-decimus »

ctz wrote: post #103
everybodyknows wrote: post #30

Earlier quoted context omitted.

Interestingly, this does not raise any error, rather has no effect. for i := range -10 { panic(i) }

"yes, please run this loop minus 10 times" - statements dreamed up by the utterly Deranged

Back in my days, you had to do it this way

for i := 0; i 

  panic

}
Post reply on HN