You can't Rust that

Re:You can't Rust that by pcwalton on Saturday March 31, 2018 @03:37PM (#16724773)

> Is there any protection for non-atomic ref counting in a multithreaded environment in Rust?

Of course. Rust is memory safe. The compiler will prevent you from sharing non-thread-safe reference counted objects between threads.

This is a significant advantage over C++, where the compiler offers no such protection and so the typical solution is just to use atomic reference counting (shared_ptr) everywhere.

[ Parent | on HN ]

Re:You can't Rust that by gmueckl on Saturday March 31, 2018 @03:44PM (#16724811)

So are you claiming that the exact same solution is good in rust and bad in C++?

[ Parent | on HN ]

Re:You can't Rust that by moosingin3space on Saturday March 31, 2018 @04:26PM (#16725008)

I'm not pcwalton, but he is correct. The Rust compiler only allows objects that implement the Sync trait to cross thread boundaries. Rc<T> is not Sync, while Arc<T> is. Sync is a marker trait, with impls automatically generated by the compiler for types that are comprised entirely of Sync types, or manually (and unsafely) specified by the author. As a result, Rc<T> cannot be misused from multiple threads without unsafe.

To learn more about this, look here: https://doc.rust-lang.org/beta/nomicon/send-and-sync.html

[ Parent | on HN ]

Re:You can't Rust that by the_mitsuhiko on Saturday March 31, 2018 @03:45PM (#16724820)

I'm not the person you are replying to but I would never use a non atomic refcounted smart pointer in C++ because the risks associated with it are just too high. In Rust however the compiler protects me from misuse.

Separately emotionally I feel different about Arc<T> because all the counting is explicit and I see it. Understanding where shared_ptr<T> in C++ counts however can be quite a challenge, even if you consider yourself proficient with C++.

[ Parent | on HN ]

Re:You can't Rust that by gmueckl on Saturday March 31, 2018 @03:57PM (#16724871)

I may be in the minority here, but if you are programming properly, your understanding of the code should always be good enough that this is a non-issue. If you manage to trigger a compiler error like this at all, you are most likely hacking, not developing.

[ Parent | on HN ]

Re:You can't Rust that by oconnor663 on Saturday March 31, 2018 @04:27PM (#16725012)

This sort of mistake gets harder and harder to prevent as programs get larger. For example, one programmer might use a non-atomic Rc pointer to hold a string in some random Error value. Later, another programmer might try to parallelize that part of the program, without realizing that sending an Error across a thread boundary is now illegal. Or maybe the same mistake happens in the other order.

Here's Niko Mastakis talking about a case where that happened to him (I think): https://youtu.be/lO1z-7cuRYI?t=4m

[ Parent | on HN ]

Re:You can't Rust that by swsieber on Saturday March 31, 2018 @06:56PM (#16725608)

I don't trust myself to not make mistakes though even when I have a thorough understanding of what I'm making.

"... trusting the programmer is fundamentally wrong, no matter the programming language"

[ Parent | on HN ]

Re:You can't Rust that by the_mitsuhiko on Saturday March 31, 2018 @04:03PM (#16724913)

Should probably but I'm not a good enough developer (yet?) to guarantee that. I rather take the extra safety from the compiler.

[ Parent | on HN ]

Re:You can't Rust that by pcwalton on Saturday March 31, 2018 @03:59PM (#16724888)

Reference count problems routinely result in vulnerabilities. Google for [cve reference count].

[ Parent | on HN ]

Re:You can't Rust that by gmueckl on Saturday March 31, 2018 @04:10PM (#16724940)

But these vulnerabilities can only happen if reference counting is not automatic, right?

[ Parent | on HN ]

Re:You can't Rust that by pcwalton on Saturday March 31, 2018 @04:28PM (#16725016)

No, because of the way references in C++ work—you can take a reference to the inside of a reference counted object without manipulating the reference count.

They could also happen if you used non-thread-safe reference counting on a thread-safe object. Now this seems to be rare in practice, because non-thread-safe reference counting is unusual. If it became more prevalent, however, I could see it happening.

[ Parent | on HN ]

Re:You can't Rust that by empath75 on Saturday March 31, 2018 @04:24PM (#16725005)

Real programmers apparently never make mistakes.

[ Parent | on HN ]

Re:You can't Rust that by moosingin3space on Saturday March 31, 2018 @04:31PM (#16725024)

Unofficial slogan of the C apologism task force, apparently.

[ Parent | on HN ]

Re:You can't Rust that by gmueckl on Saturday March 31, 2018 @04:38PM (#16725060)

No. Real developers design their data structures and algorithms carefully. When it is tine to implement them, everything should be laid out clearly enough. There are industries where this kind of process is required and it truely shows in the quality of the results.

[ Parent | on HN ]

Re:You can't Rust that by pcwalton on Saturday March 31, 2018 @08:09PM (#16725882)

I mean, that's great in theory, but we've been trying the "just design the program better" approach for 40 years and have been failing.

[ Parent | on HN ]

Re:You can't Rust that by kbenson on Saturday March 31, 2018 @05:09PM (#16725194)

If the vast majority of software is not made by real developers (and I think by the definitions you are espousing it is not), then I think one of the definitions is in need to change.

As beneficial to your argument as it would be for that change to be the definition of "software", I don't think that's likely.

[ Parent | on HN ]

Re:You can't Rust that by gmueckl on Saturday March 31, 2018 @10:58PM (#16726449)

I needed to make a distinction in the dedinition I gave. And I stand by it, even if the wording comes across as snarky. There are software engineering methods that are proven to work. They do not involve just diving in and changing the code. But I also think that there are valid reasons to not apply these rigid development practices to certain kinds of projects. For the rest, we might well get mandatory development standards forced on us to

I am well aware of the pressure on developers to get requested feature done quickly. But the vast majority of bugs that get shipped would be easily prevented by more thorough processes. All those projects writing highly reliable software demonstrate this. But the price tag has a few zeroes appended as a result.

[ Parent | on HN ]

Re:You can't Rust that by pohl on Saturday March 31, 2018 @11:56PM (#16726621)

There are software engineering methods that are proven to work.

Rust’s type system is arguably one of them.

[ Parent | on HN ]

Re:You can't Rust that by gmueckl on Sunday April 01, 2018 @06:45AM (#16727658)

I was talking about processes, not tools. Rust is just tool. But good software comes from thorough processes.

[ Parent | on HN ]

Re:You can't Rust that by kibwen on Sunday April 01, 2018 @10:35AM (#16728484)

Good software comes from processes that aren't afraid to adopt tools to automatically enforce those processes in order to guard against human oversight.

[ Parent | on HN ]

Re:You can't Rust that by gmueckl on Monday April 02, 2018 @05:14AM (#16733278)

Tools come from processes. You need to know what the tool needs to do (the process) before you can write it.

[ Parent | on HN ]

Re:You can't Rust that by pohl on Sunday April 01, 2018 @10:59AM (#16728595)

Type systems are applied mathematics. You can’t get more engineering-y than that.

[ Parent | on HN ]

Re:You can't Rust that by gmueckl on Monday April 02, 2018 @05:17AM (#16733281)

See my reply to the other comment.

Type systems are tools that simply the process of checking that you do not mangle data by applying the wrong instructions to them. They didn't come out of nowhere.

[ Parent | on HN ]

Re:You can't Rust that by pohl on Monday April 02, 2018 @02:25PM (#16737571)

Math is a tool, too, yet applying mathematical methods is one of the defining characteristics of engineering.

[ Parent | on HN ]

Re:You can't Rust that by wtetzner on Saturday March 31, 2018 @06:24PM (#16725491)

> There are industries where this kind of process is required and it truely shows in the quality of the results.

It also shows in the cost of building the software. Most software companies aren't willing to pay the cost of that process. Like it or not, you will almost certainly interact with software written by these companies, either directly or indirectly.

[ Parent | on HN ]

Re:You can't Rust that by the_mitsuhiko on Saturday March 31, 2018 @03:19PM (#16724687)

> Is there any protection for non-atomic ref counting in a multithreaded environment in Rust?

Yes. It errors at compile time (`std::rc::Rc<i32>` cannot be sent between threads safely)

[ Parent | on HN ]