Live data from Hacker News

Reflections on Rust, and the Sand Castle Metaphor

brandur.org

31–40 of 89 posts

Re: Reflections on Rust, and the Sand Castle Metaphor

#31
post #4

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…

I had the same experience with any programing language with a rich set of libraries since the 16 bit days.

Re: Reflections on Rust, and the Sand Castle Metaphor

#32
post #20

I 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.

Eiffel was one of the first languages to fix it.

Re: Reflections on Rust, and the Sand Castle Metaphor

#33
post #20

I 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.

"Having a hard time believing" isn't setting anyone up to care a whole lot about your comment - give it a shot and get some experience with it rather than pontificating.

Re: Reflections on Rust, and the Sand Castle Metaphor

#34
post #20

I 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 iterator invalidation issues or "ConcurrentAccessException" which are very nice for writing highly concurrent code at large scales. Throw in niceties like no null, result types for better error typing, and a culture of correctness and you've got a really nice language for writing correct software. Go and Java are certainly good at writing correct software too, especially compared to python or javascript, but don't offer anywhere near the same guarantees as rust. I would consider myself a Rust fanboy, but I wouldn't hesitate to use Go or Java in many domains, every tool has its niche.

Re: Reflections on Rust, and the Sand Castle Metaphor

#35
post #18

Earlier 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?

Neither OCaml[1] nor Haskell[2] has performance competitive with Rust. It’s impressive how many high-level functional features Rust was able to include, but it’s ultimately a systems language—and it’s unique precisely because it’s a fast systems language that can give the sorts of high-level guarantees usually reserved for GC languages.

[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

#36
post #17

This 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.

I agree with you if we replace "dynamic language" by "not as strongly typed". C is not exactly dynamic but its type system is prehistoric compared to Rust.

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

#37
post #20

I 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…

The comparison I like to make is that Rust is the safer/modern version of C++'s memory model. It's in a different class from most languages, but trying to apply all the latest lessons and techniques.

Re: Reflections on Rust, and the Sand Castle Metaphor

#38
post #5

I 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.…

If that was your first foray into Rust land, I hope you give it another shot. I definitly struggled with fitting into the Rust programming model at first, but a few adjustments to how I code have really helped me. Some particular points which helped me are:

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

#39
post #5

I 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.…

How much experience do you have with Rust? What about C++?

Re: Reflections on Rust, and the Sand Castle Metaphor

#40
post #17

This 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.

Well it's more of a feature of the language really. The type of static type checking provided by Rust would be impossible to achieve in C or Python for instance, unless you add specific annotations to augment the language's type system.
Post reply on HN