Reflections on Rust, and the Sand Castle Metaphor • Hacker News Board

Re: Reflections on Rust, and the Sand Castle Metaphor

#81

Post by pjmlp » Sat, Apr 28, 2018, 2:13 PM UTC

stirner wrote: post #76

pjmlp wrote: post #75

Earlier quoted context omitted.

If I have a budget of 300ms and 100MB, am able to deliver it within 150ms and 30MB, why should I spend more money to make it lets say 50ms and 10MB?

There are many reasons why you might use a systems programming language [1]. > System programming requires a great degree of hardware awareness. Its goal is to achieve efficient use of available resources, either because the software itself is performance critical (AAA video games) or because even small efficiency improvements directly transform into significant monetary savings for the service provider (cloud based…

A few languages do support such low-level controls to have such fine grain memory control outside GC hands.

So the question is, having been able to achieve half of the allowed budget, why pay for more development effort?

Of course, if the bugdet is only achievable with a lower level language, there is no way around using it.

Re: Reflections on Rust, and the Sand Castle Metaphor

#82

Post by MrBuddyCasino » Sat, Apr 28, 2018, 5:17 PM UTC

epage wrote: post #56

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

> A lot of it is just how restrictive the borrow checker is. Often you have to structure your code in a really weird way to satisfy it. I've rarely found this the case for me but I came from C++ and am generally used to thinking in terms of lifetimes. Could you elaborate on how you ran into problems with borrows messing up code structure? > Dealing with strings is another pain point. I get why there is `&str` and `St…

That sounds like a good idea! Having a gateway drug helps.

Re: Reflections on Rust, and the Sand Castle Metaphor

#83

Post by dbaupp » Sun, Apr 29, 2018, 11:50 AM UTC

eeZah7Ux wrote: post #80

dbaupp wrote: post #78

Earlier quoted context omitted.

... While your history comments can be interesting, not every comment about a feature of Rust needs a "rebuttal" about how it wasn't the first language with that feature. Especially not a comment that wasn't even mildly suggesting that Rust was the first language to not have null pointers/references! The comparison here was to "easier statically typed languages" (likely with an implicit "that one is likely to conside…

> not every comment about a feature of Rust needs a "rebuttal" about how it wasn't the first language with that feature. People keep repeating that the popular language/framework/library of the year has $feature without acknowledging that it's not a new idea. This creates hype.

I think my comment explicitly addressed why that general (and fair: I really hate credit-stealing) concern doesn't apply here.

Re: Reflections on Rust, and the Sand Castle Metaphor

#84

Post by lmm » Sun, Apr 29, 2018, 7:52 PM UTC

kadenshep wrote: post #57

lmm wrote: post #45

Earlier quoted context omitted.

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

Because C/C++ are systems languages. You can use a hammer for whatever you like, that doesn't make it the right tool for the job. If you want ease of implementation then I'd reckon you don't need Rust. Rust is for correctness and speed. This is why the comparison was made in the first place. To address the heart of what you're getting at: I don't buy the fact that it took "10x" longer to read an XML file. I'll give y…

> If you want ease of implementation then I'd reckon you don't need Rust. Rust is for correctness and speed. This is why the comparison was made in the first place.

I'd take the view that "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" doesn't need any more speed than Python, but can benefit from more correctness. I'm willing to spend a bit more implementation time than Python to get more safety than Python, but I'm not willing to spend extra time just to make it faster (and frankly I'd question the priorities of someone who would). If implementing in Rust is slower than a more error-prone language, that's not necessarily a mark against it - but if I can implement faster than Rust in a language that would also have similar safety properties then I'd rather do that, even if it meant somewhat slower runtime performance.

Re: Reflections on Rust, and the Sand Castle Metaphor

#85

Post by kadenshep » Sun, Apr 29, 2018, 9:44 PM UTC

lmm wrote: post #84

kadenshep wrote: post #57

Earlier quoted context omitted.

Because C/C++ are systems languages. You can use a hammer for whatever you like, that doesn't make it the right tool for the job. If you want ease of implementation then I'd reckon you don't need Rust. Rust is for correctness and speed. This is why the comparison was made in the first place. To address the heart of what you're getting at: I don't buy the fact that it took "10x" longer to read an XML file. I'll give y…

> If you want ease of implementation then I'd reckon you don't need Rust. Rust is for correctness and speed. This is why the comparison was made in the first place. I'd take the view that "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" doesn't need any more speed than Python, but can benefit from more cor…

>but if I can implement faster than Rust in a language that would also have similar safety properties then I'd rather do that, even if it meant somewhat slower runtime performance.

Why? Does this really make sense? You write it once, it runs a multitude of times. Why is the extra 30 minutes (maybe) to implement in Rust worth more than the extra CPU cycles over countless runs? It's going to be less error prone and faster.

Re: Reflections on Rust, and the Sand Castle Metaphor

#86

Post by dbrgn » Mon, Apr 30, 2018, 7:15 AM UTC

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…

gcc has actually been replaced with the cc crate: https://crates.io/crates/cc

Re: Reflections on Rust, and the Sand Castle Metaphor

#87

Post by lmm » Mon, Apr 30, 2018, 1:53 PM UTC

kadenshep wrote: post #85

lmm wrote: post #84

Earlier quoted context omitted.

> If you want ease of implementation then I'd reckon you don't need Rust. Rust is for correctness and speed. This is why the comparison was made in the first place. I'd take the view that "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" doesn't need any more speed than Python, but can benefit from more cor…

>but if I can implement faster than Rust in a language that would also have similar safety properties then I'd rather do that, even if it meant somewhat slower runtime performance. Why? Does this really make sense? You write it once, it runs a multitude of times. Why is the extra 30 minutes (maybe) to implement in Rust worth more than the extra CPU cycles over countless runs? It's going to be less error prone and fas…

> Why? Does this really make sense? You write it once, it runs a multitude of times. Why is the extra 30 minutes (maybe) to implement in Rust worth more than the extra CPU cycles over countless runs?

CPU cycles are cheap - my CPU is idle most of the time - and my time is expensive. Given that the script in question is fetching a file over FTP, the time taken for that is going to swamp any compute time (even in the Python implementation). Even if you could make a version that ran instantly, how many times would I have to run the script to add up to saving 30 minutes of my time? It doesn't sound like the kind of script that's going to be in use for decades.

> It's going to be less error prone and faster.

Sure, but the overwhelming majority of the time "faster" doesn't matter. So I'm much more interested in comparing languages that have the same safety properties, and whether it's possible to get the same "less error prone" effect from a language that's easier to work in than Rust.

Re: Reflections on Rust, and the Sand Castle Metaphor

#88

Post by iopq » Thu, May 10, 2018, 1:26 AM UTC

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.

Of course it's safer. It prevents you from doing a null pointer exception. That just by itself is a big enough win not to even use Go or Java ever again.

Re: Reflections on Rust, and the Sand Castle Metaphor

#89

Post by iopq » Thu, May 10, 2018, 1:36 AM UTC

pjmlp wrote: post #81

stirner wrote: post #76

Earlier quoted context omitted.

There are many reasons why you might use a systems programming language [1]. > System programming requires a great degree of hardware awareness. Its goal is to achieve efficient use of available resources, either because the software itself is performance critical (AAA video games) or because even small efficiency improvements directly transform into significant monetary savings for the service provider (cloud based…

A few languages do support such low-level controls to have such fine grain memory control outside GC hands. So the question is, having been able to achieve half of the allowed budget, why pay for more development effort? Of course, if the bugdet is only achievable with a lower level language, there is no way around using it.

Because sometimes there's no budget, there's "we spend less money on hardware the less resources our program uses" so faster is always better.