I've only ever used GCed (and largely dynamic) languages up until now (Python, JS and Clojure primarily); C is alien and C++ is frankly terrifying. With all that, I've been having a ball using Rust to solve Project Euler problems, with astonishing speed compared to what I'm used to.
It doesn't quite have all the libs you might want for general development yet, but for the things it's currently equipped for it's a lot of fun, and surprisingly easy. (Up until I find myself in a quagmire of lifetime problems of my own making. Looking forward to the coming lifetimes inference enhancement.) It's a surprisingly reasonable functional programming environment too.
Yes, it is a very powerful language and there can be a lot to it, but it shouldn't "terrify" you.
These days, it's generally quite easy to avoid much of its C heritage (including potential security pitfalls) if using the so-called "modern C++" techniques, but the extra power and flexibility is still there if you do ever need it. There are numerous ways of easily avoiding manual memory (or other resource) management, too. The STL and Boost, among numerous other libraries that are out there, offer lots of convenient, high level functionality. The portability of C++ code is often quite excellent, the language and its standard libraries are quite stable, and there are multiple commercial-grade implementations from numerous vendors/projects. You probably won't find anything else that gives you a high degree of performance along with high level abstractions, while also giving you the peace of mind that your code will still compile just fine years or even decades from now.
While it's certainly possible to to overboard and misuse C++ to a point where it causes serious problems, one of the best things about C++ is that it doesn't force you to do that. You generally don't pay for what you don't use, and it's certainly possible to use a very effective subset of the language much as one might use Java or C#, or even Python and JavaScript.
I'd say that C++ is even easier to use than JavaScript is. C++ is much more sensible in so many ways, and nowhere near as quirky or just outright broken in fundamental ways like JavaScript, while also providing at least some type safety and other compile-time checks.
If you want a stable, portable, safe, well-supported language that offers high level functionality without the performance tradeoffs of other languages, then I think that a modern subset of C++ could very well be exactly what you're looking for.
I would looooove any insight that you have on making the docs better for people who haven't done systems programming before. If you've ever got the time to type out a few thoughts, my email is in my profile.
I wrote this a while back as a blog post, it ended up being the actual intro. I hope to go over it again soon, and make it better. There's nothing super wrong with it, but you can always improve! Feedback welcome.
I gotta say, reading this actually made me really excited about Rust. C++ without the annoying memory management but no GC-overhead sounds like a dream.
Just to temper your enthusiasm, the compiler errors can sometimes be irritating, especially when you want to do something the you are pretty sure will be safe. But on the whole if you work with it the pay-off is well worth the minor annoyances. Having the compiler always check your code for memory safety is a huge win for refactoring - C or C++ code bases get really brittle over time as developers forget what is actually going on. I would also say that the number of errors you encounter over time reduce as you gain an intuition for the rules.
Anecdotally, Rust is the most joyful language to program in for me at the moment. I find that I can express powerful ideas in the type system, with deep confidence that the compiler will catch my mistakes, and a strong mental model of how my program will actually execute. I don't know any other languages that "feel" that way. Perhaps D or Nimrod would, but there's only so much time for new languages...
Out of curiosity I implemented the two examples in C++11.
For the number add I used a unique_ptr (although returning by value would be better in every way).
For the shared state I used async with a lamba that calls transform and returns the modified vector through a future. This doesn't execute in parallel for each for loop though. I think something like Arc can be coded in C++ too - template wrapper that returns a RAII lock whick unlocks on scope end.
I think the only big difference is that some errors in Rust are happening at compile time. In the first case the original buggy code was triggering only a warning in C++.
Right now the extra compile-safety of Rust is IMO not worth giving up the other benefits of C++, especially now that C++11 with some extra static checking and good guidelines can go a long way.
> Right now the extra compile-safety of Rust is IMO not worth giving up the other benefits of C++
I can't speak to everyone's use case, but for ours memory safety is extremely important. C++ is not safe, and we still see tons of memory safety issues, many security-sensitive, in practice, despite using modern C++ for all new code.
Even if safety isn't as important to you, there are other reasons you might be interested in Rust: a module system, pattern matching, a standard library which offers better performance than STL for many tasks, ADTs, concepts, a package manager, etc.
Box<T> is roughly equivalent to unique_ptr, and you're correct, returning by value would be better. Rust idiom is to use stack allocation and borrowing wherever possible.
> I think the only big difference is that some errors in Rust are happening at compile time.
This is true in these examples, except maybe the enforcement of not using a pointer after you've sent it to a task.
That said, there are other examples, like iterator invalidation, where Rust is completely memory safe, unlike C++. Furthermore, Rust has significantly less undefined behavior and odd edge cases. These are in C++ for good reason, but they're still there.
> with some extra static checking and good guidelines can go a long way.
They can go a long way, and that may be enough for you. Big applications continue to have security issues due to problems that Rust would prevent, though: in the last Pwn2Own, all of Firefox's bugs would not have been possible in Rust, for example.
This is Hacker News, so I'll explain it to you this way: this is specifically _not_ in depth. Have you ever done sales? The idea is that you need to figure out if your customer wants to buy as quickly as possible, and if they don't, move on. If they do, _then_ you move into the longform stuff. If your customer isn't going to buy, it wastes both you and their time.
The idea of this short introduction is to split you into one of two camps: "I want to know more about Rust," or "ewww." If you're in camp one, heading over to the tutorial or Rust by Example is great!
Wow, is Rust ever changing quickly. I think I read some docs a few months ago and most of this was different. It's gotten better though. All that punctuation for different pointer types was a bit too much. And this way of using mutexes as accessors that unlock automatically when they leave scope is brilliant.
I can't wait for Rust to be "done" (and get some kick-ass HTTP support).
Is the language stable enough to learn yet (given that I won't be really using it immediately)? I've been putting off looking at it because it seemed very much in flux.
For learning I would say it is. The biggest thing at the moment is API changes. But the team is now pushing to put stability attributes on all modules and marking deprecated items as such for a time before their removal (these emit warnings if used).
I would highly recommend using the nightlies from http://rust-lang.org/. A list of the docs can be found here: http://doc.rust-lang.org/index.html Reddit is also good for keeping up to date on news: http://www.reddit.com/r/rust Also, IRC is your friend! Join #rust at irc.mozilla.org, and feel free to ask questions. The community is very friendly and willing to help.
There is a very special fun in learning Rust. It isn't stable in the sense that your code from last week will compile this week. On the other hand, it is currently stable enough that all the major concepts are there and most changes are either syntax or API. So reading up on the changes of last week and some search and replace cover most things. Also, most API changes now are introduced through deprecations. All breaking language changes have an RFC process.
The great thing is to see a language while it is still being shaped. Have something you don't like or something that is incredibly clunky? Get involved! The barrier will never be lower. Backwards compatibility is not a thing yet! If the change makes sense and you can muster the resources for it, there is no one holding you back. Code review for pull requests is also awesome, all of my pull requests were accepted on the second or the third try - but for the better!
On top of that, it is a really interesting language on it's own right with interesting concepts worth learning.
How much cognitive overhead is it to think about ownership all the time once you get used to it ? Coming from a GC-languages background I had a hard time thinking in those terms last time I played with it. I ended up having .clone() littered all over the place :)
I don’t find that I need to think about it often at all. And very often I can get away with thinking about it less than I should, because if I make a mistake, the compiler will pull me up short. ☺
When writing libraries, you will typically need to think about ownership more frequently than when writing applications, but it’s normally not at all problematic.
I find that it's no more mental overhead than it is in C. The nice thing is that the development cycle ends up being faster than C for me because I don't have to spend as much time in front of the debugger.
I like this a lot, the right level to get an idea of what Rust is about.
The last example illustrates that concurrency is complex no matter what language you use - the code ends up reflecting the scaffolding enabling concurrency and the actual work ends up buried inside.
Who is "behind" Rust? A company, consortium, academics, BDFL? http://www.rust-lang.org/ doesn't have an about page. Didn't see answer listed in the FAQ.
Mozilla is behind most of it. The original creator has already left the project, so we don't have a BDFL. There is a core team, mostly of Mozilla employees. Tilde has been contracted to do the package manager, I have been contracted to do documentation. There's a pretty significant community for a language so young, our IRC channel has ~600 people in it.
Mozilla is the big driving force, with a small, dedicated group of developers from Mozilla doing a huge amount of the boring 'grunt work', and also making the hard decisions when it comes to design. The community is a huge driving force though, with lots of great contributions being landed all the time.
As someone fairly new to systems programming, I can still see why you'd want to pick a language like Rust over C. But can someone explain to me the difference between Rust and Erlang? They are both system languages, no? Erlang is much more established. But what are the key differences? And I'd ask, "which should I learn?", but that is generally not a great question...
[+] [-] mattdw|11 years ago|reply
It doesn't quite have all the libs you might want for general development yet, but for the things it's currently equipped for it's a lot of fun, and surprisingly easy. (Up until I find myself in a quagmire of lifetime problems of my own making. Looking forward to the coming lifetimes inference enhancement.) It's a surprisingly reasonable functional programming environment too.
[+] [-] Pacabel|11 years ago|reply
Yes, it is a very powerful language and there can be a lot to it, but it shouldn't "terrify" you.
These days, it's generally quite easy to avoid much of its C heritage (including potential security pitfalls) if using the so-called "modern C++" techniques, but the extra power and flexibility is still there if you do ever need it. There are numerous ways of easily avoiding manual memory (or other resource) management, too. The STL and Boost, among numerous other libraries that are out there, offer lots of convenient, high level functionality. The portability of C++ code is often quite excellent, the language and its standard libraries are quite stable, and there are multiple commercial-grade implementations from numerous vendors/projects. You probably won't find anything else that gives you a high degree of performance along with high level abstractions, while also giving you the peace of mind that your code will still compile just fine years or even decades from now.
While it's certainly possible to to overboard and misuse C++ to a point where it causes serious problems, one of the best things about C++ is that it doesn't force you to do that. You generally don't pay for what you don't use, and it's certainly possible to use a very effective subset of the language much as one might use Java or C#, or even Python and JavaScript.
I'd say that C++ is even easier to use than JavaScript is. C++ is much more sensible in so many ways, and nowhere near as quirky or just outright broken in fundamental ways like JavaScript, while also providing at least some type safety and other compile-time checks.
If you want a stable, portable, safe, well-supported language that offers high level functionality without the performance tradeoffs of other languages, then I think that a modern subset of C++ could very well be exactly what you're looking for.
[+] [-] steveklabnik|11 years ago|reply
[+] [-] steveklabnik|11 years ago|reply
Oh, and we had a big discussion last time: https://news.ycombinator.com/item?id=7051835
[+] [-] letstryagain|11 years ago|reply
EDIT:
Is this a compile-time or a run-time error?[+] [-] XorNot|11 years ago|reply
[+] [-] bjz_|11 years ago|reply
[+] [-] sanderjd|11 years ago|reply
[+] [-] blub|11 years ago|reply
For the number add I used a unique_ptr (although returning by value would be better in every way).
For the shared state I used async with a lamba that calls transform and returns the modified vector through a future. This doesn't execute in parallel for each for loop though. I think something like Arc can be coded in C++ too - template wrapper that returns a RAII lock whick unlocks on scope end.
I think the only big difference is that some errors in Rust are happening at compile time. In the first case the original buggy code was triggering only a warning in C++.
Right now the extra compile-safety of Rust is IMO not worth giving up the other benefits of C++, especially now that C++11 with some extra static checking and good guidelines can go a long way.
[+] [-] pcwalton|11 years ago|reply
I can't speak to everyone's use case, but for ours memory safety is extremely important. C++ is not safe, and we still see tons of memory safety issues, many security-sensitive, in practice, despite using modern C++ for all new code.
Even if safety isn't as important to you, there are other reasons you might be interested in Rust: a module system, pattern matching, a standard library which offers better performance than STL for many tasks, ADTs, concepts, a package manager, etc.
[+] [-] steveklabnik|11 years ago|reply
> I think the only big difference is that some errors in Rust are happening at compile time.
This is true in these examples, except maybe the enforcement of not using a pointer after you've sent it to a task.
That said, there are other examples, like iterator invalidation, where Rust is completely memory safe, unlike C++. Furthermore, Rust has significantly less undefined behavior and odd edge cases. These are in C++ for good reason, but they're still there.
> with some extra static checking and good guidelines can go a long way.
They can go a long way, and that may be enough for you. Big applications continue to have security issues due to problems that Rust would prevent, though: in the last Pwn2Own, all of Firefox's bugs would not have been possible in Rust, for example.
[+] [-] Demagog|11 years ago|reply
This is much more in depth + possibility of running code on site. I don't understand why rust site doesn't have links to this project.
[1] http://rustbyexample.com/
[+] [-] steveklabnik|11 years ago|reply
This is Hacker News, so I'll explain it to you this way: this is specifically _not_ in depth. Have you ever done sales? The idea is that you need to figure out if your customer wants to buy as quickly as possible, and if they don't, move on. If they do, _then_ you move into the longform stuff. If your customer isn't going to buy, it wastes both you and their time.
The idea of this short introduction is to split you into one of two camps: "I want to know more about Rust," or "ewww." If you're in camp one, heading over to the tutorial or Rust by Example is great!
[+] [-] dbaupp|11 years ago|reply
[+] [-] pkulak|11 years ago|reply
I can't wait for Rust to be "done" (and get some kick-ass HTTP support).
[+] [-] steveklabnik|11 years ago|reply
> and get some kick-ass HTTP support
http://arewewebyet.com/
[+] [-] shawkinaw|11 years ago|reply
[+] [-] bjz_|11 years ago|reply
I would highly recommend using the nightlies from http://rust-lang.org/. A list of the docs can be found here: http://doc.rust-lang.org/index.html Reddit is also good for keeping up to date on news: http://www.reddit.com/r/rust Also, IRC is your friend! Join #rust at irc.mozilla.org, and feel free to ask questions. The community is very friendly and willing to help.
[+] [-] Argorak|11 years ago|reply
The great thing is to see a language while it is still being shaped. Have something you don't like or something that is incredibly clunky? Get involved! The barrier will never be lower. Backwards compatibility is not a thing yet! If the change makes sense and you can muster the resources for it, there is no one holding you back. Code review for pull requests is also awesome, all of my pull requests were accepted on the second or the third try - but for the better!
On top of that, it is a really interesting language on it's own right with interesting concepts worth learning.
[+] [-] zimbatm|11 years ago|reply
[+] [-] chrismorgan|11 years ago|reply
When writing libraries, you will typically need to think about ownership more frequently than when writing applications, but it’s normally not at all problematic.
[+] [-] pcwalton|11 years ago|reply
[+] [-] aidenn0|11 years ago|reply
Other than that, it's considerably easier than other non-managed languages (e.g. C, C++, Pascal)
[+] [-] zwieback|11 years ago|reply
The last example illustrates that concurrency is complex no matter what language you use - the code ends up reflecting the scaffolding enabling concurrency and the actual work ends up buried inside.
That said, I like what I see.
[+] [-] njharman|11 years ago|reply
[+] [-] steveklabnik|11 years ago|reply
[+] [-] bjz_|11 years ago|reply
[+] [-] peaton|11 years ago|reply
[+] [-] aidenn0|11 years ago|reply
I'm not super familiar with Erlang, so I may get some things wrong, but heres a few differences:
Erlang prefers GC, wheras Rust tends to eschew it (it's available in a library).
Erlang is dynamically typed where rust is statically typed.
Erlang is single-assignment where rust uses a somewhat more nuanced lifetime system (though that is still changing).
Erlang prefers communication over channels, while rust has immutable types that are safe to share.
[+] [-] geoffroy|11 years ago|reply
[+] [-] unknown|11 years ago|reply
[deleted]