If you use any dynamic memory strict latency is very very difficult in any language/platform. I’m not really sure how a platform like Discord has strict latency requirements - it’s not as if the ‘read badge’ not updating is going to crash the plane.
As an example a lot of auto systems use Java - it can be done. I’ll repeat... the problem they had with Go is due to the lack of a generational collector. They would not have that problem in today’s Java. Please take Discord switching with a grain of salt - they didn’t really understand the cause of their problem in the first place - they will create others and wrongly switch to something else :) > On Feb 9, 2020, at 9:06 AM, David Riley <fraveyd...@gmail.com> wrote: > > On Feb 7, 2020, at 7:24 AM, Everton Marques <everton.marq...@gmail.com> > wrote: >> >> I think Go is way better than Rust, but it is amusing to see why people pick >> one over another. > > I think they have very different use cases. Rust is fundamentally a > functional language, which suits it quite well for things functional > languages excel at (which definitely includes most server functionality). Go > is a mostly-imperative language, which makes it excellent for general purpose > (and it does pretty well at server-oriented stuff as well). Rust also has > some concrete safety benefits over Go, largely down to the compile-time > dataflow analysis that prevents a lot more hazards like data races, to which > I've found Go is still quite susceptible. > > There's been a lot of talk here about the effect of GC, and I think that's > accurate, but it's worth noting that Go's GC is designed to make *initial* > allocations very fast, which actually can give it a significant edge over > many non-GC languages if they haven't come up with an allocator optimized for > low latency (this is very popular in C/C++ game development because malloc() > is not usually fast). > > Correspondingly, the rather heavy requirements for the Go runtime make it a > lot less practical for small embedded use cases (though not impossible, as > recent list traffic indicates). If I were building a small (think <=256k > RAM) embedded system these days, I'd probably go with Rust, largely because > I've come to recognize that the undefined behavior in C/C++ makes writing > definitively safe code impossible. > > As always, use the tool appropriate for your use case, otherwise you get > Perl's "when all you have is scissors, everything looks like a nail" problem. > There are appropriate use cases for Forth. Language "quality" is a vector > quantity, and trying to reduce it to a scalar does everyone involved a > disservice. > > That said, if I were to describe my ideal language for modern PCs and/or > servers, it would probably be "Rust, but more stable, with channels and > Goroutines", so I am somewhat biased. Maybe someone can make an LLVM target > or something for the Go runtime that makes something like that possible, but > I sure don't have the time. > > > - Dave > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/2A183438-E5DE-41DE-B464-78C2176F584D%40gmail.com. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/55B31021-4600-453E-92B9-BABB67F1282A%40ix.netcom.com.
