[Hendrikto]

> We attempted to move into Go […], but similar to interpreted languages it can be rather hard to optimize it. […] So it was easier to just go with Python

I don’t get that. You had trouble optimizing Go, so you went with Python?

[devjab]

We had Python and C. We aimed for Go. Now we have Python and C. Yhe deeper story is more change management than technically. We hoped we could obtain advantages from Go because we, perhaps naively, figured it would lessen the gap between programming and software engeniering. We have a lot of people who can build software, but few who can optimise it. We hoped Go would give us a lot of "free" optimisaton, but it didn't. It also wasn't as easy to transition not SWE's into not Python as we had hoped. We made no major rewrites, we instead build some of our new tools and services in Go. Some of these have been phased out, others will live out their lifecycles as is.

I personally really like Go, but I feel like I now have a better understanding of why so many teams stick with c/c++ without even considering adopting Go, Rust or similar.

[actionfromafar]

Python + C. Probably C for the optimized parts.

[Hendrikto]

Why not Go + C then?

[actionfromafar]

I'm not them but it seems they already had Python.

[just6979]

Because why bother if you're keeping the C? Part of the reason for moving to Go was safety by replacing the C, not just to move away from Python. I'd say the mistake was thinking Python programmers would enjoy moving to Go. I've done it, and it was not enjoyable. I wouldn't mind doing just the tight peformance things in Go instead of C... But using Go for the high-level things that Python is great at, and where the performance is not an issue, is just silly.