I'm Coming Around To Go...

Like a certain other programming youtuber once said: "GO MENTIONED!"

TBH the real strong points of Go are: - single static binary (the EASIEST for deploy) - simple language (few keywords) - cross compiling is as easy as set GOOS and GOARCH - Pretty decent performances (not the best, not the worst) - MOST of the stdlib has consistent behavior - MOST of the 3rd party packages have consistent behavior - Simple and effective package manager - Perfect fit for backend services, literally, it is perfect - Absolutely perfect retrocompatibility (Rust, Python and TS haven't guaranteed it even with minor or patch version) About dev velocity: i have spent a lot of time time dealing with TS, npm errors and stuff. By that time, i finished two services in Go. That's subjective, but a consistent ecosystem is a great value to me.

Go was literaly our only option. We use Go with AWS Lambda and is not only about CPU performance but RAM usage, even with Bun, JIT and interpreted lanjuages like JS and Python can't handle 1M+ records in a 256mb RAM container, even Java or C# have a memory overheat due to their VM. So basicaly Go was our only alternative to cheap microservices with a good support for AWS SDK and low learning curve. Also, cross-compiling works great, since we use ARM based Lambdas, reducing the cost even further, all in just a 10 - 16 mb binary.

I see your points about type system and other choices Go made but in general I’d say Go has even greater velocity than JS/TS. My justifications are as follows: - You don’t need to worry about the tooling around your dev environment, such as prettier, test runner, package manager, etc. because all of them come with the language. - The language itself is really small and one can learn all of it in one day. It’s even possible to read the whole specification doing that. - If you use something like htmx, then you can even get away with not touching any JS. - The one way of doing things is especially important when you want to read an open source project’s code. Also, the community mostly shares the simplicity mentality, so projects are mostly higher quality and easy to pick up. So, in my mind, the Go streches to the end of the velocity spectrum and they are exploring if they can also stretch to the perf end of it. The hesitation is mostly around not messing the dev velocity/ simplicity part.

I've been programming in Go for 2 years now, and the book 100 Go mistakes and how to avoid them describes it quite fittingly from my perspective: "simple to learn but hard to master". The language constructs can be learned very easily, but learning to write solid idiomatic Go is pretty hard.On first sight the pull requests from juniors and seniors appear similar, but at my job, in a team of around 30 developers with varying experience, it is also easy to identify who has more Go experience.

One great concept GO has implemented is errors as values, yes, they are annoying, but one day I decided to implement the concept in al my TS code with a simple helper return type that forced me to handle the error first before the actual return values were considered completely defined types, and from that moment I never had anything crash on me. I don't even need so many tests now because the control flow is so much better. When you throw and catch errors, you actually have no idea where the error will be caught and how it will be handled, which in itself could cause subsequent errors and crashes.

I started with GO last year and came to love it so much. It is so easy if you are already familiar with another language. For web apps, I would recommend building some boilerplate and keeping it as a repo that you can pull whenever you want to start a new app. The biggest plus point is how simple it is to set up a Go project, there is no complexity behind the scenes and things can be managed with ease because you control almost everything about your application.

I think you hit the nail on the head with "Writing Go doesn't make me feel clever." This is IMO why so few people contribute to Go projects, there is nothing to learn. Go is the perfect language to just get shit done. Its the Toyota Corolla of programming languages. Sure, some people turbo and race their Corollas, but most people just go from A to B and couldn't care less. PS: This is why I like Go so much. C++ and JS show the personality of the lead programmer in the codebase, no 2 codebases look the same.

I haven't done much Go, but I use TS and Rust regularly and strongly disagree with the developer velocity thing, not because it's subjective but because we often forget what it takes to make software other than "just writing code". Correctness, edge cases and error handling, maintenance and even just "reading the docs" are all things we software engineers have to do a lot of, and all of them are easier in Rust. Can I write a bit of software faster in Typescript than Rust, sure, if I don't care about bugs and weird behaviour, telling people what I've done or whether this will still work in a few months time.

Go is simple and practical. You don't overcomplicate it with like what formatter, linter, or framework you use. A wise man said "Less is more"

Imo that "uncanny valley" you described... also contains C# and Java themselve (+Kotlin), which all have very good tooling. Granted C# and Java arent exactly "Shiny" modern languages, but they do deliver.

Compilation speed does matter. I worked on a team that used Go, and I could push to a dev branch and it tested, built, and deployed to the dev environment before I could bring up the CICD page lmao.

Go’s dev velocity is by far better than Typescript’s when you are trying to build a production grade tool with robust fault tolerance and synchronization. You might go faster in typescript, but are you confident you are handling every error graciously? Are you sure if you need to change a library or two it’s not going to take weeks? Are you sure that the new developers can read through your codebase and understand in an efficient manor. This is where I feel Go has the edge. Also it’s quite amazing to not think about asynchronous code at all. No function coloring is one the of best things about Golang. Sometimes making a function async in Typescript propagates all over the codebase requiring major refactoring.

the biggest reason I'm an advocate for making a full breaking change go v2 is to allow for the breadth of that uncanny valley it covers to widen. expanding the type system coverage to make it better to use, as well as adding performance things like arenas, or better methods of excluding the gc and forcing more efficient memory. the fact that go has calcified as it has, is both it's biggest feature and it's biggest detriment imo. also, today I learned that there's a good chance I've worked on the same code as Theo, given the tiny bits of exlixer I've touched at twitch lol.

For those not anti microsoft, you can write zero garbage collection C# and go extremely fast. Like the kestrel web server with does zero allocation request handling.

I've been loving go. Pointers are weird, but once I realized they are an "opt in to mutability" flag, it all clicks. I find the Go code I write is easy to understand 6 months later. The language pushes me towards simplicity. Delightful! I just wish the type system could catch nil pointer mistakes.

When you watch theprimeagen videos too often, you will feel JavaScript is too low and TypeScript is just a JavaScript linter and Rust is too hard and Go is just fit for my level.

Go is 90% the speed of Rust and 90% the productivity of dynamic languages.

My experience has been Python for the past few years because the tasks at my job were able to be done in an afternoon with it. Incredible velocity and happy management. What I learned was having to dig up one of these projects to add a new feature was painful. Moving fast in a dynamic language is a blessing and a curse. I used go for advent of code and was impressed that it compiled to windows and Linux out of the box and it was fast. Both in performance and velocity. This year I have replaced 2/5 of my python services in an etl pipeline which allowed us to turn off half the VMs. Adding additional features has been easier with less bugs.

on his ts v go v rust video, prime said golang was the language he had the least experience in and the one it took the least amount of time to write. He said rust was his most used language, and that i took around 5x the time to write it. and go won in that performance comparison, because apparently he didn't write rust the "correct" way, which just shows that in most cases, go actually ends up being faster eventhough rust has the potential to be faster.