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
Michael Watson Retweeted Jonathan Blow
I read the "Rust is too strict" idea yesterday. I am not even close to being a compiler writer so forgive me, but couldn't we develop using a GC then do a prod build without one and the compiler would show us everywhere we need to start managing memory?https://twitter.com/Jonathan_Blow/status/1194295021609963521 …
Michael Watson added,
Jonathan Blow @Jonathan_BlowI don't mean to only address Rust here, it's just a concrete example of this class of languages. If you let me iterate and experiment, but then also provide me tools with which to ensure my program is correct, but I don't have to pay the costs of this on day one, that's great.Show this thread2 replies 0 retweets 0 likes
Because the memory management scheme fundamentally affects how you write the program. If you try to run a C program through c2rust you’ll see what I mean.
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.