A 30-minute Introduction to Rust
doc.rust-lang.org
doc.rust-lang.org
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 think it's great what Rust could potentially offer software developers. But it's still pretty theoretical at this point. The language and standard libraries aren't sufficiently stable enough for serious, long-term use, currently. I hear we may start to see the beginning of such stability at the end of the year, but until it actually happens, Rust isn't very useful, while C++ is.
C++ gives you immense power and a huge range of functionality to choose from, and some of the complexity arises from this. It has a very long history, which also contributes to the complexity. And it's first and foremost a pragmatic language, which of course brings in some complexity in order to deal with the inherent complexity of reality.
If something is seen as "complex" in C++, there's usually a good, or at least understandable, reason for this. You can usually find technical documents or discussion that justify why things are they way that they are, and the reasoning is usually quite sound. And in many cases, it's possible to safely ignore or just not use large portions of the complexity that C++ offers without facing any sort of a penalty or harm.
It's very different from the complexity that languages like JavaScript or PHP bring. The complexity there is usually unjustifiable, and often due to very rushed work, a lack of understanding and poor design, or a lack of care and consistency. They suffer from serious flaws and complexity that were not justified when introduced, and were subsequently not cleaned up or fixed once recognized. They suffer from harmful complexity, while C++ offers beneficial complexity.
I don't think the parent post was trying to say C++ was necessarily bad, but the features of C++ being justifiable or not don't really impact my feeling of it being daunting, or terrifying to learn. I could say, with reasonable certainty, that every part of a space shuttle launch probably has a good reason for being there, but the system taken as a whole is still intimidating. It's that C++ is a huge beast and there's just so much there. I haven't gone hard core at looking into C++, but every time I do people start of by saying you need to pick a sane subset of the language to work with, and they all have different views of what is and isn't sane. Add to that the fact that you can do some potentially scary stuff when you're close to the hardware, and I can see why it would be a bit scary.
In my view, the right way to approach that, if I were really trying to learn the language, would be to just pick a guide and go with the assumptions it makes until the reasoning for those assumptions becomes more clear and I can better pick and choose according to my use case. But it's still an intimidating proposition.
I'm also guessing that something like Javascript is less terrifying because of previous experience with dynamic languages. The kind of foot-shooting you do in javascript (because of accidental global scoping, poor equality semantics, or any number of things) at least make sense in the context of having programmed in a dynamic, managed language previously. C and C++ can be pretty scary when everyone talks about manually managing memory or being close to the metal or saying stuff about 'systems programming', which just sounds like crazy voodoo if you don't have a point of comparison.
I think the things your saying are all true. Just trying to offer my perspective as to why, those things being true, a language can still be scary to approach. fwiw
Given the practical history of C++ implementations, this may be rather optimistic... Though it does seem to be calming down a bit. Unfortunately, my first real work with C++ was with GCC2.96 (the phantom Redhat version of GCC); scarred me for life :)
I think you're overreacting here - somebody barely mentions a language and you immediately start praising said language for features not even needed in this particular person use cases.
Short-term and long-term stability are needed for just about any serious software application or system. They're useful to have even for short scripts that might be reused later on.
And he said he was "terrified" by C++. I explained why he shouldn't be. I'm not sure why you're getting worked up over that.
I'm not! And I agree with all your points here. It's just that this is not a thread about C++, but about Rust, and about solving small puzzles with it for that matter. Which makes both original mention of being "terrified by C++" and your explanation a bit off-topic. I won't downvote you or anything, I just wanted to point this out.
It's so easy to do it the wrong way, and there's so many examples of badly written or non-idiomatic C++ code strewn all over the internet that a newbie is bound to fall into that trap. This is the same kind of problem I (used to) see with PHP, that it can be fine if you do it all the "right way" and don't do "stupid stuff" but it takes a while to learn what those are. What happens in reality is they google "how to do x", copy paste the code, and modify. Who cares if it's idiomatic or anything.
This doesn't strike me as a 30 minute intro to Rust. More like a quick guide to what sets Rust apart from C. Perhaps my expectations would be different with a different title ("How Rust can benefit you as a working C++ dev")
Hmm yes, I will think about it. Ownership is Rust's most important and unique concept, so an intro to ownership _is_ an intro to Rust. I will think about how to make this more clear.
Thanks for writing this! I think it was a solid step in the direction of clearly explaining ownership. I know more than I did before and I'm looking forward to reading your next piece on it.
Good work.
The URL to watch is http://doc.rust-lang.org/guide.html . I'm working on it every day. Two more sections should land tonight, and I'm writing the next one as we speak... don't hesitate to ping me with ways the docs could be better, either on IRC, email, or just opening an issue on the repo and CC'ing me.
On the other hand, the writing style is way too "cute". It is legitimately distracting to see all these "Hooray!" and "Wait, whaaaat?" and "Not too shabby! I love eliminating mutable state.". It's unhelpful at absolute best.
Otherwise - thank you very much for this. Your docs are undeniably crucial for the adoption of Rust and they're extremely helpful.
And you'll be happy to hear my contract includes examples for _everything_ in the stdlib, so get ready for more of those!
Oh, and we had a big discussion last time: https://news.ycombinator.com/item?id=7051835
EDIT:
concurrency.rs:12:20: 12:27 error: use of moved value: 'numbers'
(It's worth noting that often the compiler is complaining because it actually isn't safe.)
There are certainly some valid things that the compiler will forbid which you then need to work around instead, but by and large I trust the compiler to be right more than I trust myself.
(Bear in mind, still, that these sorts of arguments of Rust’s superiority in such things are frequently only applicable for comparisons with languages like C++; often they are the sorts of things that a managed language would not have a problem with, though also not infrequently it would lead to things like data race.)
This is very true. And one of the culprits is a lack of modules, an shortcoming that Rust avoids. A module system for C++ is grossly overdue, and I'm not holding my breath that one will be forthcoming.
I'm not trying to be argumentative. I've seen this "C++ doesn't have modules" claim before, and I'm trying to get my mind around it.
Here read this:
This is a pretty ridiculous and highly inefficient way of doing things (Facebook improved compile times by crafting a server just to do the preprocessing for you).
That being said, C++ doesn't have even the bare minimum of what would be considered a module system according to any definition. With a lot of hand waving, one should be able to more or less write:
import std::vector;
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.
> 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.
I ask because the largest test case for Rust, Servo, is a cross-platform application, and I'm always looking to improve our marketing.
Having said that, immature libraries are to be expected at this point, and I do think Rust is very well positioned to have really good ones for this use case in the short to medium term.
This is absolutely true, but that's a different concern than "It would seem that neither Rust nor Go serve this area and probably do not intend to do it either," which is what I'm curious about.
One of the open questions with GUI toolkit stuff is that Rust does not have named parameters, but Qt, for example, uses them heavily.
To give you some background about the kind of apps I was referring to - I am right now working on a UI-driven app that will be deployed to Android and on the desktop. I am using C++, Qt and platform code where necessary.
All of those things are being built yet, so we don't have much to link to. There are a few work-in-progress things, for example, the postgres adapter is coming along, and rust-graphics for graphical primitives. As we get closer to release, and as they mature, we'll feature them more.
> Will the cross-platform components from Servo be included in the Rust standard library?
As we already have a package manager, I think Rust will tend to have a smaller standard library, and encourage its use more. We'll see though.
> am right now working on a UI-driven app that will be deployed to Android and on the desktop.
We support Windows, Mac, and Linux as first-class platforms, and every pull request (and additions are all through pull requests) is tested on android. iOS coming soon.
This doesn't seem very performance-critical. I doubt the best tool for the job is C++/Rust/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.
They probably think they aren't, but by definition, we are not smart enough to immediately understand the bugs we write. Otherwise we wouldn't write them.
But hey, it's not like a programmer who overestimates his own skills is a new thing.
What are concepts in this context? It is hard to google.
I've pinged #rust, I'll see if I can get someone who knows more to answer here.
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.
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!
I can't wait for Rust to be "done" (and get some kick-ass HTTP support).
let x = ~5;
let y = @5;
let x = box 5;
let y = box(Rc) 5;
> and get some kick-ass HTTP support
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.
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.
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.
Other than that, it's considerably easier than other non-managed languages (e.g. C, C++, Pascal)
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.
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.
Another significant one is that Erlang has been used to make some of the most reliable software ever for the past few decades, and Rust is still pre-1.0.
Riak, CouchDB, RabbitMQ, and SimpleDB are written in Erlang. These are mission critical, mature projects.
[1]: http://stackoverflow.com/questions/8426897/erlangs-99-999999...
My understanding is that Erlang is still primarily used in the telco industry, as it's name implies. In general Erlang shines in doing most software that would run on a server for long periods of time when interruption is expensive (it includes the ability to hot-patch running processes, for example).
Use of a GC is problematic for soft real-time systems (interestingly enough, it can become useful again in hard-real-time systems but that's too long of a tangent here). In rust you can completely ignore the GC just by choosing to not use it. The ease of getting raw-pointer access in rust also indicates places it could be used (I feel like I could write a bare-metal application in a subset of rust with a lot less work than doing so en Erlang).
It used to be that resources were so constrained that the entire OS would be written in a combination of assembler, and something slightly higher level (most commonly C, other times a reduced set of sine other high-level language). This meant that those languages were system languages. Nowadays, writing all but the kernel and drivers in something much higher level has become feasible, so the term "systems language" has blurred in meaning.
Many hard real-time systems already operate with an excess of CPU power in order to simplify analysis of scheduling. Furthermore you are already bounding things like allocations, and a simple incremental GC that runs on a timer tick can guarantee to run in fixed time if you have bounded allocations per timer-tick.
All of this is somewhat moot though as many hard real-time systems completely eschew dynamic allocations.