This seems a lot more like someone deciding on Go up front and then pushing a process through to pick it - it wasn't the fastest in their tests and it was the only language without existing usage at the company, and basically all the qualitative advantages are either not very unique or not quantifiable or both. No other new languages besides Go were even considered, despite some that easily meet the criteria for consideration.
I actually worked with Ben for a couple of my formative years as a software engineer - he's an extremely smart guy.<p>I'm no longer with Amex (still up for debate in my mind if that was a good idea to leave or not), but last I heard the department was very successful in onboarding a lot of their Java engineers to Go and transitioning to a Golang microservice architecture.
This is from 2019. I'd be curious how all of this worked out for AMEX. We've got over 4 years behind this decision now.<p>Edit: I found a followup from 2021 - <a href="https://youtu.be/e7PtBOsTpXE" rel="nofollow">https://youtu.be/e7PtBOsTpXE</a>
Whether they had chosen Go or Java, or anything else, what I see here is an internal culture that really takes ownership of their language choice. That is its weight worth in gold. That is what matters in the end ("can we ship?") - not potential issues with the language itself.
Go is a decent industrial programming language alternative to Java, only things I'm not super enthused about is the logging experience (for the love of Christ, please create a standardised logging facade along the lines of slf4j, and allow the person running the application to set logging levels for individual loggers and choose whether stack-traces are emitted or not! Bonus points if I can change logging conf for a running app without restarting it) and libs that use C bindings, I have enough problems with that in Python already.<p>E.g., my manager is really interested in Dapr as a way to make basic Kafka usage easier for teams across our org.<p>Dapr's written in Go, and have made the reasonable decision to not use any libs that have C bindings for the same reason I don't like them.<p>However, this means that they can't use the Confluent Go Kafka client, as it's just a wrapper around librdkafka.<p>So they use Sarama, as it's written in pure Go, and is widely used, but is one of the most problematic Kafka clients I've had the misfortune to support. Although now that IBM has taken ownership of the project from Shopify, some of the more egregious bugs and oddities are finally being fixed.<p>But yeah, while you _can_ bind to C libs in Java, I've never encountered a library that did, so cross-platform lib compatibility wasn't something I ever had to worry about when working with Java.
I say this as a personal rust fan, but practically if a language like a combination of Kotlin+Go existed, that'd be like an awesome standard business language. Kotlin is good but just very tied to the JVM, Go has a hostile syntax/developer experience. Another way to frame it is like Rust with a garbage collector. Most biz APIs don't really need zero cost abstractions of Rust.
I need Go to take one lesson from rust and that’s specifying if a function will mutate values passed through it or not.<p>This can technically be done as a breaking change spread over several versions of go and I think the cost would be worth what we’d get out of it. Utilities can also be made to edit code to support this automatically without having to have some user go fix it all.<p>Basically, I want an introduction of either a function level or value level ‘nut’ keyword like Rust where the function can not mutate a field unless it has explicitly stated mut.<p>This would fundamentally solve a whole class of bugs and errors that happen in go where some library ends up modifying a struct (pointer or a struct with a pointer field) without the caller intending that.
Lately I have been more interested in rust. Similar trade offs but “fearless concurrency”, access to low level APIs, and no garbage collector sold it for me.
I love how stubbornly plain and lacking in magic Go is. There is almost no hidden control flow, there's no aspect oriented programming, or operator overloading, etc., etc. - pretty much everything the code actually does is in front of you.<p>I think this means you have a bigger upfront cost in writing code the first time, with the benefit of easier debugging and easy maintenance later (which is a tradeoff I'm very happy to take).
Discussed at the time:<p><i>Choosing Go at American Express</i> - <a href="https://news.ycombinator.com/item?id=21637916">https://news.ycombinator.com/item?id=21637916</a> - Nov 2019 (15 comments)
not to be the “but rust” person, but I’m curious why Rust wasn’t in the test group. it seems to meet all their criteria, though the community was a bit smaller back then.<p>Go is a perfectly reasonable choice though, and easier to learn on average.
After using both java and go, I prefer go. The tooling is simpler and more intuitive, the feature set is less bloated (fewer useless things reinventing the wheel like streams api), it also isn't affiliated with Oracle<p>In general java feels more enshittified in comparison