I think "high level of performance" encompasses a wider range of performance levels than you're thinking.
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.
I completely agree, but the "high speed" claims by go enthusiasts are really tiresome, because the language is not particularly faster then any other that's compiled and has GC.
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
> If you actually needed performance you couldn't use a garbage collected language.
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.
No. There's one that made noise about it, but I personally know more than one other from working on their code. Not going to name anyone because I'm not sure they want their tech decisions publicized.
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.
Many companies did this in the past. Nowadays Java, Go, etc GCed languages are still used but not for the hot path anymore. They are a couple million times slower than what we need.
Compared to Python, Ruby and Javascript, Golang is high performance. Compared to C, C++ or assembly language, you sacrifice ergonomics for a bit more performance.
GC is actually a hard requirement for some problem domains such as anything making heavy use of general graphs. (One well-known example of that is GOFAI applications, which are commonly implemented in LISP.)
> GC is actually a hard requirement for some problem domains such as anything making heavy use of general graphs.
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.
There is no implication that memory is not being reused. You seem to be assuming how graphs are represented in large-scale systems which are not actually correct in practice.
Golang isn't really faster then any other on the same playing field (compiled and with GC).