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.
