[go-nuts] Re: Why Discord is switching from Go to Rust
They have very strict latency requirements. So they can't use a language with a GC. That's fine, no language is totally universal. You have to pick the right tool for the job. Aside from that it would be nice if that 2-minutes GC trigger, that is mentioned in the text, could be removed or lessened. Reminds me a bit of Oberon where the GC is triggered on every 20th mouse move. That was a smart "trick" back then, because Wirth and Gutknecht had only very little time to develop Oberon. Developing an algorithm that finds out when to trigger the GC is said to be very challenging and thus they saved the time for that and made the development of Oberon still possible (I would say Go is very much in a similar mindset than Oberon). Am Freitag, 7. Februar 2020 13:24:50 UTC+1 schrieb Everton Marques: > > I think Go is way better than Rust, but it is amusing to see why people > pick one over another. > > "Remarkably, we had only put very basic thought into optimization as the > Rust version was written. Even with just basic optimization, Rust was able > to outperform the hyper hand-tuned Go version. This is a huge testament to > how easy it is to write efficient programs with Rust compared to the deep > dive we had to do with Go." > > > https://blog.discordapp.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f > > -- 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/f0ed8e8a-60cd-4eee-b8b3-ee3f17f903f4%40googlegroups.com.
Re: [go-nuts] Why Discord is switching from Go to Rust
On Feb 7, 2020, at 7:24 AM, Everton Marques 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.
Re: [go-nuts] Why Discord is switching from Go to Rust
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 wrote: > > On Feb 7, 2020, at 7:24 AM, Everton Marques > 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.
[go-nuts] Go-1.14 irreproducibly fails with mlock failure
The first time I ran go-1.14rc1 on a stock Debian system, I got: runtime: mlock of signal stack failed: 12 runtime: increase the mlock limit (ulimit -l) or runtime: update your kernel to 5.3.15+, 5.4.2+, or 5.5+ fatal error: mlock failed ulimit -l is at 64, which is also the hard limit. After opening a new shell, I can no longer reproduce the issue -- everything appears to be working fine. Still, I find this heisenbug somewhat disturbing. -- Juliusz -- 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/87o8u7zjfl.wl-jch%40irif.fr.
[go-nuts] Proposed additions to maphash documentation
It would be helpful if the introduction to the maphash package immediately stated that it produces 64-bit values, and perhaps restate the fact that the value can be safely reduced using bit masking (already there at the Sum64 method). I'm not sure what is the purpose of the BlockSize method -- why is the block size relevant to the package user? At the very least, the doc should mention that Size is the value that the user wants. -- Juliusz -- 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/87mu9rzj98.wl-jch%40irif.fr.
Re: [go-nuts] Proposed additions to maphash documentation
That last question I can answer: https://golang.org/pkg/hash/#Hash Implementing that interface requires this method. On Sun, Feb 9, 2020 at 7:52 PM Juliusz Chroboczek wrote: > It would be helpful if the introduction to the maphash package immediately > stated that it produces 64-bit values, and perhaps restate the fact that > the value can be safely reduced using bit masking (already there at the > Sum64 method). > > I'm not sure what is the purpose of the BlockSize method -- why is the > block size relevant to the package user? At the very least, the doc > should mention that Size is the value that the user wants. > > -- Juliusz > > -- > 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/87mu9rzj98.wl-jch%40irif.fr. > -- 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/CAEkBMfE596xKrjazUFJTzxCp4%2B-rxUowp9qVRUEyKpMPvKd%2BgA%40mail.gmail.com.
