
Choosing Go at American Express - madflojo
https://americanexpress.io/choosing-go/
======
mikece
"...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."

I am curious: why was Go the only language not currently in use at AMEX to be
considered? Why not Rust? Why not dotNet Core?

~~~
madflojo
I'm not an expert in Rust or dotNet Core but I can give a bit of insight. At
the time (2016) Rust wasn't as visibly used in production as it is today. Also
from my understanding over the past few years a lot of new features have gone
into Rust which makes it more viable these days.

As far as dotNet Core, it is used at AXP but generally not in our high
performance environments. Not saying it couldn't as I'd have to do a lot more
research to say one way or another on that. But I'd say that's the primary
reason it wasn't added to the list.

~~~
mikece
My apologies: I missed the 2016 reference -- I wouldn't have recommended
dotNetCore three years ago and I'm only now waking up to the power of and
speed of Rust and didn't realize just how young it is. I'm still a little
amused that Go was the __only __language not in use already that was
considered but understand that the list of possible high performance
alternatives was indeed short... shorter than I realized.

~~~
madflojo
All good. There were a lot of factors to creating the list, Enterprise use and
readiness was one big one. So we narrowed it down to what we thought were the
best choices. Always the possibility we missed something, but thats true of
any decision like this.

Appreciate the read and questions though!

~~~
mikece
Are you on the AMEX team(s) in question? I am always interested in knowing all
of the factors that were part of the decision in why a team chose the language
or platform it did and if, after a respectable period of time, everyone is
still happy with the choice or if there's buyer's remorse and what greener
pasture languages/platforms (or problems with the selected stack) are bringing
on those second thoughts.

~~~
madflojo
Yeah, thoughts and opinions are my own of course but overall we've had good
experiences.

I tried to insert some of the benefits we are seeing into the article in
different pieces but now that we are several years later have it running in
production. We are happy with the decision. In my opinion, there are even some
newer things we didn't write in Go that I kind of wish we did.

The reasons we choose Go are holding true, and I can't say enough about how
the performance and low GC times out of the box is something that is very
beneficial. At least for my use cases.

------
parliament32
>Go achieved the second-best performance at 140,000 requests per second. This
number wasn’t far off from the top performer, which clocked in at 167,000
requests per second.

I wonder what the top performer was... I bet it was C.

If you're doing just binary to string conversion there's no need for a
features-language like Java or Node. C probably would've been a better option.

~~~
sfifs
C/C++ are _never_ better options because of the number and sheer variety of
undefined behaviors, manual memory management and ways to shoot onself on the
foot. It's something to use when there's no other choice (legacy code base,
embedded systems - though this is also moving to higher level languages).

~~~
parliament32
I promise you they are. There's a reason why over 90% of the programs you
invoke or interact with on a daily basis are written in C.

~~~
sfifs
Yes. Most of them are evolutions of legacy code bases and that's why they're
also security nightmares.

If you're building anything new it's very hard to make a valid case for coding
in C. You're almost always better off working in Rust, Java, Swift or Go

------
claytongulick
It would be nice to see a breakdown of pros/cons for the various languages,
the article doesn't really explain why other languages were excluded, it just
talks about the benefits of Go. Also, I'd be interested if the same decision
was made today, i.e. V8 has different performance characteristics than it did
in 2016, and there are interesting ways to reduce/overcome warmup time.

------
michannne
>These platforms were purpose built for performance, concurrency, resiliency,
and availability. Given advancements in the programming space, we wanted to
see what languages best suited our reliability and performance needs. We also
needed something that fit modern infrastructure and design patterns.

>As such, we launched an effort to evaluate different languages.

I feel the purpose of a payment network is performance, concurrency,
resiliency, and availability, and somewhere, wayyy towards the bottom of the
list, at 2px font size, modernity and extensibility are there.

------
tixocloud
Very interesting blog article. Thanks for sharing. Are you able to comment on
how ML might be integrated to the payments and rewards system? Is it just a
matter of APIs on top of Kubernetes/Docker? Or did you have to recreate models
in Go?

------
downerending
Seems weird to choose just one of { C++, Go, Java, Javascript }. None of these
languages is really a substitute for any of the others, except perhaps for Go
and Java.

Go certainly cannot cover all C++ uses, nor Javascript/Node.

~~~
detaro
They weren't choosing for all use cases, but for the ones they needed.

