It’s really easy to criticize Rust for being too “strict”. It’s a lot harder to say what specific changes you’d make to make it less strict during development, while still allowing safety during deployment.
-
Show this thread
-
If your answer to “Rust is too strict during development” is “throw out safety during both development *and* deployment”, that’s a bait and switch.
3 replies 0 retweets 27 likesShow this thread -
Memory safety with no GC (while still allowing dynamic allocation) is really hard. I’m skeptical it’s possible to do much better than Rust. Only alternative I’ve seen is trying to tame use-after-free; e.g. memory tagging schemes. With careful PL design it *might* be safe enough.
5 replies 0 retweets 20 likesShow this thread -
Replying to @pcwalton
rust has "unnecessary" strictness from pursuing aesthetic goals like being able to "see what code does" / "see expensive operations" / "control everything". swift goes too far, but still demonstrates real rust-relevant conveniences (lifetimes really complicate things though)
2 replies 0 retweets 10 likes
I think in practice when people talk about Rust strictness they’re 90% referring to lifetimes and the &/&mut restrictions. You’re definitely right that the strict-by-default philosophy pervades the entire language, though.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.