Very much matches my experience with the last ~2.5 years of Rust. One of the really eye-opening ones for me was building a UI library on win32 and watching it just work on Linux, OSX, Android and WASM(with some Canvas work). Obviously each platform took some work to build out their respective rendering primitives but the core engine(including embedding Lua via gcc crate) just worked. As someone who's done x-platform…
Reflections on Rust, and the Sand Castle Metaphor
31–40 of 89 posts
Re: Reflections on Rust, and the Sand Castle Metaphor
#32I have a hard time believing that Rust's guarantees make it safer than easier statically typed languages like Java or Go. Rust is hard because it is solving a different problem, memory management without a garbage collector, not because it has the strongest correctness guarantees.
Rust doesn't have the Billion Dollar Mistake, as far as I can tell. That alone makes it safer than Java.
Re: Reflections on Rust, and the Sand Castle Metaphor
#33I have a hard time believing that Rust's guarantees make it safer than easier statically typed languages like Java or Go. Rust is hard because it is solving a different problem, memory management without a garbage collector, not because it has the strongest correctness guarantees.
Re: Reflections on Rust, and the Sand Castle Metaphor
#34I have a hard time believing that Rust's guarantees make it safer than easier statically typed languages like Java or Go. Rust is hard because it is solving a different problem, memory management without a garbage collector, not because it has the strongest correctness guarantees.
Re: Reflections on Rust, and the Sand Castle Metaphor
#35Earlier quoted context omitted.
> I'd estimate it took me about 10 times longer to implement in Rust than Python. And I don't exactly know Python well - it wasn't just extra time Googling how to do things. That doesn't surprise me at all. Writing it in C++ would probably take me a lot longer than writing it in Python too.
Why is that the comparison point though? How long would it have taken in, say, OCaml or Haskell, which would have given similar correctness guarantees to Rust?
[1] http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan... [2] https://benchmarksgame.alioth.debian.org/u64q/compare.php?la...
Re: Reflections on Rust, and the Sand Castle Metaphor
#36This is not at all specific to rust: OP is just grateful for the compiler to find lots of problems one would have to write tests for in dynamic languages.
For instance C's equivalent of Rust's enum would be tagged unions, however the compiler cannot enforce the semantics of tagged unions and will gladly let you access random members regardless of the tag.
Same story with the borrow checker compared to C's "whatever you say chief" approach to resource management.
Rust is definitely not the only one to offer these guarantees and some languages even go further (such as Idris for instance). The reason Rust stands out is that it can be used basically anywhere you'd use C or C++, something few other languages can claim.
Re: Reflections on Rust, and the Sand Castle Metaphor
#37I have a hard time believing that Rust's guarantees make it safer than easier statically typed languages like Java or Go. Rust is hard because it is solving a different problem, memory management without a garbage collector, not because it has the strongest correctness guarantees.
What Rust gives you over Java is determinism. Having a GC doesn't preclude you from leaking resources(file handles, textures, etc) and you're at the mercy of whenever the finalizer decides to run once the GC has determined it's time to free an object. Usually this manifests as your Java application humming along until you hit some GC threshold cliff and then perf/memory plummets. I also can't enforce ownership in Jav…
Re: Reflections on Rust, and the Sand Castle Metaphor
#38I do think the difficulty of Rust is brushed aside by its proponents. This week I wrote a little script to read an XML file, get a path from it, read a file at that location, do some regexes on it, and then update the XML and write it back to disk. I'd estimate it took me about 10 times longer to implement in Rust than Python. And I don't exactly know Python well - it wasn't just extra time Googling how to do things.…
1. It really helped me to stop trying to force my code to be as pretty as possible the first time around.
2. If you are getting errors about a lifetime not living long enough in a complex expression, it can help to pull some part of it out into a helper let binding.
3. Adding an artificial scope (a curly block in the middle of another block) can be a great way to control the lifetime of a borrow.
4. clone() all the things! This is a major advantage that Rust has over other ball-and-chain languages like Haskell. When you get into a type-tetris situation in Haskell, you just have to find a way out. In Rust you can often just clone() something that you would rather not have to clone() and move on. I love being able to tell the borrow checker to go away while I concentrate on my program logic. Later I can always go back and fix it.
Re: Reflections on Rust, and the Sand Castle Metaphor
#39I do think the difficulty of Rust is brushed aside by its proponents. This week I wrote a little script to read an XML file, get a path from it, read a file at that location, do some regexes on it, and then update the XML and write it back to disk. I'd estimate it took me about 10 times longer to implement in Rust than Python. And I don't exactly know Python well - it wasn't just extra time Googling how to do things.…
Re: Reflections on Rust, and the Sand Castle Metaphor
#40This is not at all specific to rust: OP is just grateful for the compiler to find lots of problems one would have to write tests for in dynamic languages.
It's not even specific to compilers; it's any type-checker. Compilers just happen to include one.