Go 1.22 (opens in new tab)

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 again. Programming languages can't do this, so I'm happy that Go keeps this in mind.

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

Yeah, it's quite productive in a counter intuitive way, not having a ton of features just removes a lot of tiny decisions you have to make in a richer language.

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

Go is beautiful, productive, readable. I love Go. It's my "C with niceties".

I feel the same way. I was recently evaluating TypeScript and Go for a small project at work, having little experience with either. I went with Go almost entirely because I’d made decent progress in solving the problem by the end of my timeboxed investigation period. After a similar time with TypeScript, all I’d really done was get bogged down trying to work out what tooling I should be using.

Compilation, testing, and automatically formatting TypeScript all have multitudes of options with their own pros and cons. All that stuff is just built into the Go toolchain. Yeah it’s not always perfect but it’s more than good enough and, importantly, it’s ubiquitous. There’s nothing to think about or argue over.

That said, I’ve been wanting to try Deno. My understanding is that it takes a much more Go-like approach to running TypeScript.

Yeah someone I know has been banging on about go, too. I have a personal project I want to do so maybe I'll pick go for it.

The main pro and con to the JS ecosystem is the fact that it's so flexible; you can mostly do things how you want and there are so many libraries in each space all competing. But because you can do anything how you like it becomes hard to decide which library you want to use (or a diff one every project) and every dev has a different way of accomplishing the same thing.

I used to write internal libraries and frameworks a lot in my career and one of my mantras was to use TS to try to lock devs into doing things a certain way but there only so far you can go.

My main worry with Go is like, is everything built in? Are there multiple say, Web server libs like with nodejs or only a single option? How are deficiencies addressed if there are fewer options and fewer ways og doing things?

Go is the language for getting sh*t done.

Interesting ...

>> The amount of time spent on things such as linting, selecting the correct library for server routing, the correct server, coding standards,

I don't fully agree here. Those points are pretty straight forward and coding standards (not formatting, for TS prettier is pretty standard, btw.) need to be defined even in Go projects. Also, Deno has much of the setting up solved.

>> basic error-handling and enforcing it with a custom error or Result type to get out of this nested try/catch hell which still loses the majority of errors.

Fully agreed. Maybe I have a big lack of understanding of error handling in NodeJS, but how on earth do I find out what functions can throw errors and what are the errors thrown? If someone could enlighten me I'd be really grateful. To be on the safe side I would need to run my whole code in a try..catch block. How to decide how to handle different errors if I don't know which errors can occur? On the other hand, just yesterday I had to debug a Rust panic in a smallish code base. Even with stacktraces turned on it took half an hour to find out where there error occurred. Still, Go and Rusts error handling is much better. IIRC, in Java you see all types of exceptions that can occur in the docs of a function?

>> Setting up testing and mocking. Setting up Prisma

Again, not a big thing IMO. If you like an ORM, Prisma is one of the best.

>> Don't get me wrong, I really do like Typescript.

Yeah, that's the thing. Typescript is such a fantastic language. Writing Go feels like using a hand-axe. Typescript's null handling alone makes it 10 times better (I hope everyone is using it, but that underlines your point regarding the conventions needed ...). I recently found a lib that gives us compile time checked pattern matching like in Rust.

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.

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

Other replies miss the point - the problem doesn't lie with Typescript itself exactly. Setting up a nodejs/js project with all of the fixings (linting, Typescript, spell checks, builds if needed, etc) is quite tedious.

Sure you can accept some template project or CLI tool to kickstart things if just starting out, but at some point you will need to tweak the configuration and there is an enormous realm of options.

I'm surprised no one mentioned this already, but a runtime like Deno goes to great lengths to solve alot of these pain points. You get testing, linting, bundling, and Typescript out-of-the-box with sane settings. If Deno worked better with GRPC I'd probably be using it right now in my work projects!

> can't wait for some map/filter/find slice functions though!

just use a for loop. 90% of the time the code will actually be clearer, and faster.

the hoops people just through to avoid 2 extra lines of code is mind boggling.

Deno fixes most of the issues you're describing.

I love go. It's just so simple.

Cool, that does help. It wasn't immediately obvious what the problem with the for loop sharing thing meant, but seeing it run and give unexpected results helped. :)

Thank you this is awesome. I find it so much quicker to read and understand things like this with examples.. and these are runnable / editable! Sick.

The Compact and Replace examples leave me puzzled, are they correct?

Oh, it's great.

really cool

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.

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.

initstate is an override of statefulwidget, its no different than any other frameworks lifecycle events and its a flutter thing, so its not really something you would confuse with a constructor or something. I can understand not knowing if you should create a normal constructor or a factory i guess, but getting confused about initstate is not a reason go is superior.

We should be optimizing for expensive experts’ ability to communicate concisely with each other. Keeping the power tools of syntax out of novice hands just deters them from developing expertise.

Go standard library is absolutely littered with these kinds of tweaks. Not necessarily bad, but it does make an integration with non-standard library less satisfactory because such special casing is not scalable. Still within the expectation though.

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.

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.

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.

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

So at the moment this feature is optional / experimental and opt-in; if they make it standard on, I hope they add an opt-out mechanism of sorts, so that developers are discouraged to use it if it's not commonplace.

I find that one big problem with software developers is keeping developers from adding complexity, or "flexing". Especially developers earlier in their career, present company included, tend to overcomplicate a solution instead of just solve the problem in a straightforward albeit inelegant and wordy fashion and move on.

I also think this feature feels premature. Ideally, it should be introduced after lambdas and generic parameter packs. The Generics support in Golang is not sophisticated enough to support this at the moment leading to the strangely imposed limitations

I'm ambivalent as well. It doesn't even save lines of code compared to passing an inline function.

Curious when you need to know when null is intentional or not. There's no corresponding type like that in the db.

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.

At Square, we typically wait until the first point release before updating the default version in our Go monorepo. Individual application owners are free to upgrade sooner. This time, we had some wiggles, so the Go team beat us to 1.22 before we could upgrade our default to 1.21 :-)

Waiting is more or less just customary at this point; Go releases seldom break things.

We usually wait to experiment with new features until we find a good problem that would fit, but we upgrade compiler version pretty much right after they release. For instance we waited on actually using generics for about 6 months until we were able to experiment a bit and make sure they were really useful, the devx was good, and build/test speeds weren't significantly impacted.

At my $DAYJOB devs are free to jump on latest builds for containers we operate (SaaS / API services).

But we also deliver end-user apps with Go, and those have to stick to 1.20 for compatibility with older client OSes. 1.21 made significant cuts and so we will likely be on 1.20 for some years to come.

Our CI builds and tests using the 'latest' container for Go, and we have a fairly robust test suite so it essentially auto-updates as things go and breaks the pipeline if anything doesn't work, at which time we either decide to pin the latest working version while we update or hold off on the update to fix breaking changes.

Very rarely, like once every few years, there's some subtle edge case bug that shows up with a third party package and the new version, but honestly we'd never catch that if we were manually upgrading anyways, as by definition these bugs avoided our test suite.

I switch right away.

If you're worried about supporting older Go compilers, you could always have build conditions for older versions that define missing things like:

// +build !go1.7

type any = interface{}

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)

At work, we upgrade when there's a compelling reason (structured logging in 1.21 came close; we haven't finished migrating from our old logger yet). Before deploying that version, we typically bump versions in all our Go repos and run the tests in those repos. Having the same version across apps gives some people on our team a bit of comfort (with Go, it's not as important as some other runtimes).

Usually we switch after the first point release.

I switched right away. All of our images are tagged anyway so rolling back is hella easy.

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.

Upgrade our binaries immediately, then bump go.mod `go` directive as we touch things.

You find

  func Backward[E any](s []E) func(func(int, E) bool) {
    return func(yield func(int, E) bool) {
        for i := len(s)-1; i >= 0; i-- {
            if !yield(i, s[i]) {
                return
            }
        }
    }
  }

simpler than C#'s

  IEnumerable<T> Backward(T[] s) {
    for i := s.length-1; i >= 0; i-- {
            yield return s[i];
    }
  }

I think that's quite hard to defend, honestly. Granted, Java doesn't have anything comparable, so I'm not sure what you're comparing this feature to.

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)

That's fine if you don't have any downstreams. Painful when upstreams change this for no functional gain.

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.

      for i := range 10 {

What was the syntax for this before?

While the phrasing is funny, it's really more "we now have a direct equivalent to 10.times in ruby"