Why Rust?
rerun.io
Why Rust?
1–10 of 294 posts
Re: Why Rust?
#2TL;DR — because the author loves it, followed by what can be described as multiple paragraphs of personal preferences.
Re: Why Rust?
#3> Safety and speed
One thing I can't seem to find a quick answer to from the Rust crowed is how does Rust handle dynamic lifetimes? It seems like it does not; it simply prevents you from referring to objects that have a dynamic lifetime not known at compile time.
You either have to use 'unsafe' or use the 'handles' pattern where you have what amounts to a custom allocator but the compiler does not know that it's an allocator so it can't prevent 'use after free' bugs.
I suppose you can also use Rc, but isn't that essentially a garbage collection scheme, with similar performance characteristics? (AFAICT a reference counting scheme must be able to nullify all references to an object when it's deallocated, so deallocations can become arbitrarily expensive).
Am I missing something?
Re: Why Rust?
#4> Safety and speed One thing I can't seem to find a quick answer to from the Rust crowed is how does Rust handle dynamic lifetimes? It seems like it does not; it simply prevents you from referring to objects that have a dynamic lifetime not known at compile time. You either have to use 'unsafe' or use the 'handles' pattern where you have what amounts to a custom allocator but the compiler does not know that it's an a…
> dynamic lifetimes
What do you mean ?
If you refer to heap allocations, then you can use Box, Arc, Rc. They are not a "garbage collector" nor do they incur performance hits other than a regular heap allocation.
Re: Why Rust?
#5TL;DR — because the author loves it, followed by what can be described as multiple paragraphs of personal preferences.
Retrospectively you might be right.
The majority of software is slow and not safe to use and the majority of people do it anyway.
Re: Why Rust?
#6TL;DR — because the author loves it, followed by what can be described as multiple paragraphs of personal preferences.
They seem pretty universal to me. For example, the tedious error handling in Go that is mentioned is a turn-off to a lot of developers. Safety and speed are both things most languages strive for, and if Rust is not THE fastest or THE safest language, it’s on the efficient frontier of the two.
Re: Why Rust?
#7TL;DR — because the author loves it, followed by what can be described as multiple paragraphs of personal preferences.
Retrospectively you might be right. The majority of software is slow and not safe to use and the majority of people do it anyway.
The majority of things in general is not safe to use, and yet somehow we do it anyway, and thrive.
Re: Why Rust?
#8> Safety and speed One thing I can't seem to find a quick answer to from the Rust crowed is how does Rust handle dynamic lifetimes? It seems like it does not; it simply prevents you from referring to objects that have a dynamic lifetime not known at compile time. You either have to use 'unsafe' or use the 'handles' pattern where you have what amounts to a custom allocator but the compiler does not know that it's an a…
> AFAICT a reference counting scheme must be able to nullify all references to an object when it's deallocated, so deallocations can become arbitrarily expensive
The idea of reference-counted object is that by the time it's deallocated there _are_ no references left to update. Now you might reasonably be asking about the memory left behind by those old references which contain now-invalid pointers. The use-after-free risks of any single given reference to the object is something the Rust compiler can reason about quite easily. Once you drop one of them (and the refcount decrements) you are guaranteed not to be able to get at that pointer again; not until that memory is reinitialised with something else valid.
Re: Why Rust?
#9This must be how people felt about C++ in the beginning ...
Re: Why Rust?
#10> Rust's enums and exhaustive match statement are just amazing, and now that I'm using them daily I can barely imagine how I could live without them for so long.
I feel this! I absolutely love rust's fancy enums - i.e. not just a set of constants, but where each variant can be a full fledged type of its own, and how you have to handle every case whenever you're matching on it. It dovetails absolutely wonderfully with non-nullability and errors as values. This is probably the main nice-to-have in a language for me. Unfortunately, I don't really work in a low-level domain so I'm not sure the extra complexity of manually managing memory is worth it to me.
Do any other higher-level languages have rust-style enums with exhaustiveness checking? I only know of Haskell and Ocaml. Actually, I suppose TypeScript has something kind of similar.