Choosing Go at American Express • Hacker News Board

Re: Choosing Go at American Express

#11

Post by detaro » Tue, Nov 26, 2019, 7:49 PM UTC

downerending wrote: post #10

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.

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

Re: Choosing Go at American Express

#12

Post by michannne » Tue, Nov 26, 2019, 9:25 PM UTC

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

Re: Choosing Go at American Express

#13

Post by sfifs » Wed, Nov 27, 2019, 3:21 AM UTC

parliament32 wrote: post #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.

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).

Re: Choosing Go at American Express

#14

Post by tixocloud » Wed, Nov 27, 2019, 5:14 PM UTC

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?

Re: Choosing Go at American Express

#15

Post by parliament32 » Wed, Nov 27, 2019, 5:27 PM UTC

sfifs wrote: post #13

parliament32 wrote: post #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.

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).

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.

Re: Choosing Go at American Express

#16

Post by sfifs » Thu, Nov 28, 2019, 11:56 AM UTC

parliament32 wrote: post #15

sfifs wrote: post #13

Earlier quoted context omitted.

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).

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.

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