[rurban]

Putting them well together in Rust is debatable.

Writing proper and safe concurrent code in Rust still looks horrible compared to languages which supports it natively in the type system, e.g. ponylang type capabilities. You still have to manually maintain locks, and it's also much slower.

There's a safety model, but it's only best practice, not enforced by the language nor the compiler. So calling it "safe" and "truly unique" is way off. Even parrot has a better, safe and lockless threading model, which guarantees safety.

[Manishearth]

> You still have to manually maintain locks, and it's also much slower.

You ... don't. That's just the concurrency model that the abstractions in the stdlib expose, but Rust's safety is generic enough that you can use different abstractions (e.g. lockfree ones). See crossbeam for some alternative models. There are also transactional memeory impls in Rust. They still use Send and Sync for safety though. Manually maintaining locks is a feature of the concurrency library used, not the safety model.

Pony's system is actually pretty close to that of Rust. Sync is "immutable", Send is "isolated" (sort of). Of course, capabilities are different from auto traits, but the idea behind using these two capabilities for concurrency safety is similar.

(So I was wrong that Rust's concurrency safety system is unique, since Pony has something based on the same concepts)

> There's a safety model, but it's only best practice, not enforced by the language nor the compiler.

Yeah, Send and Sync are technically a part of the stdlib (and can be reimplemented outside of it, aside from a small interaction with statics -- Send/Sync are treated as special by the compiler when it comes to statics). However, it is enforced by the compiler in the sense that if you avoid best practice (using Send and Sync), you can't write parallel code without dropping to `unsafe`. If you do that you can design safe abstractions around that and use whatever concurrency enforcement you wish, though pretty much everyone sticks to Send and Sync since it works well with the rest of the language.

(Because of the statics thing, "not part of the language" is debatable, anyway)

[gpderetta]

Having a language-imposed concurrency model would be useless and actively harmful in a system language. Rust provides the building blocks to build whatever safe abstractions are appropriate for the problem and domain at hand, plus a set of out of the box abstractions relatively low level that will be familiar to people coming from other system languages.

And of course the means to get rid of any abstraction and safety when required.

edit: accidentally a word

[jonathanstrange]

> Having a language-imposed concurrency model would be useless and actively harmful in a system language.

It works fine in Ada.

Edit: Why am I downvoted for this? A language-defined concurrency model is indispensable for having safe and deadlock-free concurrency in the language (rather than in arbitrary utility libraries). That's why concurrency was explicitly included into Ada and into the additional Ravenscar profile. The rationale for this has always convinced me and it also works fine in Ada, so anybody care to elaborate what's wrong with it?

[nickpsecurity]

It worked great for Concurrent Pascal and Solo:

http://brinch-hansen.net/papers/

I agree it's better to have mechanisms that can be turned into a proper model. A good default, though, greatly improves consistency and reliability in real-world systems.

[rwmj]

Only if development of the language and OS are separate. If you co-develop the language with the OS, then it makes perfect sense to push safety features into the language (or conversely, to remove them from the language when they are no longer appropriate).

LISP-strength macros give you most of this capability.

[gpderetta]

OS are not the only use cases for system languages and developing a language to be tightly tied to an os (and viceversa) is a great way to condemn both to obscurity.

[amalcon]

Erm... I think Dennis Ritchie would have had a few things to say about that.

[gpderetta]

good point; though, while designed to work well with each other, neither unix nor C require the other.

[bluejekyll]

If you want a portable C, *libc is practically a requirement. Having POSIX is also a huge boon.

[pcwalton]

> There's a safety model, but it's only best practice, not enforced by the language nor the compiler.

What? How is it not enforced?

> You still have to manually maintain locks, and it's also much slower.

Slower? I don't think it can be any faster even in theory!