[HN Gopher] Choosing Go at American Express (2019)
___________________________________________________________________
Choosing Go at American Express (2019)
Author : veqq
Score : 40 points
Date : 2024-01-03 13:17 UTC (9 hours ago)
(HTM) web link (americanexpress.io)
(TXT) w3m dump (americanexpress.io)
| sgt wrote:
| 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.
| bob1029 wrote:
| 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.
|
| Edit: I found a followup from 2021 - https://youtu.be/e7PtBOsTpXE
| evanm wrote:
| Curious what other languages were evaluated.
| vlod wrote:
| From [0] "Based on these criteria, we narrowed our testing
| languages to C++17, Java, Node.js, and Go. The first three
| languages were already in use at American Express, whereas Go
| was not."
|
| [0]: https://americanexpress.io/choosing-go/
| Ancalagon wrote:
| I actually worked with Ben for a couple of my formative years as
| a software engineer - he's an extremely smart guy.
|
| 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.
| matrix87 wrote:
| 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
|
| In general java feels more enshittified in comparison
| CobrastanJorji wrote:
| As someone who's got a lot of Java experience but almost no Go
| experience, I worry that I've been coddled with a humongous
| standard library for pretty much everything, from collections
| of every sort to handling of time, units, strings, I/O buffers,
| and pretty much every data structure I might need. Do you find
| that the Go ecosystem is rich enough that you can find whatever
| you require?
| rlawson wrote:
| Yes I had the exact same question. Philosophically I like Go
| better but I worry in practice that Java has me spoiled
| rad_gruchalski wrote:
| The Go ecosystem has everything one needs. The cryptography
| stuff is nicer than any Java library (sorry BouncyCastle),
| first class tls everywhere, very decent http client/server
| support and tons community routers, third-party collections
| are easy to come by, ssh in standard library, any package
| from the internet can be directly pulled as a dependency,
| packages can be renamed without the need of shadowing,
| kafka clients, any cloud sdk, everything what one can
| imagine.
|
| I was a heavy java snd scala user before 2018 and 5 years
| later I'm not missing anything. For what it's worth, life
| got easier when I moved to Go.
| holografix wrote:
| Go introduced generics as of recently therefore you won't
| find many of the more sophisticated collection types like
| trees and sorted lists etc. However there is an effort to
| include the usual suspects in the standard lib.
| matrix87 wrote:
| > Do you find that the Go ecosystem is rich enough that you
| can find whatever you require?
|
| For what I require (which is atm concurrent web services,
| restful and grpc APIs, occasional CLIs, k8s tools), it's on
| par with java
|
| For collections, I don't think go has the same variety as
| java built in but there are 3rd party implementations for
| more niche data structures like rb trees. Bare essentials
| like arraylists and hashmaps come built in
|
| In general, yeah ecosystem is more than good enough for me.
| Only big thing that I can think of that's missing is gui
| stuff like swing in java
| jmaker wrote:
| In my experience, in most cases you realize you're imminent
| to reinvent a wheel, you start sifting through the packages
| available and check GitHub, see what one or another package
| is up to, then I check whether the functionality that I need
| is well tested, in many cases it is not, sometimes you get
| perplexed skimming through the issues, there are few
| uniformly good packages in many cases, you always see
| something popping up that's been smoothed out in a Java
| pendent long ago. It's tricky.
|
| With JVM bound projects I've rarely felt compelled to
| actually examine the rather foundational packages. With Go,
| however, I'm often surprised, even when looking at the more
| popular packages or framework, kind of a different attitude,
| you know. Same goes to the Go runtime system behavior. The
| deeper you look the more you can see, I guess. There's always
| a caveat somewhere around the corner.
|
| That said, I do have a few Go systems in production. I love
| the lower memory footprint though it often comes at a cost of
| unnecessary CPU thrashing, which for the IO bound services I
| consider acceptable. I see some companies move to Go, the
| sentiment I've perceived is mixed.
| EdwardDiego wrote:
| The dependency management story (and noted by the author) is
| one where I wish people would just steal Java's approach.
|
| 1) Every package is namespaced 2) Namespaces are DNS names that
| you can prove you own
|
| It eliminates typosquatting, and the drama of "someone created
| a bunch of helloworld crates just to grab the good package
| names"
| liampulles wrote:
| I think Go's approach is similar - if you have a public repo,
| then whatever the DNS name is gives you a unique module name.
| For example, both of these modules can exist, and I can
| import both into a given Go project:
|
| github.com/rs/zerolog
|
| mysite.com/myforks/zerolog
| coredog64 wrote:
| "foo.int" is a valid domain but is not possible to use as a
| Java namespace. What do you do when your company gets bought
| or changes names? (com.sun.whatever vs. com.oracle.whatever)
| liampulles wrote:
| I was a Java dev for many years and I vastly prefer Go. A lot
| of it for me has to do with the inversion of control libraries
| providing "fake" simplicity, but becoming a nightmare when you
| have to try and figure out what thing in the background is know
| causing a bean conflict.
|
| The extremely straight control flow of Go makes it much easier
| to maintain in the long term IMO.
| closeparen wrote:
| Part of maintainability is readability and ease of debugging,
| and I agree that Go shines here. But another part is the ease
| of refactoring and rewriting. My experience is that Go
| codebases which aren't fundamentally doing very much
| nevertheless become ossified through sheer volume. This is
| especially the case when you have layered packages (MVC, etc)
| and consequently a lot of mocks. Most conceivable changes
| implicate dozens to hundreds of mock expectation lines, and
| thus become more trouble than they're worth. This is largely
| because fully explicit control flow needs to be fully
| explicitly unit tested every single time. Those tests weigh a
| lot.
| 7e wrote:
| How did they ensure their service benchmark wasn't I/O bound?
| dang wrote:
| Discussed at the time:
|
| _Choosing Go at American Express_ -
| https://news.ycombinator.com/item?id=21637916 - Nov 2019 (15
| comments)
| EdwardDiego wrote:
| 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.
|
| E.g., my manager is really interested in Dapr as a way to make
| basic Kafka usage easier for teams across our org.
|
| 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.
|
| However, this means that they can't use the Confluent Go Kafka
| client, as it's just a wrapper around librdkafka.
|
| 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.
|
| 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.
| liampulles wrote:
| You may rejoice on the logging front: https://go.dev/blog/slog
| aslilac wrote:
| 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.
|
| Go is a perfectly reasonable choice though, and easier to learn
| on average.
| steveklabnik wrote:
| https://news.ycombinator.com/item?id=21638455
| liampulles wrote:
| 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.
|
| 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).
___________________________________________________________________
(page generated 2024-01-03 23:01 UTC)