Live data from Hacker News

Choosing Go at American Express

americanexpress.io

1–10 of 16 posts

Re: Choosing Go at American Express

#2
"...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?

Re: Choosing Go at American Express

#3
post #2

"...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?

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.

Re: Choosing Go at American Express

#4
post #3
post #2

"...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?

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…

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.

Re: Choosing Go at American Express

#5
post #4
post #3

Earlier quoted context omitted.

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…

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.

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!

Re: Choosing Go at American Express

#6
post #5
post #4

Earlier quoted context omitted.

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.

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!

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.

Re: Choosing Go at American Express

#7
post #6
post #5

Earlier quoted context omitted.

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!

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.

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.

Re: Choosing Go at American Express

#8
>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.

Re: Choosing Go at American Express

#9
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.
Post reply on HN