Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fearless concurrency with Rust

blog.rust-lang.org

Post reply on HN
Print view View original

81–90 of 186 posts

Re: Fearless concurrency with Rust

#81

Post by lambda »

fny wrote: post #27
steveklabnik wrote: post #16

Earlier quoted context omitted.

> Also, are there any plans to integrate tutorial-style guides similar to those from Rust for Rubyists into the Rust book? I'd been waiting for beta to drop to do a re-organization of the TOC of the book. You can see it on nightly here: http://doc.rust-lang.org/nightly/book/ I've carved out a whole section, "Effective Rust", specifically for this kind of thing. I'm looking for a better name than "Effective Rust", sin…

Never new Rust by Example existed until today actually! You really should link to it somewhere more prominent. I'm fairly far along, but would have loved the example book had I know about it sooner.

It is actually linked to from the front page of http://www.rust-lang.org/; it's the "more examples" link under the example. But I guess that's just far enough down to be easy to miss; it's just below the fold on my screen.

Re: Fearless concurrency with Rust

#82

Post by elektronjunge »

dilap wrote: post #64
Animats wrote: post #12

Rust's ownership model, and the borrow checker that enforces it, are a major breakthrough in language design. It's so simple, yet it solves so many problems. This is what Go should have done. Then Go's "share by communicating, not by sharing" would be real, not PR. Go code often passes references over channels, which results in shared memory between two threads with no locking. In Rust, when you do that, you pass own…

"Should have done" is a silly phrase to use here -- Rust is attempting to advance the state of the art, Go was attempting to use only very-well-understood ideas to make a very-well-understood, simple language. Perhaps some day we will see a successor language that follows the philosophy of Go using the new stuff we understand thanks to Rust.

> 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 understood 5 years ago and I doubt that the go creators could have incorporated them well at the time. It took Rust 5 years of experimentation to come to what it is now (and its still got a number of additions to go!).

Re: Fearless concurrency with Rust

#83

Post by mamcx »

Jweb_Guru wrote: post #75
mamcx wrote: post #74

Earlier quoted context omitted.

I wonder how much the concept of owner/borrows could work in a more scripting/dynamic language. Exist some sample on that direction? I'm working in a toy language focused in data (relational), on top of F#.

Ownership is doable in a dynamic language, provided you are willing to tolerate aborts: C++'s std::unique_ptr is enforced at runtime. Similarly, you can emulate dynamic borrowing using something like Rust's RefCell, which aborts when you attempt to mutably borrow a value twice (though it can be quite difficult to reason about from a usability perspective). But if you're building on top of F# you have a static type sy…

My lang will have a static type, so that info is usefull.

It will start as a interpreter, but probably the challenge is the ergonomics of it: How make it "easier" to use... probably limit it to only handle resources? (ie: files, handles, etc, like the IDisposable in .net)

Re: Fearless concurrency with Rust

#84

Post by jrapdx3 »

FWIW I thought the article was quite informative and well-written enough to make the concepts easy to grasp. I'd agree with the opinion that Rust is breaking new ground in an interesting way, and over the next several years I wouldn't be at all surprised to see its ideas becoming quite influential.

The discussion points out something else that too often receives too little attention. That is, the quality of documentation is extremely relevant to product success. Sadly, software is more often than not poorly documented, not only frustrating for potential users, but an unnecessary impediment to uptake of the program.

It appears the Rust developers are serious about describing how Rust works. That's a very favorable sign of their commitment to the project and speaks volumes about dedication to grow the Rust community.

Re: Fearless concurrency with Rust

#85

Post by Jweb_Guru »

zzzcpan wrote: post #79
copsarebastards wrote: post #72

Earlier quoted context omitted.

> Go has very different design goals than Rust, so very little that Rust does would actually be possible in Go, and vice versa. Oh give this lame argument a rest already. They're both supposedly general-purpose programming languages. Rust shoots for a little lower level than Go, but they can certainly be compared, and the comparisons are valid. > Having a complex type system would cut into compile times (an explicit…

> The fact is, these "idioms and best practices" will not be followed perfectly on projects of any reasonable size if they are not enforced by code. Why would you not enforce them with code? Compiler shall not be an obstacle to a man. We tried enforcing things before, many times. Things got abandoned.

Agreed. But every production language that I'm aware of has an out that allows you to escape its type system, with the exception of languages whose type systems are intended to uphold strong security properties and verification languages that feature decidable logics. I can't remember for sure, but I think even Coq--which is eminently not a language designed for everyday programming--may diverge if you explicitly opt out (though I could be wrong about that).

The questions, to my mind, are

1. How easy it is to opt out?

2. How often do you have to opt out?

3. How easy it is to write well-typed expressions?

4. What guarantees does a program being well-typed provide?

For example, you almost never have to opt out of the type system in a dynamic language, but the static type system is very basic. In a language like Rust, you opt out semi-frequently (unsafe isn't common but it's certainly used more often than, say, JNI), and it can be hard to type some valid programs, but opting out is simple and the type system provides very strong guarantees. In a language like C, you never have to opt out of the type system, and the annotation burden for a well-typed program is minimal, but the type system is unsound--being well-typed guarantees essentially nothing in C.

All languages fall somewhere along this spectrum, including Go. It's just a question of what tradeoffs you're willing to make.

Re: Fearless concurrency with Rust

#86

Post by lambda »

Animats wrote: post #12

Rust's ownership model, and the borrow checker that enforces it, are a major breakthrough in language design. It's so simple, yet it solves so many problems. This is what Go should have done. Then Go's "share by communicating, not by sharing" would be real, not PR. Go code often passes references over channels, which results in shared memory between two threads with no locking. In Rust, when you do that, you pass own…

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 sooner; by having a much simpler type system, and less ambitious concurrency story, Go has been ready to use and build up a library ecosystem for many years now, while Rust is only just now hitting stability to the point where you can write code and not have it break if you don't constantly keep it up to date with the latest nightly.

So, I think that they are both valid strategies. There has been lots of good code written in languages which don't provide as many safety guarantees or as strong a type system as Rust has; it's not an absolute requirement for all code to be written with such guarantees.

By staying simpler and not trying to solve as many problems, Go has been ready for production use for quite a lot longer, and I think that there are many things for which it is still simpler and easier to use.

That said, I do prefer Rust now that it's actually hitting a stable and usable state. I wish it had been ready sooner, but that's the price you pay for needing a lot of time on iterating on how to make these stricter semantics actually usable in practice.

Re: Fearless concurrency with Rust

#87

Post by sanderjd »

tomjakubowski wrote: post #76
ajross wrote: post #71

Earlier quoted context omitted.

A managed heap; emphasis on the use of functional constructs; rejection of lots of previously-thought-to-be-essential OOP features; built-in concurrency based on a rejection of the traditional primitives; general de-emphasis of metaprogramming constructs like templates and macros; broad design emphasis on preventing common programming mistakes. You're saying, I think, that the Go implementation and runtime looks more…

> A managed heap I'm not sure what you mean by this, but when I hear "managed heap" I think of heap memory managed by a garbage collector. This is not a feature of Rust. > emphasis on the use of functional constructs Rob Pike wrote (unavoidably, because of the lack of generics) crippled versions of map and reduce for Go and declared that the almightly for loop was superior. I don't think an emphasis on the use of fun…

On the rejection-of-OOP thing; I agree that seems like the biggest similarity between Go and Rust, but even then, the major replacements for those features are completely different – Rust's traits are more like typeclasses and C++ templates (to some extent) than they are to Go's interfaces (though "trait objects" are like interfaces, but used less often). It also seems like Rust will eventually add some form of more traditional OOP features like inheritance, because the servo project would like such things to implement the DOM (and I think others are also interested for different reasons), which I doubt Go will ever do.

Re: Fearless concurrency with Rust

#88

Post by steveklabnik »

sanderjd wrote: post #87
tomjakubowski wrote: post #76

Earlier quoted context omitted.

> A managed heap I'm not sure what you mean by this, but when I hear "managed heap" I think of heap memory managed by a garbage collector. This is not a feature of Rust. > emphasis on the use of functional constructs Rob Pike wrote (unavoidably, because of the lack of generics) crippled versions of map and reduce for Go and declared that the almightly for loop was superior. I don't think an emphasis on the use of fun…

On the rejection-of-OOP thing; I agree that seems like the biggest similarity between Go and Rust, but even then, the major replacements for those features are completely different – Rust's traits are more like typeclasses and C++ templates (to some extent) than they are to Go's interfaces (though "trait objects" are like interfaces, but used less often). It also seems like Rust will eventually add some form of more…

Related, http://programmers.stackexchange.com/questions/247298/how-ar... is really good.

Re: Fearless concurrency with Rust

#89

Post by f2f »

elektronjunge wrote: post #82
dilap wrote: post #64

Earlier quoted context omitted.

"Should have done" is a silly phrase to use here -- Rust is attempting to advance the state of the art, Go was attempting to use only very-well-understood ideas to make a very-well-understood, simple language. Perhaps some day we will see a successor language that follows the philosophy of Go using the new stuff we understand thanks to Rust.

> 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.

Re: Fearless concurrency with Rust

#90

Post by Ygg2 »

jbandela1 wrote: post #55
carllerche wrote: post #15

Rust has definitely been a pleasure to work with. I have been experimenting with a Future & Stream [1] abstraction in Rust that would allow easily describing complex concurrent and async operations and to allow easy composition, not unlike ES 6 promises. The interesting thing is that, thanks to Rust's ownership system, it is easy to discover when handles to a future value go out of scope. This allows the library to r…

Just looked at eventual. It seems really interesting. I looked at Rust's std Future and was turned off by the fact that is blocking.

Rust is blocking, there was mio crate which brought non-blocking IO operations.
Post reply on HN