Re:Web Development in Go
by jerf on Monday April 10, 2017 @04:44PM
(#14082368)
For C/C++, don't use a memory-unsafe language to speak to networks. (The fact that so many things already do is no excuse and adequate demonstration of why. Also arguably more true of C than C++ but I'm not particularly impressed with claims that C++ is safe if you just "do it right" because that's the sort of gap you can drive a truck through.) Rust is still a bit shy of web libraries, and may be overkill for some use cases, but otherwise, go for it. Go for it with Java too.
However, the performance gap between Go and Rust is much smaller than the gap between Go and a dynamically-typed language, even one JIT'ed to the n'th degree, and the gap between Go and Java generally lost in the noise [1]. Between Go, Java, and Rust, you've probably got a good case that you'll get to more-or-less production-ready code fastest in Go. (And yes, "more-or-less" is a gap big enough to drive a truck through too. I preemptively pretty much agree with everything anybody might care to write about that issue in reply. :) )
[1]: I suppose I should point out that a perf gap of 2 or 3 is "generally lost in the noise". In the real world what tends to control which such language has the better implementation of something for most tasks is who has taken more time to write an optimized version. It's when you start getting up to the 10x-25x range that the gap between Go and a dynamic language can be that it's not really "lost in the noise" anymore; in that case, the faster language can end up simply faster than the slow language even if the slow language is given a lot of extra love (assuming no "change to a different language" shenanigans).
However, the performance gap between Go and Rust is much smaller than the gap between Go and a dynamically-typed language, even one JIT'ed to the n'th degree, and the gap between Go and Java generally lost in the noise [1]. Between Go, Java, and Rust, you've probably got a good case that you'll get to more-or-less production-ready code fastest in Go. (And yes, "more-or-less" is a gap big enough to drive a truck through too. I preemptively pretty much agree with everything anybody might care to write about that issue in reply. :) )
[1]: I suppose I should point out that a perf gap of 2 or 3 is "generally lost in the noise". In the real world what tends to control which such language has the better implementation of something for most tasks is who has taken more time to write an optimized version. It's when you start getting up to the 10x-25x range that the gap between Go and a dynamic language can be that it's not really "lost in the noise" anymore; in that case, the faster language can end up simply faster than the slow language even if the slow language is given a lot of extra love (assuming no "change to a different language" shenanigans).