The struggle with Rust

Re:The struggle with Rust by pjmlp on Tuesday January 24, 2017 @02:18PM (#13474545)

> Do you really need to use malloc to allocate memory in a systems language? Do you really need to use pointer arithmetic to deal with things in a systems language?

To add to this point, my answer would be a big NO, if one would look to the C alternatives that sadly became niches.

Sadly the adoption of C has lead to younger generations thinking that those are the only valid paths in system languages.

Thankfully new languages, including Rust, are changing that.

[ Parent | on HN ]

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

However, typed and separate memory areas with various allowed kinds of concurrent access are needed. Even simple RAM has multiple modes, plain, atomic of multiple kinds, barriers... On top of that, you get devices that handle access only with delay inbetween, can never be accessed concurrently (volatile), have alignment requirements and more. Rust memory model is too weak to enforce safety in such cases while not sacrificing performance.

It is written from "I have one CPU" side. Even C is far beyond that with things like OpenCL...

[ Parent | on HN ]

Re:The struggle with Rust by dbaupp on Tuesday January 24, 2017 @06:05PM (#13476641)

Rust gets all your favourite kinds of atomics and barriers, exactly like C. Other things are indeed hard to get safe, which is why Rust has `unsafe`: it is possible to use them, marking out the dangerous regions precisely, rather than the whole program being `unsafe` just because a few places need niche features.

In any case, Rust is definitely not written with "I have one CPU" in mind. A slogan that is sometimes used for Rust is "safe. fast. concurrent.", and it's one of the headline features on the front page: http://rust-lang.org/ . Rust's abstractions allows writing extremely high performance libraries like rayon, which, had better performance than even highly optimised C libraries like Cilk, in one benchmark I heard about. Building out that parallelism ecosystem takes time, so it does not seem particularly surprising that there are more (unsafe!) libraries for the 40-year-old language, than (safe!) libraries in the less-than-2-year-old one.

[ Parent | on HN ]

Re:The struggle with Rust by AstralStorm on Wednesday January 25, 2017 @03:20AM (#13479691)

No, by one CPU i meant not a single core. I meant not having to manage different memory models and available access patterns. Or different ways of handling race conditions and alignments.

You get to use unsafe almost exclusively in the internals of such access where it shouldn't be necessary if there are ways to specify more properties than just binary "safe" and "unsafe".

It is extremely hard to prove such code correct in Rust.

[ Parent | on HN ]

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

> I meant not having to manage different memory models and available access patterns

The only way I can make this make sense, is having cross-platform abstraction around atomic orderings etc. (like the new C++11 std::atomics) that works on x86 and ARM and PowerPC etc.

Rust has such a cross-platform abstraction, almost identical to C++11: https://doc.rust-lang.org/std/sync/atomic/index.html

Please be more specific about what exactly you mean if I am wrong.

[ Parent | on HN ]