I can't wait for a mature idris+mature rust. It will be a better world then.
It makes me sad that Idris is (explicitly) never going to be an industrial language - so many nice things in it.
Fearless concurrency with Rust
131–140 of 186 posts
Re: Fearless concurrency with Rust
#132Earlier quoted context omitted.
std::unique_ptr is a significant improvement over prior options, but it can neither ensure correct usage of a mutex (in the sense that it can't cause a data race) nor preserve data race safety for references into another thread's stack. Both of these rely on Rust's ability to limit reference lifetimes, which C++11 doesn't really have (C++14 has an extremely limited form of it in rvalue references, but it's not suffic…
unique_ptr transfers ownership. No 2 threads can be working on the same object unless you go out of our way to cheat unique_ptr behavior. Statically or at runtime guarantees don't buy me much. Regarding mutations, const and copy/move constructors give you want u want. Generally, all you need to do is have 1 thread create an std::unique_ptr object and pass it to the channel for other thread to pick it up.
Regardless of whether you feel that these static guarantees buy you anything, C++ does not have them and Rust does; the two solutions are not equivalent. Const references only guarantee that you are not mutating through the reference, not that someone else isn't--if you are writing a library that accepts one, you cannot prevent misuse by users. This is an important difference from Rust. In any case, you still haven't explained how unique_ptr helps with the other two things I mentioned (ensuring that data protected by a mutex cannot be accessed without acquring the lock, and safely sharing and/or mutating data on another thread's stack). The blog post explains how Rust does it; C++ simply does not have the necessary types.
Re: Fearless concurrency with Rust
#133Earlier quoted context omitted.
When Go was first announced in 2009, I thought "this is a nice idea, but I really wish it had generics and non-nullable references". Then Rust was announced a few months later, and I thought "wow, this is what Go should have been." However, in the intervening time, Rust has diverged farther from Go. It no longer has green threads nor emphasizes message-passing based concurrency. In addition, Go was ready to use much…
Well, let's also not forget that a big factor in Go's success is Google. Google has much deeper pockets than Mozilla to build a language and infrastructure.
But it's not as if they threw a massive amount of manpower or budget at it. I think Go succeeded more by association (to Google) and the fact that it hits a sweet spot for many people - it produces native code, but does not have the complexity of C++ or the unsafety of C.
I have written a fair bit of Go code. But I will switch to Rust without a second though once the ecosystem takes of. The lack of simple things like generics or algebraic data types in Go is jarring.
Re: Fearless concurrency with Rust
#134Earlier quoted context omitted.
When Go was first announced in 2009, I thought "this is a nice idea, but I really wish it had generics and non-nullable references". Then Rust was announced a few months later, and I thought "wow, this is what Go should have been." However, in the intervening time, Rust has diverged farther from Go. It no longer has green threads nor emphasizes message-passing based concurrency. In addition, Go was ready to use much…
Well, let's also not forget that a big factor in Go's success is Google. Google has much deeper pockets than Mozilla to build a language and infrastructure.
This meme really should die.
It has never been true so there's nothing to forget.
The number of full-time Rust people paid by Mozilla is roughly the same as number of Go people paid by Google.
Mozilla is a wealthy company and while Google is even more wealthy, it doesn't mean that it spends all its money on Go. Both v8 and Dart are staffed with more people and Dart is not taking off the way Go is.
People are trying to rationalize away the explosive popularity of Go with all sorts explanations, the "it's all because it's Google" being one of them.
The simple explanation is: people use Go because it's a good language. That's the big factor in Go's success.
Re: Fearless concurrency with Rust
#135Earlier quoted context omitted.
> Go was attempting to use only very-well-understood ideas to make a very-well-understood, simple language. Many of the ideas in go were not well understood and had only been demonstrated in research languages prior to go. Its concurrency model and associated primitives, and the automatic interface system were in roughly the same state then as Rust's new ideas are now. That said the ideas in Rust were not as well und…
> Many of the ideas in go were not well understood and had only been demonstrated in research languages prior to go. Its concurrency model and associated primitives, and the automatic interface system were in roughly the same state then as Rust's new ideas are now. to Go's authors the CSP model was very well understood through three different implementations: Alef, Limbo, and Plan 9's libthread.
> Alef, Limbo, libthread.
Also Newsqueak.
Re: Fearless concurrency with Rust
#136And here's me, happy building apps with Erlang/Elixir with their concurrency model.
Re: Fearless concurrency with Rust
#137Earlier quoted context omitted.
When Go was first announced in 2009, I thought "this is a nice idea, but I really wish it had generics and non-nullable references". Then Rust was announced a few months later, and I thought "wow, this is what Go should have been." However, in the intervening time, Rust has diverged farther from Go. It no longer has green threads nor emphasizes message-passing based concurrency. In addition, Go was ready to use much…
Well, let's also not forget that a big factor in Go's success is Google. Google has much deeper pockets than Mozilla to build a language and infrastructure.
The biggest factor probably was that Rob Pike had basically been prototyping the language for 20 years.
(But google's name certainly helped.)
Re: Fearless concurrency with Rust
#138Earlier quoted context omitted.
> Linear-session-typed process calculi are guaranteed deadlock-free and race-free While this may be true for certain restricted systems, this claim is misleading. Session types, as invented by K. Honda and refined by numerous others, guarantee deadlock and race freedom only within any given session . Session initiation (basically messages to replicated inputs) can deadlock and race in many (most?) session typing syst…
I mostly know about the linear logic side of session types; I'm not super familiar with the older line of research starting with Honda. I'll have to read up on it! I'm not sure what the equivalent in my world of "session initiation" is. If by "replicated inputs" you mean what in linear logic is expressed by the "!" connective (often called "replication"), it's definitely possible to have ! without deadlocks or any ob…
Honda's pioneering papers on session types (and on everything else for that matter) are always worth reading.
Yes, replicated input is !x(v1).P in pi-calculus, and Milner was directly inspired by linear logic's replication.
> Still, overall I think I'm more optimistic about the possibility of capturing most reasonable forms of concurrent programming in a deadlock & race-free manner.
I don't think you can, or indeed want to excise all forms of race condition from concurrent programs, for if you do that, there would be little concurrency left. You could only do deterministic concurrency, which is not what you want in many cases, e.g when you use concurrency to mask latency. For example how would you define a lock or mutex if all races are forbidden? You need race conditions, but you want them in homeopathic doses, you want them constrained and tightly controlled.
I also doubt that concurrent programming patterns like dynamic deadlock detection and removal are amenable to a type-theoretic analysis in linear-logic based systems such as Caires & Pfenning's.
Re: Fearless concurrency with Rust
#139Earlier quoted context omitted.
Well, let's also not forget that a big factor in Go's success is Google. Google has much deeper pockets than Mozilla to build a language and infrastructure.
The biggest factor probably was that Rob Pike had basically been prototyping the language for 20 years. (But google's name certainly helped.)
Not to take anything away from your comment on this being a language that has been brewing for years, but people really should give Robert Griesemer more credit for his influence on the language design.
I know he's the least publically visible of the three, but IIRC godoc and gofmt are mostly his babies. After getting used to those I think I miss them more in other languages than I miss the concurrency.
Re: Fearless concurrency with Rust
#140And here's me, happy building apps with Erlang/Elixir with their concurrency model.
Immutability sure makes this stuff easy in Erlang.
EriPascal, an ancestor of Erlang, used runtime ownership for passing mutable binaries around. Once you send the binary in a message it is a runtime error to use it again afterwards.