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.
-
-
Show 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.
Show this thread
End of conversation
New conversation -
-
-
A little thing: Global constants should not require upper case names.
-
You can turn that warning off, though?
- 2 more replies
New conversation -
-
-
I think it’s also too... idealistic (or honestly, naive) to how a huge chunk of development happens. If I had a cent for every ‘oh i just hacked this up quickly, this isn’t meant for production’...
-
... I'd be able to pay for the cleanup of all the hacked together prototypes that ended up in production.
End of conversation
New conversation -
-
-
Finding the strictness enlightening.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
during a big non-incremental refactoring it can be impossible to test runtime logic before fixing everything, rustc could make this possible by replacing e.g. functions that don't compile with panicking stubs; maybe these binaries could be made undeployable by adding time bombs
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
Rust is criticized for being too strict? Wasn’t this exactly its liberating selling point? No more impossible mental overhead.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
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.