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

Rust is mostly safety

graydon2.dreamwidth.org

Post reply on HN
Print view View original

361–370 of 474 posts

Re: Rust is mostly safety

#361

Post by yawaramin »

zerofan wrote: post #348
yawaramin wrote: post #344

Earlier quoted context omitted.

I think it's a misconception to classify type-safety and memory-safety techniques as 'clever', they should be seen as the bread-and-butter of day-to-day coding. To put it another way, Rust's memory safety is no more clever than C++'s smart pointers, the only difference is what people mistakenly believe about the two.

> I think it's a misconception to classify type-safety and memory-safety techniques as 'clever' I didn't call Rusts type-safety of memory-safety clever. The clever stuff is lifetime specifications, a multitude of string types, traits as indications to the compiler for move vs copy, Box Ref Cell RefCell RefMut UnsafeCell, arbitrary restrictions on generics, needing to use unsafe code to create basic data structures, a…

Almost everything you mentioned as 'clever' is trying to achieve either type-safety or memory-safety. To your coworkers I would reply: would you like the compiler to handle error-prone memory deallocations? Or do you want to keep doing it manually and wait till runtime to find potential mistakes?

Re: Rust is mostly safety

#362

Post by eropple »

bjz_ wrote: post #309
jwn wrote: post #305

Earlier quoted context omitted.

I really want to love Rust, and while I understand the Rust borrow checker in theory, actually using it in practice has been a major headache. I tried Rust on a simple terminal-based project, and after a week of feeling that I was getting nowhere I switched to Go and had a proof of concept in several hours. With that said, can you recommend a good source to really understand best practices and patterns for ownership…

Alas, I think a week is too short to give Rust. Go will get you more pay-off in the short term, but as you internalise the rules of Rust you'll really start to reap the benefits. Unfortunately being an experienced user, I'm not aware of a single online source for learning this stuff - I mainly teach people directly in person or on IRC.

Agreed. It took me about two months to really understand Rust, and I was coming from a background of languages like C++ and Scala. It pays off, though, for what I want to do with computers.

The rise of "it demos well so we should use it" is in a lot of ways troubling. The inflection point for productivity doesn't need to be "five minutes in" to be worthwhile if you're doing something that is, itself, worthwhile.

Re: Rust is mostly safety

#363

Post by keldaris »

dbaupp wrote: post #349
keldaris wrote: post #338

As someone looking at this influx of discussion from the point of view of a curious bystander, I can't help but be annoyed by two persistent misconceptions that keep being perpetuated in many statements of this kind. 1) Memory safety is or should be a top priority for all software everywhere. The OP goes so far as to state: "When someone says they "don't have safety problems" in C++, I am astonished: a statement that…

Memory safety is important for everything because it is a prerequisite for any other form of correctness. There's no guarantee that a violation of memory safety will result in a crash, memory corruption is just as possible, resulting in a bad numerical computation or a broken game. It may be that the risk of an actual problematic memory safety violation in numerics/gaming is small enough to not worry, but it is still…

> Memory safety is important for everything because it is a prerequisite for any other form of correctness.

That's obviously true, but not what I (or the OP) was talking about. My point was that in many applications memory safety doesn't rank highly as a separate concern, in addition to computing correct output from expected input. Because of this, describing Rust as a language that solely focuses on memory safety isn't very interesting to large groups of developers that work on such applications.

> The rayon library offers similar functionality to OpenMP, including a parallel map/reduce (etc) over a vector, all in safe code for the user.

I did look at rayon when I skimmed through the available ecosystem. The runtime cost of that approach wasn't obvious to me from the documentation, and it doesn't quite let me keep the loop-based control flow usually employed for numerical calculations (because of the need to refer to different indices within the loop, etc.), but it's certainly a viable approach. Not a direct replacement to OpenMP loops, though.

On the subject of -ffast-math, I did not encounter these recent additions you mention in the language documentation, but I'll take another look on the issue tracker and elsewhere. Thanks for the information.

On tail call optimisations, I don't believe your statement is entirely correct. It's true that C++ compilers don't guarantee TCO (although, empirically they're very good at it), but Rust doesn't seem to be able to do it at all. It's explicitly stated in the language documentation and there's a recent issue on the subject [1].

And on explicit vectorization - I'll take a look at the latest nightly Rust and edit my post accordingly if explicit SIMD is already usable. Glad to hear it.

FWIW, I think Rust has made great progress considering the age of the language, and I'm glad to see SIMD and other improvements being implemented. My objection was simply against the hyperbolic assertion that Rust has already attained full parity or even superiority over C++ in performance.

By the way, is there a way to turn off runtime bounds checking for vectors? That's another common performance sink in numeric computing.

[1] https://github.com/rust-lang/rust/issues/217

Re: Rust is mostly safety

#364

Post by white-flame »

hedora wrote: post #359
cmyr wrote: post #233

Earlier quoted context omitted.

I couldn't agree more with this. Cargo (and the general desire to think and work hard on ease-of-use) is a huge part of what makes Rust a pleasure. It alone would be enough for me to steer someone with experience in neither to Rust over C++ for lots and lots of use cases.

I haven't looked at rust, and this sentiment is exactly what has kept me away. I watched perl, java, python, ruby, node and c++ (boost) fall into the trap of "we know better than the end-user/developers/sysadmins/os vendor, so let's reinvent dpkg poorly". Why should cargo be any different? It is solving a problem I don't have (debian, ubuntu, openbsd, and freaking illumnos all have acceptable package management), and…

apt & ports don't follow you into other OSes. Language-specific package managers do, without requiring entanglement with the OS or admin permissions. All you need is sockets and a filesystem.

I think the language-specific ones will win for developer-oriented library management for platform-agnostic language environments.

Re: Rust is mostly safety

#365

Post by z1mm32m4n »

hedora wrote: post #359
cmyr wrote: post #233

Earlier quoted context omitted.

I couldn't agree more with this. Cargo (and the general desire to think and work hard on ease-of-use) is a huge part of what makes Rust a pleasure. It alone would be enough for me to steer someone with experience in neither to Rust over C++ for lots and lots of use cases.

I haven't looked at rust, and this sentiment is exactly what has kept me away. I watched perl, java, python, ruby, node and c++ (boost) fall into the trap of "we know better than the end-user/developers/sysadmins/os vendor, so let's reinvent dpkg poorly". Why should cargo be any different? It is solving a problem I don't have (debian, ubuntu, openbsd, and freaking illumnos all have acceptable package management), and…

TL;DR: I think language-centric package managers do a better job at versioning packages per-project. Here's an anecdote to explain what I mean.

-----

Let's say I want to build a piece of software that depends on some software library written in C at version 1.0.1. It's distributed through my system package manager, so I sudo apt-get install libfoo.

~~ some time later ~~

Now let's say I want to build a different piece of software that also depends on foo, but at version 1.2.4. I notice that libfoo is already installed on my system, but the build fails. After a quick sudo apt-get install --only-upgrade libfoo. This piece of software now builds.

~~ Even later ~~

When I revisit the first project to rebuild it, the build fails, because this project hasn't been updated to use the newer version yet.

I'm fairly inexperienced with system package managers, but this is the wall I always hit. How should I proceed?

Re: Rust is mostly safety

#366

Post by zerofan »

yawaramin wrote: post #361
zerofan wrote: post #348

Earlier quoted context omitted.

> I think it's a misconception to classify type-safety and memory-safety techniques as 'clever' I didn't call Rusts type-safety of memory-safety clever. The clever stuff is lifetime specifications, a multitude of string types, traits as indications to the compiler for move vs copy, Box Ref Cell RefCell RefMut UnsafeCell, arbitrary restrictions on generics, needing to use unsafe code to create basic data structures, a…

Almost everything you mentioned as 'clever' is trying to achieve either type-safety or memory-safety. To your coworkers I would reply: would you like the compiler to handle error-prone memory deallocations? Or do you want to keep doing it manually and wait till runtime to find potential mistakes?

I don't believe those clever things are necessary for safety or performance. I think many of them are incidental and caused by a lack of taste or just a disregard for the value of simplicity. Rust deserves credit for it's good ideas, but these aren't those, and I believe there will be other high performance (non-GC) languages that are more accessible to non Computer Scientists [1].

> To your coworkers I would reply: would you like the compiler to handle error-prone memory deallocations? Or do you want to keep doing it manually and wait till runtime to find potential mistakes?

They don't really care about memory deallocations - the program will finish soon anyways, and the operating system will cleanup the mess. Sorry, they've already excused you from the office and have gotten back to getting their work done.

Btw, modern C++ programmers don't worry about memory deallocations either. You should find a better bogeyman.

[1] http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan... (yes, most people disregard benchmarks, but you need someway to discuss performance)

Re: Rust is mostly safety

#367

Post by nnethercote »

PudgePacket wrote: post #336
sh_tinh_hair wrote: post #334

Safety stopped here: "curl https://sh.rustup.rs -sSf | sh" So did my interest.

It's convenient for the majority of people. There are regular downloads available ( https://www.rust-lang.org/en-US/other-installers.html ) and you can probably also get Rust through your system package manager.

"I trust your binaries but I don't trust your shell script for installing those binaries."

Re: Rust is mostly safety

#368

Post by tomjakubowski »

zerofan wrote: post #290
nnethercote wrote: post #276

Earlier quoted context omitted.

It's perfectly reasonable to say "Rust isn't appropriate for my use case". Your comment higher up was more along the lines of "Rust isn't appropriate for anyone" which is far less reasonable.

If you're going to put words in his mouth, you should make them much stronger words. It's not a valid argument either way, but it'll seem more dramatic. (He didn't say either of your quotes...)

I downvoted you initially, but changed to an upvote to hopefully ungrey your comment.

The use of quotation marks on the Internet (especially on Internet discussion forums) has become non-standard, and I can see how it could be confusing. I think on HN that we tend to use italics or email-style

> block-quoting

to indicate direct quotations of posts or user comments.

Quotation marks on forums like HN tend to be used either to mark dialogue (things spoken out loud) or to mark paraphrased or "hypothetical" thoughts. This is different from the use of quotation marks in formal English writing, as described by Wikipedia [1]. Here, the quotation marks are used to separate the "paraphrased thought" from the rest of the sentence.

I'm actually finding it hard to describe exactly how quotation marks are used this way on the Internet; it's something I've just developed a "feel" for.

There's more discussion of this phenomenon here. http://metatalk.metafilter.com/23184/Should-we-keep-quotatio...

[1]: https://en.wikipedia.org/wiki/Quotation_marks_in_English

Re: Rust is mostly safety

#369

Post by braveo »

msbarnett wrote: post #223
braveo wrote: post #204

Earlier quoted context omitted.

You completely misunderstood what he was trying to tell you.

There was nothing interesting in what he was trying to say. Yes, no programming language perfectly eliminates all classes of unsafety. But that's no reason to let the perfect be the enemy of the good! "The issue with safety is..." no issue at all. Being safe in a bunch of problem domains (Rust) is still strictly better than being safe in very few if any of them (C).

So you did it on purpose. That just makes you a bad actor in the conversation.

Re: Rust is mostly safety

#370

Post by deathanatos »

sh_tinh_hair wrote: post #334

Safety stopped here: "curl https://sh.rustup.rs -sSf | sh" So did my interest.

This is effectively what most package managers do too. If you're going to be running code from a third party, you need to be able to trust that command, or there's really nothing you can do, as some equivalent of it is going to run.
Post reply on HN