Hacker News new | past | comments | ask | show | jobs | submit login

>concurrency still requires the same underlying ideas to be understood whether C++ or Rust

But Rust will catch data race mistakes at compile time, which is very nice. That is a common mistake, and a mistake that can keep happening without you being aware for a long time.




That is a common misconception.

It only applies to threaded code, as soon as IPC, or other kind of external resources enter into the picture there is very little that Rust's type system can do to help with.


There is zero misconception in the GP. Catching data races in threaded code is extremely valuable, regardless of whether it applies to IPC or not. Why? Because non-IPC multithreaded code is a thing. Libraries like rayon even make this sort of parallelism quite easy. With the help of the Rust compiler, it's all safe too.

Just because this doesn't extend to IPC (of course not) doesn't mean there is some kind of misconception here.


Misconception is that IPC and external resources is always left out of the message, so anyone without experience in distributed computing assumes guarantees that Rust actually does not provide.


That's not a misconception. It's a totally different problem space.

> so anyone without experience in distributed computing assumes guarantees that Rust actually does not provide.

[citation needed]


I don't think you can have shared IPC memory in rust. You have to use message passing. Of course you are on your own completely, and there will be weird logic bugs when you mess it up. However, there won't be any memory corruptions.


Sure you can, it is no different than mapping a FFI pointer inside unsafe code block, or doing a mmap like access.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: