Live data from Hacker News

Reflections on Rust, and the Sand Castle Metaphor

brandur.org

41–50 of 89 posts

Re: Reflections on Rust, and the Sand Castle Metaphor

#41
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.…

> I wish there were a simpler language, like Rust (no garbage collector, no runtime), but that was a little more helpful and willing to do implicit things even if they are slightly slower than the most optimised code possible.

The fiddling with borrows isn't about being as optimised as possible, it's about being correct in the absence of garbage collection. Are you sure you need no GC and no runtime? Tasks like the script you describe sound like a perfect fit for something like OCaml.

Re: Reflections on Rust, and the Sand Castle Metaphor

#42
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?

Because Rust and C++ have similar domains.

Re: Reflections on Rust, and the Sand Castle Metaphor

#43
post #7
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 have the same experiences with Go regarding xplat. I was particularly amazed that I could trivially cross compile by simply setting the GOOS and GOARCH env vars to the correct operating system and CPU architecture and then running `go build`. EDIT: Curious why people are downvoting this. Is it really so taboo to suggest that Go could be nearly as pleasant as Rust at something? Do I really need to roll out my Rust f…

I upvoted you, but perhaps bringing up Go (or Nim, etc.) In every Rust thread is as annoying as bringing up Rust in every Go thread.

This article is about comparing languages more or less, though.

Re: Reflections on Rust, and the Sand Castle Metaphor

#44
post #6

This is indeed very light in content. Also, while Rust fixes a whole set of problems, it doesn't mean that Rust fixes all possible problems. It is relatively easy to create a situation where you overflow your program. See here: https://github.com/rust-lang/rust/issues/50049 Googling around, there are many situations where bad code can lead to an overflow and your code breaking.

This is the equivelent of `~Foo() { Foo f; }` isn't it?

Re: Reflections on Rust, and the Sand Castle Metaphor

#45
post #18

Earlier quoted context omitted.

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?

Because Rust is a systems language?

What does that cash out as that the programmer cares about though? A task like "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" doesn't need any special systems-ness (and maybe Rust is only a suitable choice for problems where you need that systems-ness, but people seem to be writing a lot of ordinary code in it and advertising it for non-systems uses).

Re: Reflections on Rust, and the Sand Castle Metaphor

#46

Earlier quoted context omitted.

Who, ever, anywhere, has claimed that "Rust fixes all possible problems"? This is a straw man. As for bad code leading to overflows and crashes: yes, bad code causes overflows and crashes, definitionally. Rust does not, and has never claimed to protect against logic errors in this way. How could it?

The language in the article is very strong. > Rust is another step into the beyond. When finishing a feature and its test suite I’ll run my program to see it in action, but just as a formality – I already know it works. I also know that it’s going to keep working because meticulousness of the compiler is so good at catching regressions.

This is a bold statement, specially because not many other languages have such high quality guarantees at compile time.

> I already know it works

This is the part I don't agree all of the time, but depending on the scope and size of the project, I've seeing this be true. And the compiler is really good at catching regressions, submitting PRs for Rust projects is not easy in the beginning, but it is very hard to insert a regression.

Re: Reflections on Rust, and the Sand Castle Metaphor

#47
post #6

This is indeed very light in content. Also, while Rust fixes a whole set of problems, it doesn't mean that Rust fixes all possible problems. It is relatively easy to create a situation where you overflow your program. See here: https://github.com/rust-lang/rust/issues/50049 Googling around, there are many situations where bad code can lead to an overflow and your code breaking.

The same author wrote a Rust article filled with a lot of great content: https://brandur.org/rust-web

Re: Reflections on Rust, and the Sand Castle Metaphor

#48
post #35
post #18

Earlier quoted context omitted.

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://b…

Depends what you're competing on. IIRC (can't view your link) OCaml/Haskell performance is much closer to Rust than it is to Python (runtime tends to like x for rust, 2x-5x for OCaml/Haskell, and 70x or more for Python) - if IshKebab's starting point was "my Python script is too slow, I need something an order of magnitude faster" then OCaml/Haskell would be competitive with Rust in that space.

Re: Reflections on Rust, and the Sand Castle Metaphor

#49

Earlier quoted context omitted.

> I do think the difficulty of Rust is brushed aside by its proponent. Then how do you explain the constant push for "more ergonomics"?

I think that was more a comment on people who go "It seemed hard at first, but after a week it was totally natural and I hardly ever even think about the borrow checker anymore." Which has not been my experience.

Neither it has been mine. I have written C and C++ only in college, so my impression might be very wrong, but I think that programmers who are proficient in low level languages are the ones that learn Rust the fastest due to the low level concepts Rust's compiler puts upfront such as sane memory management.

Re: Reflections on Rust, and the Sand Castle Metaphor

#50
post #43
post #7

Earlier quoted context omitted.

I have the same experiences with Go regarding xplat. I was particularly amazed that I could trivially cross compile by simply setting the GOOS and GOARCH env vars to the correct operating system and CPU architecture and then running `go build`. EDIT: Curious why people are downvoting this. Is it really so taboo to suggest that Go could be nearly as pleasant as Rust at something? Do I really need to roll out my Rust f…

I upvoted you, but perhaps bringing up Go (or Nim, etc.) In every Rust thread is as annoying as bringing up Rust in every Go thread. This article is about comparing languages more or less, though.

Thanks; I used Go because it was specifically referenced in the article. I don’t personally mind people bringing up Rust in Go threads; I do mind pretending there aren’t trade offs, however.
Post reply on HN