3 ms·
The article felt kind of disjointed, I think that statement was just meant generally and not meant to suggest it applies here
by brundolf 4y ago
The article felt kind of disjointed, I think that statement was just meant generally and not meant to suggest it applies here
- masklinn 4y agoAlso how I interpreted it, though even there it's quite weird (e.g. better performances is also a common reason to convert things to Rust, especially when "easy binding" tools like pyo3, neon, or rustler are available and take care of the unsafe bits between the two).
- tialaramex 4y agoOn the other hand, performance isn't a unique thing Rust brings to the party, C or C++ both have attractive performance in the same ballpark. So if the question is "Why Rust specifically?" rather than e.g. "Couldn't I technically use an awk script?" then safety is a better argument than performance. Rather than memory safety per se, I'd actually value Rust's type safety over Python's. Yes, strictly speaking Python is dynamically typed rather than untyped, but Rust will shift a lot of your mistakes "hard left" (ie report your goof during compilation not during execution) compared to Python because it gets to do these checks up front, and it is also able to catch a lot more of them because it's much stricter about what types are. In Python we can write "if foo" and it doesn't matter too much what type foo actually has, Python will try to decide if it's "truthy" at runtime. In Rust either foo is a boolean, in which case this is a reasonable thing to do, or it isn't, that's a type mismatch, your program doesn't compile. Not everyone loves this, but I certainly do.
- UncleEntity 4y agoYeah… It’s becoming a pet peeve that the Rustafarians believe they have a monopoly on “memory safety” and need to point it out all the time.
- shaunsingh 4y agoIts worth pointing out because rust has a monopoly on easy-to-write gc-less memory safety, with the alternatives being modern c++ or higher level languages where you run into a garbage collector
- tialaramex 4y agoEven with garbage collection, check the fine print. Most of those languages aren't memory safe when multi-threaded, you can race a complicated data structure so that its state becomes inconsistent and now everything is on fire, so if the garbage collector comes along that just catches fire too.
- moosedev 4y agoDo you have any specific examples of this (or the fine print that implies it) for Rust? (Not sealioning[0], genuinely interested!) [0] https://www.merriam-webster.com/words-at-play/sealioning-internet-trolling#:~:text=Sealioning%20refers%20to%20the%20disingenuous,questions%20of%20the%20other%20commenter https://www.merriam-webster.com/words-at-play/sealioning-int.... Edit: Just realized you said "even with garbage collection", so you weren't talking about Rust. Never mind.
- tialaramex 4y agoThat's actually an entirely reasonable question, Rust's memory model is scarcely as well nailed down as the Java Memory Model (which is a GC model that does promise memory safety under concurrency and is worth reading about if you'd like to see how much thought is needed). https://jcp.org/aboutJava/communityprocess/final/jsr133/index.html https://jcp.org/aboutJava/communityprocess/final/jsr133/inde... (section 17.4 of the full specification) However in a sense Rust is cheating. Java has to do a lot of work because they can't stop you writing a data race in Java, so they want that to be safe anyway if it happens. (Safe) Rust just won't emit the data race in the first place. A data race requires (as mentioned below in the thread about Python concurrency) that there's mutation concurrently with access to the same memory. In Java that's a bad idea, but it does happen, usually by mistake. In (Safe) Rust mutation requires that nobody else has a shared (immutable) reference to the object, so the data race can't occur because if we can mutate something by definition nobody else has a reference to it - programs with this mistake won't compile.