This is so cool, and I love that Rust is being so heavily driven by the pragmatic needs of an ambitious project like this. As a systems guy, Rust is the most excited I've been about a new language in years.
Yes, Rust is very promising especially if you look for better alternatives for C++. I wish it would stabilize and someone could write an in depth and well structured book on it. I have easier time learning languages that way, when ideas are explained and well presented, rather than deducing it all from very lacking documentation. In case of Rust it's even more difficult since it's packed with new ideas.
Let me first say I really loved your Rust intro and I'll be buying any new book you produce.
Question: are there any moderate-sized codebases (ie not Servo, not Rust itself) that can be used to show idiomatic Rust? In my own experimentation (a simple image utility to resize images and convert to b&w), I ended up writing it a lot like I would C, which I know isn't correct based on snippets I've seen. Or rather, it's correct in that it works, but it's not particularly idiomatic and the Rust elite would sneer at me.
It's like the early days of C++ when people were writing it as "C with classes", complete with pointers everywhere, malloc, etc. A lot of that could have been mitigated with some easily digestible source that clearly demonstrates the idioms. Maybe a small game, a simple text editor, etc.? Does anyone know of anything like this? Or is it too soon for this?
Thanks. I am currently finishing up "Rails 4 in Action" and "Designing Hypermedia APIs," which I've both been working on for far too long. In this sense, I don't mind that Rust isn't ready for a full book. ;)
I am not entirely sure that 'idiomatic Rust' is something that's fully figured out yet. Rust itself is _certainly_ not idiomatic, as it's a hodge-podge of several historical coding styles.
As I said when I spoke at the Bay Area Meetup, my position in Rust is 'eternal newbie,' so I'm not actually the best one to ask here. Maybe pcwalton can chime in.
As you know, Real Programmers can write FORTRAN in any language.
But, do we want to?
No, we want to learn what is new and useful in a new language. We want to learn how to make best use of that language.
That doesn't mean writing code that looks just like the language we used before. What would be the point of using a new language, then?
No one cares what the "Rust elite" think. Didn't you see that that was just a humorous throwaway comment following a much more important point: writing idiomatic code.
Learning to write idiomatic code helps us see what is new and useful in any language.
We won't learn that by writing FORTRAN in the new language.
But seeing how experienced users write their code is a great way to see what is good and interesting about the language.
> Yes, Rust is very promising especially if you look for better alternatives for C++.
Go kind of wanted that prize. It didn't quite get it.
Many will say how they care about cool features, built-in concurrency, nice stuff and in the end, when comes to releasing product if performance isn't there, it won't replace C++.
Some program in C++ because they love the language. They really do. There are people like that, I've met one, once. Quite often others do it because the rest of their world does (libraries, coworkers) and performance.
The niche were performance matters (and I understand that is a loaded word so to speak) is going to be hard to get into.
Go was never supposed to replace C++, it was supposed to replace Java in server applications. Happily it seems Python and Ruby developers are finding good use in Go too.
How was a garbage collection language ever supposed to take the place of a manual memory management language? The area that C++ shines in is systems programming, and you can't do that with Go, because of garbage collection. Rust on the other hand, is precisely made for systems programming.
I do like C++, have my bookshelf full of C++ books and magazines since the C++ ARM days, still follow C++ standard even if I nowadays tend to spend more time with other languages.
> Many will say how they care about cool features, built-in concurrency, nice stuff and in the end, when comes to releasing product if performance isn't there, it won't replace C++.
That's why Rust is about zero-cost abstractions, period. Unlike almost every other new language (for example, Go), we don't accept abstractions that compromise performance.
This is an article about Servo. We care about performance for Servo—along with safety, performance is Servo's entire raison d'être. Much of the focus on performance in Rust is motivated by the desire to build an engine that's faster—not just "as fast as" or "within the ballpark of", faster—than the existing C++ engines.
Go doesn't address concurrency design deficiencies of C++ in any way, while Rust does. So I don't see Go as a next generation successor, but Rust really looks that way.
I like C++ personally for its power and keeping performance accessible (especially with new developments of C++11 and beyond). And looking at new alternatives, Rust looks more like a successor to me than Go. As others pointed out, Rust doesn't enforce garbage collection, while Go does. For example if someone would want to write a demanding game, they wouldn't do it with garbage collection enforced language.
