Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reflections on Rust, and the Sand Castle Metaphor

brandur.org

Post reply on HN
Print view View original

21–30 of 89 posts

Re: Reflections on Rust, and the Sand Castle Metaphor

#21

Post by mpweiher »

vvanders wrote: 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…

Hmm..I had the same experience with Objective-C. First on NeXTStep, later with GNUStep. And durability is pretty good, too. I am currently using code I wrote back in the late 90s. Whereas all of Apple's Swift sample code I tried (about non-Swift-specific features such as Apple pencil) would no longer compile.

And of course Smalltalk images can be saved on one platform and restarted on another, but that's with a VM.

Re: Reflections on Rust, and the Sand Castle Metaphor

#22

Post by yarrel »

urschrei wrote: post #14
csomar wrote: 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.

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?

I've had conversations with enthusiasts who are incorrectly convinced that ownership/borrowing fixes problem X.

Trying to explain otherwise to them is an exercise in futility. Because ownership/borrowing.

So serious Rust project members may never claim this, but there is a large less widely experienced Rust community who have turned the claims Rust does make into something much stronger and more resistant to logic.

Re: Reflections on Rust, and the Sand Castle Metaphor

#23

Post by icebraining »

jlg23 wrote: 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.

Re: Reflections on Rust, and the Sand Castle Metaphor

#24

Post by jandrese »

majewsky wrote: post #19
IshKebab wrote: 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 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.

Re: Reflections on Rust, and the Sand Castle Metaphor

#25

Post by vvanders »

guelo wrote: 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 Java which drives me up the wall. Once you hand out a ref anything is fair game and calling code is free to add that ref to the root GC set so that it never gets freed.

Re: Reflections on Rust, and the Sand Castle Metaphor

#26

Post by weberc2 »

vvanders wrote: post #13
weberc2 wrote: 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…

https://crates.io/crates/gcc is even more amazing, it will cross-compile your C dependencies(assuming you have the right compilers setup, which is mostly handled already via rustup or base install). For Android all I had to do was point it to the NDK(for both Rust and the crate) and I got all my C dependencies for basically free. Anyone who's had to work with the NDK knows how nice that is. That's also with zero chan…

> it will cross-compile your C dependencies

That's really cool indeed! Rust's build tooling is truly world class.

Re: Reflections on Rust, and the Sand Castle Metaphor

#27

Post by kadenshep »

lmm wrote: post #18
xboxnolifes wrote: post #8

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 is a systems language?

Re: Reflections on Rust, and the Sand Castle Metaphor

#28

Post by icebraining »

guelo wrote: 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.

Re: Reflections on Rust, and the Sand Castle Metaphor

#29

Post by Skunkleton »

lmm wrote: post #18
xboxnolifes wrote: post #8

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?

I can't imagine a new OCaml or Haskell programmer getting this done faster than a novice Python programmer.

Personally, I don't think this is even an interesting metric. These are tools for experts, understanding expert experiences is more interesting.

Re: Reflections on Rust, and the Sand Castle Metaphor

#30

Post by titanix2 »

guelo wrote: 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.

Especially since some byte-code languages such as OCaml or C# can be compiled to native code instead of targeting a VM, the number of cases where writing such manual memory by hand make sense doesn't seem very large.
Post reply on HN