3 ms·

One important thing is that Rust is an expressive language that's pleasant to use, unlike Go :) that would explain why many side projects that could be in Go ar

by forty 3y ago

One important thing is that Rust is an expressive language that's pleasant to use, unlike Go :) that would explain why many side projects that could be in Go are actually in Rust even if they could have been done efficiently in Go too.

tombert 3y ago
Fair! I actually kind of like Go but it's not a language I reach for very often. Still, the point I was making is that it's possible to have garbage collectors that get very low pause times (sub millisecond in Go's case [1]). It might still be an issue for a kernel or microcontroller, I'm not suggesting we always use a GC for every project, I don't think most people would, but I am suggesting that there are a lot of projects (most projects?) that would be better off using a low-latency GC instead of trying to handle memory directly. Even the JVM is getting better about this; there's already experimental support for a low-latency GC in some distributions of OpenJDK [2], which reportedly gets sub-millisecond pauses as well. If you have JVM support then you have access to good languages like Clojure. Personally, I actually think I'm reasonably-ok with manually managing memory, I've cut my teeth on enough C to write code that doesn't generally crash, but I still reach for a garbage collector whenever possible. Just because I think I'm capable of doing manual memory management doesn't mean that I think it's worth it for most things; nearly everything I do touches a network at some point, which means that avoiding latency is not really possible a lot of the time. [1] https://groups.google.com/g/golang-dev/c/Ab1sFeoZg_8 https://groups.google.com/g/golang-dev/c/Ab1sFeoZg_8 [2] https://wiki.openjdk.org/display/shenandoah/Main https://wiki.openjdk.org/display/shenandoah/Main
- pebal 3y ago
  You can have completely concurrent GC, without pausing threads. https://github.com/pebal/sgcl https://github.com/pebal/sgcl
  - tombert 3y ago
    I have not heard of this, but this looks really cool! Forgive some ignorance on this, but does this mean you have literally zero millisecond pause times? What kind of additional overhead/throughput does this incur? This just seems like the holy grail!
    - pebal 3y ago
      This GC operates with zero pause time. The GC runs on a separate thread, so can reduce memory bandwidth if the GC experiences heavy load.
- pjmlp 3y ago
  Java has had real time GC for decades, it isn't available as free beer, rather in commercial JDKs for real time OSes and bare metal deployments. See PTC and Aicas, the two main vendors still in business. And even if I am not a big Go fan, TinyGo and TamaGo show what is possible regarding using Go for bare metal deployments, OS like.
  - tombert 3y ago
    I should have thought about the bare metal JVM deployments. I guess we’re all victims of our careers; 99% of what I do is server-ey and as a result I sometimes forget that there’s a whole bunch of other types of software.
bsaul 3y ago
This may not be the best article to state that rust is more pleasant to use than Go… Op shows cryptic code nesting generic container with various static and dynamic behavior related to memory… This is definitely something i don’t miss having in my go codebase.
- forty 3y ago
  Indeed :) but for many use cases, I find it fun and elegant
pjmlp 3y ago
They could have used OCaml, Haskel, F#, Scala (Scala/Native), Kotlin (Kotli/Native), Common Lisp, C#, D... It isn't for lack of alternatives with nice type systems, automatic memory management and AOT tooling.
- forty 3y ago
  Yes, agreed. Having standalone native binary could also be one of the goal (yes the /native options works too) Personally I like Scala a lot, and I used it quite a lot as a hobby for 10+ years, but my impression is that it's dying (or dead) so I'm not really motivated to play with it anymore. Kotlin always felt to me like a subpar Scala, so I never enjoyed it. There is something about Rust that makes me feel it's a smart language and make me enjoy writing it (most of the time at least, it can absolutely be frustrating at times too). But it's certainly a matter of taste before all.

by forty 3y ago

tombert 3y ago

Fair! I actually kind of like Go but it's not a language I reach for very often. Still, the point I was making is that it's possible to have garbage collectors that get very low pause times (sub millisecond in Go's case [1]). It might still be an issue for a kernel or microcontroller, I'm not suggesting we always use a GC for every project, I don't think most people would, but I am suggesting that there are a lot of projects (most projects?) that would be better off using a low-latency GC instead of trying to handle memory directly. Even the JVM is getting better about this; there's already experimental support for a low-latency GC in some distributions of OpenJDK [2], which reportedly gets sub-millisecond pauses as well. If you have JVM support then you have access to good languages like Clojure. Personally, I actually think I'm reasonably-ok with manually managing memory, I've cut my teeth on enough C to write code that doesn't generally crash, but I still reach for a garbage collector whenever possible. Just because I think I'm capable of doing manual memory management doesn't mean that I think it's worth it for most things; nearly everything I do touches a network at some point, which means that avoiding latency is not really possible a lot of the time. [1] https://groups.google.com/g/golang-dev/c/Ab1sFeoZg_8 https://groups.google.com/g/golang-dev/c/Ab1sFeoZg_8 [2] https://wiki.openjdk.org/display/shenandoah/Main https://wiki.openjdk.org/display/shenandoah/Main

pebal 3y ago
You can have completely concurrent GC, without pausing threads. https://github.com/pebal/sgcl https://github.com/pebal/sgcl
- tombert 3y ago
  I have not heard of this, but this looks really cool! Forgive some ignorance on this, but does this mean you have literally zero millisecond pause times? What kind of additional overhead/throughput does this incur? This just seems like the holy grail!
  - pebal 3y ago
    This GC operates with zero pause time. The GC runs on a separate thread, so can reduce memory bandwidth if the GC experiences heavy load.
pjmlp 3y ago
Java has had real time GC for decades, it isn't available as free beer, rather in commercial JDKs for real time OSes and bare metal deployments. See PTC and Aicas, the two main vendors still in business. And even if I am not a big Go fan, TinyGo and TamaGo show what is possible regarding using Go for bare metal deployments, OS like.
- tombert 3y ago
  I should have thought about the bare metal JVM deployments. I guess we’re all victims of our careers; 99% of what I do is server-ey and as a result I sometimes forget that there’s a whole bunch of other types of software.

bsaul 3y ago

This may not be the best article to state that rust is more pleasant to use than Go… Op shows cryptic code nesting generic container with various static and dynamic behavior related to memory… This is definitely something i don’t miss having in my go codebase.

forty 3y ago
Indeed :) but for many use cases, I find it fun and elegant

pjmlp 3y ago

They could have used OCaml, Haskel, F#, Scala (Scala/Native), Kotlin (Kotli/Native), Common Lisp, C#, D... It isn't for lack of alternatives with nice type systems, automatic memory management and AOT tooling.

forty 3y ago
Yes, agreed. Having standalone native binary could also be one of the goal (yes the /native options works too) Personally I like Scala a lot, and I used it quite a lot as a hobby for 10+ years, but my impression is that it's dying (or dead) so I'm not really motivated to play with it anymore. Kotlin always felt to me like a subpar Scala, so I never enjoyed it. There is something about Rust that makes me feel it's a smart language and make me enjoy writing it (most of the time at least, it can absolutely be frustrating at times too). But it's certainly a matter of taste before all.