A 30 minute introduction to Rust

http://words.steveklabnik.com/a-30-minute-introduction-to-rust

by steveklabnik • 13 years ago

328 156 13 years ago

words.steveklabnik.com

steveklabnik33• 13 years ago

I like the overall structure, but I'm not sure about throwing so much syntax without explaining it in detail.

bcbrown• 13 years ago

I've only written a little C and C++, about six years ago, but enough to understand the syntax well enough to understand C and non-templated C++ code. The introduction was at just the right level for me, and I didn't have any problems with the syntax.

I think it's well written, and it makes me interested in learning more about Rust. The one thing I'd like to have seen addressed is type inference.

Also, you don't credit the original author.

steveklabnik33• 13 years ago

Great, thank you.

"This excellent presentation" is a link.

ash3• 13 years ago

From the article:

But wait, how is that possible? We can’t both allow and disallow mutable state. What gives?

I had to re-read the above a few times. And still don't get it. Steve, what do you mean with it? Are you talking about how are Arc/RWArc implemented? Or is it something else?

steveklabnik33• 13 years ago

The previous sentence is "We gain the efficiency of shared mutable state, while retaining the safety of disallowing shared mutable state."

I also wasn't sure about the part you quoted, but I was trying to explain that it's not that Rust _doesn't_ allow shared mutable state, it's that while the language doesn't, you can use unsafe to build safe abstractions, so in practice, it does. Hmmm.

ncallaway• 13 years ago

I actually liked the amount of detail in explaining the syntax. For the most part, the code samples are very readable and understandable as they are (and I haven't written any Rust).

I think explaining a lot of the syntax would have made this more of a "how to Rust" article, rather than a "why to Rust" article. I really appreciated the "why to Rust" tone of this article, and it provides a great explanation of why the language is different from C / C++ and why I should care.

steveklabnik33• 13 years ago

Excellent. Thank you.

It's hard to have a beginner's mindset after you've done something for a year.

scott_s3• 13 years ago

I think the amount of syntax you've shown is fine. Since there's C++ and Rust code that both do the same thing, it allows readers familiar with C++ to infer what the Rust syntax means. This is a much quicker process than reading "Here's how you write an if clause ..." prose.

When it comes to showing new languages to experienced programmers, I prefer showing code, and explaining what it accomplishes. Experienced programmers will start building up a Bayesian model of the syntax without being explicitly told.

I think of this as the "Dive Into Python" approach: http://www.diveintopython.net/

pcwalton7• 13 years ago

I like this tutorial because dives straight into the most unique/unfamiliar parts of Rust (ownership/references) and gets them out of the way. It's a "learn the hard way"-style tutorial, and I think that's the best approach. Once you learn how ownership and borrowing work, along with ARCs and concurrency, everything else is really simple and just naturally falls out.

haberman• 13 years ago

Agreed. I'd love to see an even more in depth document that takes a wide range of ownership/allocation patterns that are common in C and C++, shows Rust equivalents, and analyses why Rust can or cannot prove that they are safe (i.e. whether they require unsafe blocks or not). I don't have an intuitive sense yet for the boundaries of what Rust can automatically prove safe. How much C and C++ could be directly translated into safe Rust and how much would need to be reworked or put in unsafe blocks?

patrickaljord• 13 years ago

Thanks for the the tutorial! Rust seems a bit too complex to me. Like a C++ on steroid that wants to do and be everything. Nothing wrong with that but not my cup of tea. I'd rather stick to C if I need tight memory management, it is way simpler and straight forward. And if I need concurrency, I'll stick to Golang (or erlang). Really, it's such a pleasure to read some golang after reading this 30 minutes of Rust. Anyway, just my opinion.

duaneb• 13 years ago

I would argue that rust is both simpler and more consistent than either C or C++. No preprocessor, no pre/post increment, a real type system (instead of templates)—there's just not the mountain of undefined parts of the language that tends to be a large problem. Scala, in spite of being on a VM, is far closer to C++ IMHO in terms of attitude.

I actually find golang harder to read without parametric types (sans built-in slices and maps).

steveklabnik33• 13 years ago

I'd rather stick to C if I need tight memory management, it is way simpler and straight forward.

Well, if you don't want your C to segfault, you have to understand these concepts anyway, they're just implicit to the language. C's memory management may be simple, but it's surely not easy.

pcwalton7• 13 years ago

Rust seems a bit too complex to me. Like a C++ on steroid that wants to do and be everything.

No, that's explicitly not a goal. The goal is to enable zero-cost abstractions and memory safety. Everything here is in service of that goal.

I'd rather stick to C if I need tight memory management, it is way simpler and straight forward.

The problem is that the "simple and straightforward" model of C leads to a lot of very not-simple-and-straightforward time in front of Valgrind to get the program to work, or worse, to fix security vulnerabilities.

pjmlp8• 13 years ago

C if I need tight memory management, it is way simpler and straight forward

If you work alone yes. Good luck on a 50+ developer team size, with high atrition rates.

masklinn5• 13 years ago

Like a C++ on steroid

Rust most definitely isn't "like a C++ on steroid" from a complexity standpoint. It tries (and — I think — mostly succeed) to be a significantly simpler and more coherent language.

It does make things which are implicit in C or C++ (e.g. ownership) explicit. That's a good thing, you need to know your ownership in C or C++, the language just doesn't help you much.

azth• 13 years ago

Really, it's such a pleasure to read some golang after reading this 30 minutes of Rust.

Incidentally, I find reading Go to be much more verbose and even heaver cognitively compared to reading Rust code.

danso• 13 years ago

A little OT...but what's with Svbtle's apparent default styling of links? There's no indication that any particular word or sentence contains a link, which basically makes those links invisible to readers. Or do lots of people read web articles by randomly hovering the mouse around the text?

But relevant to the OP...I generally try to save useful tutorials like this on my pinboard, which often doesn't pick up the meta-description text. So I double-click to copy the first paragraph and paste it into pinboard...except in the OP, I kept on clicking on text that was hiding links underneath.

It's a strange UI decision, and one that seems to discourage the use of outbound links...if you can't see the links, then what is the purpose of them? For spiders?

steveklabnik33• 13 years ago

Yeah, I think that they have been made lighter recently. Bummer :/

Zecc• 13 years ago

There's no indication that any particular word or sentence contains a link

There is a subtle grey underline, which I'm sure can be nearly invisible depending on your screen.

kibwen5• 13 years ago

Allow me to save everyone from opening their devtools:

  background-color: #FFF;
  border-bottom: 2px solid #F4F4F4;

In RGB, that's the difference between 255 and 244. It's more than a little absurd.

tptacek4• 13 years ago

This isn't so much an introduction to Rust as it is an introduction to Rust's concurrency model.

The example of returning a reference to an automatic variable isn't super compelling, since every competent C/C++ programmer knows not to do it. That bug does pop up every once in awhile, but almost always in the context of a function that returns a reference to one of many different possible variables depending on some condition in the function.

Does Rust really call its threads "green threads"? Green threads have a weird reputation.

Copy like "this allows you to, well, read and write the data" could be tightened up; it's an attempt at conversational style that doesn't add much. "That doesn't seem too hard, right?" is another example of the same thing.

How much of Rust concurrency is this covering? How much of its memory model? Does the whole concept of Rust concurrency and memory protection boil down to "the language provides an 'unsafe', and then people write libraries to do things with it"?

lmm• 13 years ago

Green threads are the standard term for language-level threads that are not OS-level threads.

steveklabnik33• 13 years ago

Salespeople qualify leads by determining if you're ready to buy or not. If you're not, they stop wasting time on you. The general idea for a quick introduction is to qualify your lead. So this isn't a "introduction to Rust's syntax" it's "an introduction to why you should (or should not) care about Rust."

since every competent C/C++ programmer knows not to do it.

Everyone knows, yet programs still segfault. The point is that the language helps you be competent. Static analysis is very useful.

Does Rust really call its threads "green threads"? Green threads have a weird reputation.

I agree. Rust has N:M mapped threads by default, but recently added 1:1 as well.

it's an attempt at conversational style that doesn't add much.

I happen to write like I talk, it gets good and bad reviews. A more neutral style would be more appropriate if/when this gets pulled into Rust itself, thanks, that's a great point.

Does the whole concept of Rust concurrency and memory protection boil down to "the language provides an 'unsafe', and then people write libraries to do things with it"?

I think this is an unfair characterization, but I gave it to you, so that's a criticism of me, not you. I tried to point out that unsafe exists for exceptional cases only: it's not something that you need unless you're doing something dangerous for a specific reason. I personally have only ever written unsafe when wrapping something with FFI.

Introductions are hard because you never know how much depth to go into; maybe I should go into these bits a little more in depth.

Thanks for the great feedback. :)

tptacek4• 13 years ago

Oh, don't get me wrong, I'm sold on memory protection as a type system feature. I'm just suggesting that the example you're using might make it sound less valuable, because returning stack variable references isn't the most common kind of error made by C programmers; when you do that, more often than not your program doesn't work at all.

crusso• 13 years ago

I happen to write like I talk, it gets good and bad reviews.

There's nothing wrong with writing casually for a web page that is meant to be inviting to newcomers.

I've ignored Rust links on HN until the subject of your link got me to take a look. The style was fine and you did a good job in at least showing a few snippets of code while advocating the benefits of the language.

Contrary to tptacek's criticisms, I wasn't looking for a dry or comprehensive manual - just something to read in a couple of minutes that would give me an indicator of whether or not I should look further into the language.

Thanks for the article.

scott_s3• 13 years ago

A conversational style is fine, but those particular sentences actually get in the way. The style comes from the overall tone of the writing, not just sentences which talk to the reader directly.

politician• 13 years ago

I personally have only ever written unsafe when wrapping something with FFI.

Is discussion of unsafe in an introduction article esoterica?

By the way, loved the proposal video [1] you did on docs for rust: it's a pretty solid proposal for any language.

[1] https://air.mozilla.org/rust-meetup-december-2013/

kybernetikos3• 13 years ago

I happen to write like I talk, it gets good and bad reviews.

I found it unusually clear, which I liked a lot. There was a bit at the end to do with unsafe that was a bit difficult to follow, but a sentence like 'but wait, RWArc is just a library, how come it was able to do the thing that I said the compiler wouldn't let you do?' would have cleared it up just fine.

coldtea• 13 years ago

I happen to write like I talk, it gets good and bad reviews. A more neutral style would be more appropriate if/when this gets pulled into Rust itself, thanks, that's a great point

I think the style's alright. I also like the tone of the tutorial on the Rust website, don't know if you were involved with that too.

Thanks for the great feedback. :)

FWIW, I found the feedback to be a little too condescending for what is a volunter effort to help people understand a new language.

pcwalton7• 13 years ago

This isn't so much an introduction to Rust as it is an introduction to Rust's concurrency model.

Ownership is really central to Rust. It's central to both memory management and concurrency: to work with Rust you need to understand it.

The example of returning a reference to an automatic variable isn't super compelling, since every competent C/C++ programmer knows not to do it.

That's just a simple example. The same logic also prevents iterator invalidation and use-after-free, which are things that do occur in the real world and lead to security vulnerabilities.

Does Rust really call its threads "green threads"? Green threads have a weird reputation.

They're M:N threads, multiplexed among multiple hardware threads, like Go or Erlang.

Does the whole concept of Rust concurrency and memory protection boil down to "the language provides an 'unsafe', and then people write libraries to do things with it"?

Sort of, but I think that's an uncharitable way to say it. The trick is that the language allows these unsafely-implemented primitives to be safely used from safe code. As long as the unsafe code is correct, the safe code is guaranteed to be safe. From a trust point of view this is really no different from building the features into the compiler: either you trust the compiler (which, as it's a compiler, is unsafe) or you trust the unsafe portions of the standard library. But it's way easier, and more flexible, to hack on libraries than to hack things into the compiler—as you get to write code, not code to generate code.

Furthermore, the safe part of the language is so powerful that you rarely ever need "unsafe": you can do practically everything you might need to do, including shared memory with locks, in the safe language, without GC. Only if you really need to squeeze out the last amount of performance, or if you need to interface with C libraries, do you need "unsafe".

steveklabnik33• 13 years ago

That's just a simple example. The same logic also prevents iterator invalidation and use-after-free, which are things that do occur in the real world and lead to security vulnerabilities.

Maybe I should mention some of the more complicated examples explicitly, then?

tptacek4• 13 years ago

I don't mean to be uncharitable; it seems like a legitimate design. I'm just wondering if there are other magic pointer types or type system features that also protect memory. To me, fewer mechanisms is better. On the other hand, building libraries to abstract unsafe pointers has been somewhat discredited by C++ and shared_ptr.

lucian1900• 13 years ago

Rust's tasks can either use native threads or green threads multiplexed on top of a pool of native threads, without change in API.

saosebastiao• 13 years ago

tptacek, I've been meaning to ask this question to someone with some extensive security experience: Is there a compelling story for security researchers and engineers for low-level languages with an emphasis on memory safety (like Rust or Cyclone)? From my admittedly limited perspective, it seems like it could eliminate a lot of mistakes that lead to insecure software, but then again, I don't know how common memory-flaw exploits are.

pcwalton7• 13 years ago

From my admittedly limited perspective, it seems like it could eliminate a lot of mistakes that lead to insecure software, but then again, I don't know how common memory-flaw exploits are.

We have done measurements on this for Firefox code. 100% of the security vulnerabilities for Web Audio were memory safety flaws.

tptacek4• 13 years ago

Absolutely it does.

pjmlp8• 13 years ago

since every competent C/C++ programmer knows not to do it.

They are hard to come by, in this time and age, of cutting down costs everywhere while offshoring components.

Daishiman2• 13 years ago

They have always been hard to come by because not everyone wants to spend 10 years banging their heads against the wall of memory management errors unnecessarily.

Jemaclus• 13 years ago

The last time I touched C code was my sophomore year in college, so maybe 12 years ago? As a result, the last time I had to deal with pointers and such was back then, as well.

I'm primarily a web-dev. Ruby, PHP, and Javascript are the languages I'm most familiar with at the moment.

Are there any Rust for Dummies-style tutorials floating around? As simple as this introduction is, it was still over my head...

steveklabnik33• 13 years ago

I have you covered in that case as well: http://www.rustforrubyists.com/

I want to provide a version of the 30 minute intro that's not strictly for systems people as well, but you have to start somewhere.

rubiquity• 13 years ago

Do you see Rust as a language that people will write the business domain type applications in or as a supplement to languages like Ruby, Python, etc. to write those "gotta have performance here" parts of the application?

minimax3• 13 years ago

I think we can be a little bit more charitable towards C++. Modern compilers will let you know if you try to do something as obviously incorrect as returning a pointer to a stack variable.

    $ cat > foo.cpp <<EOF
    > int *dangling(void)
    > {
    >     int i = 1234;
    >     return &i;
    > }
    > EOF
    
    $ clang++ -Werror -c foo.cpp
    foo.cpp:4:13: error: address of stack memory associated with local variable 'i'
          returned [-Werror,-Wreturn-stack-address]
        return &i;
                ^
    1 error generated.

steveklabnik33• 13 years ago

Thank you! Maybe I should explicitly show a new/free example instead, or does that end up having a similar warning?

I haven't written serious C++ in years, so I have some blind spots. Others on the Rust team have done quite a bit, so they tend to pick up my slack in exactly this manner.

minimax3• 13 years ago

I wasn't trying to undermine your argument. Rust is solving real problems. Use after free and double free are still issues in the C world. In modern C++ we are (hopefully) using smart pointers (std::unique_ptr, std::shared_ptr) to manage heap-allocated object lifetimes.

maxerickson2• 13 years ago

I personally dislike the style of tutorial that has lots of 'we' and 'lets' in it.

I suppose part of that comes from the tendency for such tutorials to provide revelations instead of motivators. For example, in this tutorial there is 'look at this C++ code because I said to' and then two sentences later it explains that the C++ code ends up in a garbage value.

But this is probably very much a point of style and I'm sure lots of people think my view is stupid.

steveklabnik33• 13 years ago

I tend to be very collectively focused, so I do tend to write this way. Thanks for the feedback; the style may not be appropriate for an official tutorial.

the tendency for such tutorials to provide revelations instead of motivators.

I'm going to have to think about this, that's very interesting. I would like to say that my revelations provide motivation, but that may be wishful thinking...

Do you think there's a way to demonstrate these concepts in a way without 'the reveal'? It seems to me that comparison will always feel a bit reveal-y, as demonstrating some kind of difference is inherent in comparison.

maxerickson2• 13 years ago

Well, try to state the motivation prior to the explanation.

"The second function in this C++ code does not properly initialize num":

...

"How does that happen?"

...

"Rust avoids this by"

...

brson2• 13 years ago

I like this a lot, and think it's the best intro to Rust yet. The thing that concerns me a bit is that it presents the special cases in concurrency without impressing some of the most important points. Primarily, the channel example presents the send as copying, which in this case it is, but one of the main advantages of Rust's channels and owned types is that message passing of heap-allocated types do not need to copy. It probably doesn't stress hard enough that Rust tasks do not share memory before saying, 'oh, but really you can share memory if you need to', though I see that the Arc and RWArc examples are good ways to introduce the concept of using unsafe code to provide safe abstractions.

45g• 13 years ago

You can see how this makes it impossible to mutate the state without remembering to aquire the lock.

Not quite true. Looking at the type signature of e.g. RWArc::write I see this:

    fn write<U>(&self, blk: |x: &mut T| -> U) -> U

which means I could probably do:

    let mut n = local_arc.write(|nums| {
         nums[num] += 1;
         return ~(*nums);
     });
    n[2] = 42;

eridius2• 13 years ago

You're not letting anything escape. You're copying `nums` and then mutating your copy. And this only works because `nums` can be implicitly copied like this. If you changed it from `[int, ..3]` to `~[int]` you'd get a compiler error (as `~[T]` cannot be implicitly copied).

samth3• 13 years ago

I think the emphasis on "unsafe" isn't helpful. As far as I can tell, the only thing that "unsafe" is enabling is that Arc and RWArc are written in Rust rather than in C in the runtime (the way they'd be in Go, or Erlang, or Haskell). The things that make Rust able to do what it does are ownership and tasks and lifetimes and affine types -- all the things the post covers before talking about "unsafe".

Also, it gives the impression that there's something fundamentally unsafe about all of this, whereas the whole point is that these abstractions are _safe_ to use.

eridius2• 13 years ago

I think `unsafe` is important to talk about. It's the escape hatch that lets you subvert the type system and do things that the compiler cannot statically reason about. The ability to implement Arc in pure Rust code is very important. But I do agree that it could have been presented perhaps in a different way.

eatfish• 13 years ago

Agreed. My experiments with rust have been uphill because I've been fighting with lifetimes, ownership and borrowing.

For the most part I failed to see that I -needed- unsafe code in some situations. Instead I was trying (failing) to annotate my code to ridiculous levels with lifetimes. It was really frustrating.

I don't think the current docs do a great job of putting unsafe in a suitable perspective. It's somewhat downplayed IMO.

Still, I've learned now and it's been pretty pleasant after that.

FWIW I've been doing c++ for maybe 18 years, writing device drivers, game engines, compiler development. I thought rust was made for me but it's been tough, much more so than any other language except maybe SML!

steveklabnik33• 13 years ago

Also, it gives the impression that there's something fundamentally unsafe about all of this, whereas the whole point is that these abstractions are _safe_ to use.

Right, this is my point. I should find a way to make it a bit more clear.

I wrote it this way because the systems people I talk to are skeptical at times that a compiler knows best. After all, there's a reason you want that low-level control in the first place, right? The ability to escape things when you have to relaxes people.

kps• 13 years ago

I think that's a necessary approach. The first time I encountered Rust, in a treatment that covered unique and managed but not unsafe/raw pointers, my impression was: ‘You promised GC was optional, but I can't even write a DAG’.

samth3• 13 years ago

I wrote it this way because the systems people I talk to are skeptical at times that a compiler knows best.

Well, the best way to combat that would be demonstrate that cool things can be done safely in Rust, but that probably requires a lot more than fits in your introduction.

I think you could allay that fear by addressing it directly, rather than saying that Rust's secret sauce is unsafety.

rcthompson• 13 years ago

Thanks for this straightforward and accessible intro to some of Rust's unique features!

steveklabnik33• 13 years ago

You're very welcome.

niix• 13 years ago

Thanks for this. I've been thinking about getting into Rust recently and this motivates me to do so now.

steveklabnik33• 13 years ago

Excellent. You're very welcome. :)

0x001E84EE• 13 years ago

I'm a big fan of that kudos button! Very nice website and an interesting introduction to Rust.

steveklabnik33• 13 years ago

Thanks! I don't make any of that, it's just Svbtle.

nfoz• 13 years ago

I find it annoying to the point of offensive. Actions being actived on mouse-hover is terrible; I did not intend to give "kudos" but was curious what might be linked under it, and suddenly an action is recorded. Now I can't consider any webpage safe and have to watch where my mouse goes; that's wrong.

BlackDeath3• 13 years ago

Three cheers for NoScript!

I understand that it doesn't really solve your problem, but if it's safety you're worried about...

ChuckMcM2• 13 years ago

This is an excellent summary Steve, it also points out one of the challenges of 'System' languages, which is the requirement for 'unsafe.'

One of the first things I did when I started working on Oak (which became Java) was to see about writing an OS in it. The idea being that if you could write an OS in a 'safe' language then you could have a more reliable OS. But we were unable to write it completely in Oak/Java and that lead to some interesting discussions about what might be the minimum set of 'unsafe' actions might be required by a systems language.

Sadly we did not get to explore that very much, although I did pass it on as a possible thesis topic to some interns who came through Sun at the time. I'd be interested in your experience with what actions require 'unsafe' and if you have seen a canonical set that might point toward a process to get to a 'safe' OS.

kibwen5• 13 years ago

For reference, the following actions are what are enabled within `unsafe` blocks in Rust:

1. Dereferencing raw pointers (a.k.a. "unsafe" pointers). Note that's just dereferencing: there's nothing inherently unsafe about just creating and passing around the pointers themselves.

2. Calling a Rust function that has been marked with the entirely-optional `unsafe` keyword.

3. Calling an external function via the C FFI, all of which are automatically considered unsafe.

valtron• 13 years ago

Don't points 2 & 3 together imply that anything that uses built-ins, which I assume are implemented with C FFI, is `unsafe`?

silon3• 13 years ago

Note that's just dereferencing: there's nothing inherently unsafe about just creating and passing around the pointers themselves.

Sure there is. Passing around multiple pointers can result in a double free and then the dangerous dereference can happen. I'm guessing the developer must be careful when writing unsafe blocks to make sure this doesn't happen.

steveklabnik33• 13 years ago

Glad you liked it, Chuck.

Some of my closest friends in college specialized in operating systems, and we (mostly them) worked on http://xomb.org , an exokernel in D. I'd hope that today we'd choose Rust instead.

Julia Evans has been writing _fantastic_ series about a kernel in Rust: http://jvns.ca/blog/categories/kernel/

As she says "This is typical of a lot of Rust code I’m writing – I need to write a lot of unsafe code."

I'll have to give this 'minimum set' idea some thought. I think that safety will be more useful for things like kernel modules than in the kernel itself, though I'm not sure why I think that, exactly. Hmmmmm...

kibwen5• 13 years ago

  > I need to write a lot of unsafe code.

To contrast with application-level code, pcwalton has measured that less than 1% of Servo's code is contained within `unsafe` blocks.

scott_s3• 13 years ago

You'll probably be interested in the Singularity project at Microsoft Research: http://research.microsoft.com/en-us/projects/singularity/

Much of the kernel is implemented in managed code.

volatile• 13 years ago

I remember hearing about Singularity a few years back - it sounded promising. Looking at the linked page, there doesn't seem to be anything published or presented since 2009. Anyone know what's going on with Singularity these days?

seanmcdirmid• 13 years ago

Sun eventually did JavaOS, though I'm not sure how much of its code was Java.

IBM did Jikes RVM (old name: Jalapeno) which was mostly, if not purely Java. They handled the bootstrapping problem with some clever ahead-of-time compilation + meta-programming. Even their GC is implemented in Java.

twic2• 13 years ago

Jikes RVM was an absolutely amazing project. Superb work.

googles

Jikes RVM is an absolutely amazing project. Superb work. And i'm very glad to see it's still under somewhat active development!

http://jikesrvm.org/

noelwelsh2• 13 years ago

The focus on C++ as point of comparison is understandable given Mozilla's background, but in Internet land most systems software runs on the JVM, and is written in Java, or increasingly, Scala (see LinkedIn and Twitter, for example).

The issues of memory layout and the like come up here, and unlike Rust the JVM doesn't give much control of this aspect. See Martin Thompson's blog for an example of someone very concerned with issues of performance on the JVM (http://mechanical-sympathy.blogspot.co.uk/) I believe Rust could see a lot of adoption within this community as a "better" Scala -- a modern high-level language that allows dropping down to bit-twiddling when performance is an issue. It needs higher kinded types before it will work for me, but I hear that is on the road-map.

BTW, I've read a few Rust tutorials and they all fail for me in the same way: too much waffle and not enough getting down to the details. I understand the difference between stack allocation, reference counting, and GC, I get why shared mutable state is a bad idea, etc. What I want is a short document laying out the knobs Rust provides (mutable vs immutable, ownership, allocation) and how I can twiddle said knobs.

steveklabnik33• 13 years ago

I think that's totally true. It's not just so much because of Mozilla, but also because Rust is probably closer to C++ than Java...

The official tutorial contains much of that information.

noelwelsh2• 13 years ago

Funnily, I see at being closer to Scala than either C++ or Java. I think it all comes down to background.

The official tutorial isn't very good on issues of memory management. The first mention of managed references (I assume that means GCed) is in an example in section 11. Nowhere does it actually explain what managed means (and if I missed it, I blame the tutorial for not making it explicit enough!)

Aloisius• 13 years ago

but in Internet land most systems software runs on the JVM, and is written in Java

[[Citation needed]].

The Internet land I've lived in mostly lives in C with a smattering of non-JVM scripting languages (Python, Ruby, PHP, etc) on top.

mbreese• 13 years ago

It's probably more accurate to say that in the Enterprise most software is running on the JVM. But there are certain (large) internet companies that have significant system software running on the JVM (Google, Twitter).

bsaul2• 13 years ago

Is rust borrowing any kind of code from what is used for objective C ARC technology relative to detecting the lifetime of a variable and automaticaly freeing the resource ? Is it a common known algorithm ?

steveklabnik33• 13 years ago

Everything is written in Rust, so we're not borrowing the code.

Reference counting is very common: http://en.wikipedia.org/wiki/Reference_counting

bsaul2• 13 years ago

I had the impression that rust and ARC were doing a bit of static code analysis to detect when a "reference count decrease/increase" could be performed ( thus the "automatic" part in ARC), and insert code at compile time. Which seems a bit more complicated than simply decrease them dynamically when a pointing is object is destroyed. But now that i come to think of it, things look a little blurry for me on that part.

acqq2• 13 years ago

"Rust does not have the concept of null."

How can I have the pointer to something that is maybe allocated or maybe present? Do I have to have additional booleans for such uses? Isn't that a waste?

How can I effectively build complex data structures like graphs, tries etc then?

I'd like to see that covered too.

kibwen5• 13 years ago

Rust uses the `Option` type for that (name taken from Scala and ML, it's called `Maybe` in Haskell).

http://static.rust-lang.org/doc/master/std/option/index.html

What's neat is that if you stuff a pointer inside an `Option`, then not only is it guaranteed to be memory-safe but it also compiles down to a plain old nullable pointer at runtime, so there's no extra overhead while still retaining safety.

acqq2• 13 years ago

So it doesn't have "null" but it has "None." On the linked page:

     // Remove the contained string, destroying the Option
     let unwrapped_msg = match msg {
         Some(m) => m,
         None => ~"default message"
     };

Now why is there that ";" at the end? Before that there is a construct without it:

    // Take a reference to the contained string
    match msg {
        Some(ref m) => println!("{}", *m),
        None => ()
    }

And did we have take the "reference" to print the value of m?

And one note more: the linked page doesn't explain that the Some actually introduces "Option" type. It writes about the Option but the code uses just "Some."

     let msg = Some(~"howdy");

Some as a "keyword" seems to have two different semantical purposes, depending if it's in the "match" or not. I don't see that explained too.

Skinney• 13 years ago

You use the Option type. Option can either be None or Some(T). I think Rust optimizes this to (non)null, so there is very little, if any, overhead compared to the equivelent C++ code.

steveklabnik33• 13 years ago

It compiles down to a nullable pointer if possible, and if not, it needs a tag, so yes, it's very minimal if any.

A 30 minute introduction to Rust

Related Stories