The struggle with Rust

Re:The struggle with Rust by jackmott on Tuesday January 24, 2017 @09:36AM (#13471581)

I don't think they are any error classes that OCaml/F# will let you make that Rust won't.

[ Parent | on HN ]

Re:The struggle with Rust by stonemetal on Tuesday January 24, 2017 @09:57AM (#13471750)

Rust prevents data races, OCaml/F# don't provide such guaranties. Though it isn't so much of a problem in OCaml since it doesn't have concurrent threads.

[ Parent | on HN ]

Re:The struggle with Rust by jnbiche on Tuesday January 24, 2017 @12:16PM (#13473302)

OCaml has GIL, is normally single core, and shares no state, so current OCaml doesn't need to provide such guarantees.

Upcoming multicore OCaml will provide such guarantees through algebraic effects [0].

0. http://kcsrk.info/ocaml/multicore/2015/05/20/effects-multico...

[ Parent | on HN ]

Re:The struggle with Rust by AstralStorm on Tuesday January 24, 2017 @03:35PM (#13475213)

First, Rust does not prevent data races, just makes them pain to write.

Second, Rust also prevents legitimate sharing in a bunch of cases where concurrency is not involved. (and a simple scoped allocator succeeds)

This would be fixed if there was an easy way to have typed memory that can be shared but cannot be accessed concurrently. There is none. You get at most full unsafe.

[ Parent | on HN ]

Re:The struggle with Rust by steveklabnik on Tuesday January 24, 2017 @03:41PM (#13475260)

Rust does prevent data races, as long as you don't use unsafe. If not, it's a bug.

You can write arenas in Rust.

[ Parent | on HN ]

Re:The struggle with Rust by GolDDranks on Tuesday January 24, 2017 @04:05PM (#13475435)

Just to be clear about the terminology (since I'm not sure if the grandparent knows about the difference): Rust prevents data races but not race conditions (although it makes it easier to avoid them). Here's an explanation about the differences: http://blog.regehr.org/archives/490

[ Parent | on HN ]

Re:The struggle with Rust by AstralStorm on Wednesday January 25, 2017 @02:49AM (#13479560)

You can, but it is an extreme pain to do it, especially for any nontrivial data structure. That is because even if the arena is safe enough, say with copy on write semantics, you cannot specify that for the borrow checker easily (or at all)

You cannot implement many data structures in a decent performance way without unsafe, so Rust guarantee is weak.

[ Parent | on HN ]

Re:The struggle with Rust by dbaupp on Wednesday January 25, 2017 @02:27PM (#13485033)

> You can, but it is an extreme pain to do it,

It is not extreme, and it isn't even necessary: just reuse one of the many arenas others have already written, e.g. https://crates.io/crates/typed-arena .

Copy-on-write is fairly ease to write in Rust, e.g. the even core Rc and Arc types have a get_mut function that does copy-on-write.

> You cannot implement many data structures in a decent performance way without unsafe, so Rust guarantee is weak.

You can't implement anything in C or C++ without unsafe: Rust's main strength is the ability to write high performance code with a safe interface, so that only one library has to muddle through the `unsafe` problems (if they have to touch `unsafe` at all). Most code one writes is not implementing data structures.

As a demonstration of this strength, even very low-level projects like operating systems can get away with not using `unsafe` everywhere by packaging it up into safe interfaces, e.g. http://os.phil-opp.com/modifying-page-tables.html

[ Parent | on HN ]

Re:The struggle with Rust by pcwalton on Tuesday January 24, 2017 @11:25AM (#13472703)

Data races.

[ Parent | on HN ]