If you actually needed performance you couldn't use a garbage collected language.
Golang isn't really faster then any other on the same playing field (compiled and with GC).
Golang isn't really faster then any other on the same playing field (compiled and with GC).
Go will be more than fine for the vast majority of servers people need to build. Sure, there are some things where Go might not fit the bill, but that doesn't really matter; Go is still super relevant for writing servers, just as Java (another GC'd language that some people call "slow") is too.
There are very few languages which are categorically slower then Golang, and these are generally languages which explicitly accepted slow executions for ergonomic reasons such as ruby and python
This is incorrect; HFT platforms have been written in Java for example (https://news.ycombinator.com/item?id=24895395). But it's about either tweaking GC settings or mode, or avoiding using the heap entirely if you can.
Go is still slow if you (over)use the heap, but at least it gives you the choice and plenty of tooling to analyze it.
I really like the arena libraries you can use in Rust where you can have logic to free untouchable memory at a specific time.
Also some performance-sensitive chunks of wall street itself (depending on how you define "wall street itself". And "performance sensitive" (what I worked on was more "high throughput" than "no pauses".).) run on java.
TBF, I write a lot of java, so my perspective is probably biased, but I can assure you, it's out there.
js actually beats Golang on most metrics if you're aiming for synthetic "web" performances.
This is manifestly false. I used to write general graph analysis kernels on supercomputers. We used (old-style) C++ and never had an issue with memory management. Your assertion is assuming a naive implementation that would have offered poor performance regardless.