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

41–50 of 164 posts

Re: Go 1.22

#41

Post by buzer »

eweise wrote: post #24
peter_l_downs wrote: post #15

The addition of `sql.Null[T]` is great. I'll probably start using that in new projects. In current stuff, I'm relying on sqlboiler's null [0] whose API is very similar — it works the same way as `sql.Null` will, but has an additional `IsSet() bool` method that tells you whether or not the value was ever explicitly set, to help you distinguish "intentionally null" from "null due to uninitialization". (Sounds nice, but…

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.

Re: Go 1.22

#43

Post by cookiengineer »

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.

Re: Go 1.22

#45

Post by icholy »

dgunay wrote: post #40
metaltyphoon wrote: post #20

Earlier quoted context omitted.

Wish you could do for i := range [3:10] {

I think you could write something using the experimental Rangefunc feature that does that.

You can, which makes me wonder why they added the range-over-int functionality when it could have been a function in the proposed iter package:

   for x := range iter.N(10) { ... }

Re: Go 1.22

#46

Post by miki123211 »

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" :-/).

I don't think this is necessarily true, most of the standard library docs have switched over to using any, even when generics are not involved.

Re: Go 1.22

#47

Post by [deleted] »

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" :-/).

[deleted]

Re: Go 1.22

#48

Post by pjmlp »

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…

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 in JavaScript now in the roadmap, being good enough for general use cases.

Re: Go 1.22

#49

Post by baby »

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…

The problem of typescript is the lack of convention and the emphasis on configuration, the reverse made Golang a great language.

Re: Go 1.22

#50

Post by moondev »

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
Post reply on HN