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

71–80 of 164 posts

Re: Go 1.22

#71

Post by endtime »

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 got to spend a couple years writing Dart (not Flutter) and found it to be the best of both worlds. Such an underappreciated language.

Re: Go 1.22

#72

Post by EdiX »

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…

The way they are using to route around the Go 1 compatibility promise is to gate these backwards incompatible changes on the value of the go directive in go.mod. If it says 1.22 or later you get the new library behavior, otherwise you get the old one. We'll see how well this ends up working in practice.

Re: Go 1.22

#73

Post by divan »

doctor_eval wrote: post #59
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…

Sure, it's always a tradeoff. Yet my pet peeve is that people rarely talk about the social aspects of the programming language. It's called "language" for a reason. We express our thoughts using this language ("I intend this code to do such and such"), and we expect other people to be able to understand what we intended, and we want to make sure that they understand exactly as we want them to.

I judge languages on their ability to collectively construct mental maps in the brains of the developers who work on the same project. If they all read the same code, will they be able to understand the task and intent of that code without additional explanations? How cognitively hard would it be?

Gottfried Liebnitz was obsessed with finding a Universal Language, which was exactly about this – making communication clear and lacking misunderstanding. I feel like Dart (and most other languages) approach is the opposite of that. Creating multiple ways to express the same intent is a sure go way to introduce misunderstanding and fracture the speakers of that language into dialects and groups. Go's, on the other hand, is really good at making this "reconstructing mental map" part a joy.

Re: Go 1.22

#74

Post by divan »

Jean-Papoulos wrote: post #60
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 b…

Some people joke that state management in Flutter is like http mixers/routes in Go. But I think it's much worse :)

Granted, UI state handling is not an easy task, and it's not directly related to the topic of complexity of the languages. I had an article written a few years ago about a thought experiment of Flutter being implemented with Go. It's a bit naive, but still fun to think about. [1]

[1] https://divan.dev/posts/flutter_go/

Re: Go 1.22

#75

Post by tonis2 »

endtime wrote: post #71
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 got to spend a couple years writing Dart (not Flutter) and found it to be the best of both worlds. Such an underappreciated language.

Yeah, Dart is way better / easier to debug, than Typescript in my opinion

Re: Go 1.22

#76

Post by maccard »

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?

We use go:generate to generate services and types from protobufs.

    //go:generate protoc --go_out=src/generated/ protos/service.proto
Our CI pipeline is a dockerfile that looks vaguely like this:

    FROM golang:1.21 as build
    go generate
    go build
    go test

    FROM scratch
    COPY --from=build ...
The CI steps are: docker build && docker push

We have a goland project template that has options for generate, build, test that matches what we do in CI rather than having that _one_ edge case that is the difference between `make build` and `go build`. That difference has caused more than one outage in my career.

Re: Go 1.22

#77

Post by maccard »

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…

I agree this is a (rare) mistake with Go. If they're going to break versioning using go.mod, they should at least break it in a way that makes it better. I'd much rather have my code fail to compile when we change go.mod to 1.22 than have to detect subtle runtime issues like this.

Re: Go 1.22

#78

Post by catherinecodes »

candiddevmike wrote: post #7

Looking forward to revisting the stdlib mux and possibly removing chi. I really appreciate seeing this stuff move into the stdlib.

Came here to say the exact same thing. chi has been reallly great for a couple projects--in fact, it's easy to forget it's even here. Moving them into the stdlib means they'll always be maintained and ensure that approach is used in many Go programs.

Re: Go 1.22

#79

Post by maccard »

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

We try to keep up to date. We'll be on 1.22 by the end of the month, give or take (all going well)

Re: Go 1.22

#80

Post by miningape »

norman784 wrote: post #61
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…

Do you know if the Javascript type annotations is progressing? I didn't hear anything after the initial proposal.

I don't have the source at hand but I remember seeing that they wouldn't support it until it had progressed as a JavaScript proposal. Their reasoning was that the decorations API is really weak, and it will likely be changed meaning a complete rewrite of the TypeScript decorator implementations.
Post reply on HN