Rust Guide

by bilalhusain • 12 years ago

319 141 12 years ago

axaxs• 12 years ago

Honest initial impressions from my quick glance. This guide is confused. It reads at times like an informal conversation... lots of exclamations. That's pedantic, the real confusion comes from the target audience. As a programmer, I want as little cruft as possible. Get me to examples and how this differentiates from C. As a non programmer, teach me the basics of types and logic. From that thought, it's failing at both. As a programmer, stop talking to me informally and redefining types as one liners. As a newbie, you're explaining basic shell constructs as if I don't know, then trying to sum up strings in a one liner. I know it's an early draft, and I know Steve is an awesome dude. My advice - figure out your audience or else break into two guides. Be terse with me, be overly explanatory to a beginner. This now seems to sway on both sides of that line, and likely will frustrate both groups.

buster• 12 years ago

If you want more details, less cruft, you probably like to read the Manual: http://doc.rust-lang.org/rust.html

The Guide is fine as a tutorial and where does it not teach the basics?

So your impression is definitely not mine. "Stop talkting to me informally" is also very subjective. I very much prefer the informal way.

ash• 12 years ago

Looking forward to reading "Rationales and design tradeoffs" section. But it's still not written: http://doc.rust-lang.org/rust.html#appendix:-rationales-and-...

Is there any place to read about the Rust design?

mkishi2• 12 years ago

I've always enjoyed informal guides, but oddly enough I share your frustration.

Heck, I loved "Learn You a Haskell," yet this one reads very patronizing for some reason, and I can't figure out why.

maxerickson• 12 years ago

I usually get that visceral reaction from pronoun heavy instructional material. I haven't decided if it is just a personal hang up or not.

It's usually possible to omit pronouns and end up shorter, maybe at the cost of ending up a little dryer:

"Welcome to the Rust guide. This is the place to learn how to program in Rust. Rust is a systems programming language with a focus on "high-level, bare-metal programming": low level control, but with zero-cost, higher level abstractions. We really think Rust is something special, and we hope you do too.

The guide starts with a traditional "Hello, World!" program. Next a quick detour to introduce "Cargo", a tool for managing and building Rust programs and libraries. Then it's back to the language."

If the guide actually builds something, the last sentence there could say "Then it's back to the language, starting with the basics and working up to <thing that is built>."

ZeroGravitas• 12 years ago

This seems to be fundamental problem with programming texts. I was reading a couple of javascript books recently (eloquent javascript and javascript allonge) and I was struck by the sheer amount of background knowledge you needed to have.

Most of that I've picked up over the last 20 years, but not all of it (or else I wouldn't be reading the books) so I constantly felt like I was having something I knew explained to me in too much detail or having crazy new concepts thrown at me without enough context.

I mostly felt sorry for total newcomers, particularly as I realised most of my knowledge was historical trivia or workarounds rather than actual useful. Once I noticed the above, the amount of crufty irrelevances we have to deal with became obvious, and that's doubly true in JS for the browser.

My only constructive thought was to break things into smaller skippable sections. I personally would skim rather than skip, but advanced warning that the section would only cover stuff I thought I already knew would be helpful.

k__• 12 years ago

I see this problem too, when teaching people.

I tell them stuff and leave out the things that seem obvious to me. They can tell me, what is the missing bit.

scott_s2• 12 years ago

Mark Pilgrim solved this problem quite well in "Dive Into Python". He presented the working code first, at the beginning of each chapter ("diving in"). If you could read and fully understand the code, then you had no need to read the rest of the chapter. If there were only small things you didn't understand, you could skim to those sections.

This philosophy is stated pretty clearly in the beginning of the book:

You know how other books go on and on about programming fundamentals and finally work up to building a complete, working program? Let's skip all that.

2.1. Diving in

Here is a complete, working Python program.

It probably makes absolutely no sense to you. Don't worry about that, because you're going to dissect it line by line. But read through it first and see what, if anything, you can make of it.

See: http://www.diveintopython.net/getting_to_know_python/index.h...

dmunoz• 12 years ago

Hopefully some of the issues you're noticing will get fleshed out before the guide is officially linked from the rust homepage.

I do agree with you though. I felt the same way about the guide from the first time I read (parts of) it, and I know we're not alone. I've commented before about how it's impossible to nail down the target audience, but it seems overly informal as a replacement to the current tutorials, especially compared to the "additional guides" that were linked to at the conclusion of the tutorial which really got down to business quickly.

I've long been hoping that something like rustbyexample.com gets officially sanctioned and linked to from the homepage alongside the guide. As a small metric, the current tutorial is 942 to Hello World, the new guide is 1595 words, and rustbyexample.com is 239 words.

vertex-four• 12 years ago

Most languages' official "guides" use a more-or-less informal tone, from my experience. I've not read through the Rust Guide yet, but I'd think this is a good thing, especially as most newcomers to Rust will be learning new concepts (its type system is very different from most languages, unless you're coming from the strongly typed functional world).

georgemcbay3• 12 years ago

I disagree. I like it a lot, particularly if "graded" as a first public draft.

I'll admit right up front that there is a lot of subjective bias here, different people learn in different ways and you will never please everyone. So I'm not saying you are wrong, just that the guide appeals to me.

In terms of the A/B split on target audience:

A - Newbs) I'd argue that teaching people to code is way, way beyond the scope of any document like this, so the most logical starting target is someone who codes already but maybe doesn't have a ton of experience and maybe it is in a language very different from the one the guide is presenting. I think this guide hits that target pretty well as a straight-forward read. There are nitpicky things that maybe could be better, but luckily online guides like this can be expanded and iterated on.

Obviously a newb isn't going to understand something like what a "closure" is inherently, but they have the whole rest of the internet to tell them that when they see the term in this guide and then google it to fill in the blanks.

B - Non-Newbs) As an experienced programmer I think the guide is actually pretty great if you use the nicely presented ToC/index at the front as the primary interface to it. Click a concept and boom, you're looking at some nicely formatted example code along with some text that you can probably just skip over completely or skim because you already know what a closure is (for example) and just want to see the syntax for Rust.

I remain a diehard Go partisan for now, but I think this guide is actually superior in a lot of ways to the combination of the "Go Tour" and "Effective Go" which, cute mascot aside, are a bit too much on the dry/clinical side for me as introductory material to a language.

coldtea• 12 years ago

Programmer of 15+ years here, I disagree.

It's a new language with some interestinf semantics than can be tricky even for those familiar with say C or Java or Python etc, so it's good that it's conversational -- it helps cater to both the new programmer and the experienced one in other languages.

The skipping of cruft part I can do by myself, using "vgrep".

This "skipping of cruft" because we're talking to "experienced programmers" is what makes Manfiles nearly useless, EVEN for experienced programmers, unless as a very basic flag reference.

the_af• 12 years ago

Agreed. Manfiles are an excellent example! My usual investigation of an unfamiliar command goes like this:

1- Read the manfile.

2- If I was just trying to figure out the meaning of a flag, I'm done.

3- If it was anything else, I space out trying to understand the no-nonsense, terse, written-for-programmers style of the manfile. I usually fail.

4- Google.

makmanalp• 12 years ago

I think the problem is that references and tutorials fill different niches. This is a tutorial, basically. Tutorials are conversational, intuitive, hand-holding walkthroughs. If you think you already know enough, you should be able to just skim the reference. References are to the point, don't hand-hold, and get the job done.

jfarmer2• 12 years ago

Disclaimer: I've been writing programming curriculum professionally for the last three years.

I do agree that it falls into the pit you describe, but I disagree that it's the style that's doing it. I think the style is fine, although there are always people it could turn off (e.g., you, perhaps).

Here's an example of him falling into that pit, though:

By the way, in these examples, i indicates that the number is an integer.

Ok, that's an important detail! You have to be reading _very_ closely to read that line. An expert will be skimming (as you say) and someone less less expert might not even realize how important that fact is.

If I had to list "Five Rust Facts About Integers and Variable Bindings," noting that you signal an integer literal with that "i" character would definitely be on that list! As it's written, it's emphasized no more or less than any other part of the text.

roywiggins• 12 years ago

Indeed. I skimmed and thought "Wait, we're using imaginary numbers now? What?" and then realized it just meant "this is an integer."

bjz_6• 12 years ago

This is good criticism. If you have time, might you consider creating an issue? https://github.com/rust-lang/rust/issues Steve reads all of the ones regarding documentation, and most likely would find it valuable.

andrewflnr• 12 years ago

Even within the domain of informal writing, there's a lot of fat in this piece that should be trimmed. I think that's what's triggering your distaste. However, once that is removed, as I'm sure it will, the tone will improve dramatically, and I suspect you'll only find it slightly annoying.

My guess is that by far the most likely reader of this document is a noob to Rust with some degree of experience in other languages. To be safe we'll only assume basic programming experience. As a more experienced programmer, I don't mind seeing a few explanations of things I already know. From that perspective, this guide is a good compromise, once the technical issues are solved.

someone13• 12 years ago

Also note that the installation section is a bit out of date: they have Windows x64 binary installers now:

http://www.rust-lang.org/install.html

antocv6• 12 years ago

Please Rust-lang, why, oh why, do you choose to name function 'fn' and module 'mod', dont you expect to read any of the programs you write!?

How is anyone supposed to read fn main(). Fun main? Fen main? F of N? Is it related to ln in println?

Ive tried rust, but it just doesnt parse well in my mind. More time is spent for me parseing out the bullshit terse keywords than the meaning of the program.

Ada gets this right, there you have to write exactly what you mean, end begin, if then. Simple clear.

Terseness, shorts and abbrevations, thts now hw you wrt anyng.

Vanzetti2• 12 years ago

You are not supposed to read programs aloud. What do you think it is, poetry? 'fn' is a symbol.

antocv6• 12 years ago

Well yeah, it should be poetry.

Instead of, what, cryptic symbols to decipher?

You dont read symbols?

reirob• 12 years ago

I feel exactly the same way. Thanks for saying it loud!

simias• 12 years ago

Come on, that's a complete bikeshed and I'm sure you know it. If you have to read code aloud you can just say "fun" or "function" and "mod" or "module", obviously. And since those symbols are used everywhere in the source code I really doubt anybody is going to forget what they mean.

I know it's trendy to remove all non alnum characters and make everything super verbose but there's a compromise to make here. Because some languages went overboard with symbol soup doesn't mean all symbols/abbreviations are bad.

This is the kind of reacting any newcomer to a language makes. You start with lisp? "omg all those parens!" You start with python? "omg significant whitespace!" You start with C? "OMG all those semicolon at the end of lines!" You start with perl? "OMG!" You start with APL? "O|▼".

Also I think making basic language constructs overly verbose doesn't help legibility because it drowns the actually interesting bits in a lot of boilerplate. VHDL comes to mind, but it's probably not what you were talking about...

antocv6• 12 years ago

I dont read code aloud, but when reading it I have to make the sounds in my head. Makes sense?

fn calculate() does not lead my brain/mind to discover everything there is it already knows that is function and what it means in this specific context, but instead if I read it as fun it takes me to fun times calculating tip at college with friends.

mod means modification. Modulus. Or module. Why oh why, cant they just write freaking word module?!

Thats what programming is about - kill assumptions, define stuff, and Rust is flowing with assumptions and tersness.

Ada is what I am talking about - a very fine verbose language. Even Java is better than rust.

I think if Mozilla designed Java, it would look like this

pub cls Dfne {

priv stat fin Str hey;

}

hippiehippo2• 12 years ago

Bikeshed or not, he's not the only one who doesn't like "fn" choice. The shortnaming choices aren't really consistent. IMHO, "fun" would be better.

  as box break continue crate else enum extern false fn for if impl in let loop match mod mut priv proc pub ref return self static struct super true trait type unsafe use while

gosub3• 12 years ago

do you think that python should use "define" instead of "def"?

antocv6• 12 years ago

Yes, I think thats a miss python made.

But python at least doesnt have the goal it seems to make abbrevations and allow misconceptions about what the language is saying.

hippiehippo2• 12 years ago

On the other hand, do you think that python should use "df" instead of "def"?

jacquesm• 12 years ago

The use of fn in programming languages to denote 'function' goes back to the 60's. Even BASIC had it! (deffn).

stock_toaster• 12 years ago

How is anyone supposed to read fn main()

I humorously read it in my head as "fuckin' main".

easytiger2• 12 years ago

fn & mod are fine. no worse than cdr & car.

Variable declaration and type annotations in rust are the thing you should be confused/angry/sad about.

bcj• 12 years ago

I would say fn and mod are a lot better than cdr and car. At least fn and mod are just abbreviations of the words they represent.

cdr and car requires me to know 60-year-old implementation details of Lisp.

mercurial6• 12 years ago

What do you find wrong about variable declaration and type annotation? Most variable declarations are like 'let foo = ' with the type auto-inferred. I admit that the diamond notation for type parameters is a bit aggravating, but it's not the end of the world. On the other hand, the little rust I've seen had a large number of as_slice() calls...

saosebastiao• 12 years ago

Yes! This is what drives me the most crazy about rust:

    fn foo<<W<>W>G<>GGW>>>F<<D>F>>A>(bar: AJK<<<DUoSJK><<>S>>>){
    ...
    }

Okay, I'm probably being a jackass, but I find Scala's use of [] for nested type annotations to be much easier to parse.

Grue3• 12 years ago

Absolutely agreed. Programs are for reading. For a language designed in 2010s there's no excuse to use such ridiculous abbreviations.

general_failure• 12 years ago

Not sure why you are getting downvoted. I find it very annoying as well.

Why not use brk, cont as well? Somethings are abbreviated, some things are not.

kansface• 12 years ago

Both your comment and OPs comment have no place. The article itself is a newly published guide to Rust. OPs comment derailed the entire thread- perhaps 2/3 of the discussion is in response. Ideally, if this comment merited discussion, it would be submitted as its own thread (where it would quickly go nowhere). After all, the assertion, fn is a stupid name, is a bikeshed- a triviality offering a safe opinion for everyone. Rust isn't going to change the token. Please refrain from bikeshedding in the future.

spyder• 12 years ago

Maybe you shouldn't spell out every abbreviation (and acronym) when you read? Otherwise it can be "fun" when you read HN comments about the HTML5 WebGL API and the low FPS CSS animations that eats too much CPU power.

gosub3• 12 years ago

    let x = 5i;

so, integers are written like complex numbers?

thristian• 12 years ago

In this case, "i" is a type suffix meaning "int". 5u would be an unsigned int; 5i32 would be a 32-bit int; 5f64 would be a double precision float, and so forth.

gosub3• 12 years ago

I understood that, but it's an unfortunate suffix.

the_mitsuhiko3• 12 years ago

Complex numbers use `j` :)

georgemcbay3• 12 years ago

AFAICT they only need to be written like that if you want to assign them to an implicitly typed variable or you can use the alternate explicitly-typed form (which the guide also shows):

let x: int = 5;

As far as i being an unfortunate suffix, I can't think of a better one when you consider there is already a pattern to such suffixes (being the first letter of the type) carried over from C/C++, et al.

I suspect mathematician programmers who are already used to * being multiply and ^ being bitwise xor (instead of, say, an exponent operation) can probably learn to deal with it, or just avoid it by avoiding implicit typing for ints.

blt• 12 years ago

5s for 5 signed?

sixbrx• 12 years ago

On the other hand, not many languages use lowercase 'i' for complex number literals, in fact I can't think of any right now.

cheepin• 12 years ago

I can't even think of a language that has first class complex numbers, let alone complex number literals.

gus_massa• 12 years ago

Scheme and Racket use i in complex numbers, for example:

(* 2+3i 4+5i) ;=> -7+22i

dragonwriter• 12 years ago

Ruby 2.1 does.

steveklabnik9• 12 years ago

https://github.com/rust-lang/rust/issues/15526 <- there's actually a lot of context for this, and depending on how the RFC shakes out, much of this will go away.

SideburnsOfDoom2• 12 years ago

One stylistic nitpick / question. It says:

"We expected an integer, but we got (). () is pronounced 'unit', and is a special type in Rust's type system. () is different than null in other languages, because () is distinct from other types"

Would it not be more accurate and more informative to compare the "special type" unit to "void" than to compare it to "null" ?

The keyword "void" is a placeholder that says "nothing here" where normally there would be a type. It function more or less like a type. i.e. "public void foo { ... };" instead of "public int foo() { ... };"

I understand "unit" as a "first class void".

"null" on the other hand is a value, that can be placed in variables of many types.

the_mitsuhiko3• 12 years ago

The problem with void is that it's not a real type in C.

SideburnsOfDoom2• 12 years ago

Yes, totally. The same in java and c# too.

That's why I said void is "more or less like a type" and asked about "unit" as a "first class void" - i.e. a "void" that is a real type that works like other types.

jeremyjh• 12 years ago

Null is not a type either, and you cannot reference it in a definition. I think void is a closer match.

lelf• 12 years ago

It's called unit in math / many other languages.

null is not a type. void type is inhabited. unit type has exactly one value, ().

sratner• 12 years ago

Comparison with `null` is strange. First thing I thought of was JavaScript's `undefined`.

eik3_de• 12 years ago

leaving aside the first-mover advantages like community, docs, stdlibs, api stability, where do you see rust's advantages over go?

antocv6• 12 years ago

Security.

fleetfox2• 12 years ago

Control, lack of garbage collector.

ldng2• 12 years ago

Control, yes.

Lack of garbage collector ? There is a garbage collector in the standard library : http://doc.rust-lang.org/std/gc/

It gives you even more control I would say as you can choose when/if to use a garbage collector. Which is not always a bad idea (See https://news.ycombinator.com/item?id=8263811)

andolanra• 12 years ago

The two languages are quite different. Go is billed as a "systems language", for whatever that means, but in practice occupies a space similar to Java. It's quite well-suited for server and applications programming, but various design choices mean that it's less well-suited for lower-level programming domains like operating system components or device drivers, performance-intensive video games, or hard-real-time embedded systems.

On the other hand, Rust is aimed at being a replacement for C++ or even C: it allows for precise control over lower-level aspects of the machine while providing more static guarantees of correctness by means of a powerful type system. For example, Rust prevents dangling and null pointers and disallows access to uninitialized memory while retaining manual memory management, as well as allowing garbage collection as a library-provided feature and not a core language feature. In that sense, Rust is suitable for problem domains that Go is not.

matthewmacleod• 12 years ago

The languages (to me at least) seem to have little overlap. Maybe a better question would be "Why are there so many comparisons between Rust and Go"?

bjz_6• 12 years ago

Superficially, they both have curly braces, they are both being supported by prominent internet companies, and due to some mixed messaging, the public perception is that they are both systems languages. So it's not surprising that these questions are being asked, but I do hope that the message will get through to folks that despite surface similarities they are actually quite different.

Pxtl• 12 years ago

They both billed themselves as "modern C" but Go failed to deliver on that so instead it's now light/modern/ Java. Rust hopes to succeed as a "modern C" where Go failed.

Shamanmuni2• 12 years ago

I like Go and feel quite productive when building web services with it. It works well, but I think the Golang team neglected many advances in Computer Science, particularly the ones coming from the functional world, and the result is a nice language which could have been great. Rust appears to be that great language.

When you see Rust it's clear that they have taken note of these advances and added them to the language. Pattern Matching, Algebraic Data Types, Hindley-Milner type inference accompanied by a sophisticated type system, everything is an expression (well, most), immutable variables by default and type classes are all things that many of us who were exposed to the functional world miss sorely in mainstream languages like Java. Rust includes all of them while Golang doesn't, and C++ doesn't have some of them.

And it doesn't end there, in Rust you can also do OOP, though it's different from Java (no classes, more similar to Go). You have concurrency primitives baked into the language as in Go. You have generics as in C++ (the most cited criticism of Go, which lacks them). It lets you manage memory but in a safer way than C. And it can be made compatible with C, which lets a library written in Rust be used by other languages.

So, Rust really feels like the superior replacement of C++, and possibly C, that Golang promised at first, and it has a chance of becoming mainstream when it's stable. Rust offers all the things that Golang does, and many more. The tooling is generally better in Go, but it surely can be improved.

the_mitsuhiko3• 12 years ago

I like the informal style, I would not want to change it. Tutorials and introductions are supposed to be readable to complete beginners or developers that only used a simple programming language before.

There are lots of small things I would want to change about the guide, especially in regards to which sections should be more in depth and which ones should be skipped for another guide, but that's why it's a first iteration.

ch• 12 years ago

It would be useful if the guide folded the Unix/Windows examples up into a single view (something like what the Spark docs do: https://spark.apache.org/docs/latest/quick-start.html#Basics)

And then, perhaps, used some platform detection to display the more appropriate form by default.

That way less space is used up by the parallel examples.

phloxicon• 12 years ago

I think it reads well but I would prefer if the examples given were correct first time around and then talk about what might go wrong, whereas right now, it describes what might go wrong and then how to do it correctly.

For example, in the testing section, the first example code generates an error because it's scope is private. The section then shows how to fix this. I would prefer he showed the correct way first and then how to fix common errors.

Also, I didn't see file IO but i probably overlooked that.

Other than that, it's excellent. Very thorough and reads like a book.

octo_t• 12 years ago

+1 from me for the `curl | sudo sh` disclaimer. Even if the only thing it does is stop people complaining about it :)

JoelMcCracken• 12 years ago

I always like seeing and doing curl foo.sh / sudo bash foo.sh

mindslight• 12 years ago

Even if there were five cute disclaimers, suggesting that command would still be irresponsible. The problem is that it hurts the people who are the least knowledgeable. Anyone with a modicum of experience downloads the script first, finds out it's 475 lines, and then chooses a different method that is at least tracked by git.

At least get rid of the wholly-unnecessary sudo. At that point, it would at least be comparable to tar xvzf rust.tgz && ./rustc (still less auditable though).

steveklabnik9• 12 years ago

Hi everyone! I just woke up to find all this, and I'm speaking at a conference today where there's no laptops allowed, so we'll see when I get to read these comments. A few things:

1. Consider this a 'first draft.' I wrote this in sections, see [1], and now it's time to edit as a whole.

2. Because of that, there are still changes coming. There's even an active one in the queue right now. [2]

3. This guide is fairly long (The PDF is 80~ pages), tries to make little assumptions about systems programming knowledge, and will get you from 'I know nothing about Rust' to 'I'm an intermediate Rust programmer.' There's plans to make an abridged version for people who are already familiar with systems or want something faster with less explanation.

To expand on (3) a bit, one of the hard parts of teaching is that you have such varying background levels of skill in your audience. This means different people need different things, one learning resource will never fit all. I very specifically went for extra explanation and an informal tone with this piece, based on my years of experience teaching programmers new languages. You all here are generally much further along, know more programming concepts and features, and are just generally more advanced. I want to include _everyone_ with the introductory documentation I write, and that means spelling things out a bit more. And it also means you all may not like it. You'll probably prefer the abridged version.

Feedback very welcome. I'll read all this eventually, or just open some issues.

1: https://github.com/rust-lang/rust/pulls?q=is%3Apr+author%3As...

2: https://github.com/rust-lang/rust/pull/17155

izietto• 12 years ago

What is your opinion about this HN comment [0] (TL;DR the guide should be terse to a skilled profile, overly explanatory to a beginner)? I personally agree with him

[0] https://news.ycombinator.com/item?id=8306868

steveklabnik9• 12 years ago

Fundamentally disagree. Terse is bad for teaching. There's value in having something terse for those who know they want it, but it's bad for primary material.

bsdshepherd4• 12 years ago

Feedback very welcome.

Negative feedback is being pruned and buried.

steveklabnik9• 12 years ago

That's not even close to true. The top comment is very negative.

A ridiculous bikeshed did get downvoted a bunch though. See https://news.ycombinator.com/item?id=8310203

scott_s2• 12 years ago

I recommend critically reading Mark Pilgrim's "Dive Into Python": http://www.diveintopython3.net/

I think that he manages to serve both audiences: new programmers, and experienced programmers who are new to Python. He achieves this, I think, through two main methods:

1. The emphasis is always on doing things. He introduces and explains the language concepts while using the constructs he's explaining to achieve an understandable task.

2. Code comes first, explanations come after. Hence the title, "Diving Into". Chapter 1 shows this very well: http://www.diveintopython3.net/your-first-python-program.htm..., as does the chapter on classes and iterators: http://www.diveintopython3.net/iterators.html

The idea is that the emphasis and structure enable experienced programmers to quickly recognize "Oh, that's how that is done here - I can move on", but new programmers can also see applications that accomplish some task, and then read line-by-line how it works. Code always has a context.

steveklabnik9• 12 years ago

I love Mark's writing, and "Dive into Python."

I was originally intending on having the guide by driven by sample projects, but I had a hard time making it work when introducing just one thing at a time. I think that's the difference here: I want to build up from small things, rather than say "here's a big thing, you may not understand it all." That approach is the one I'll be using for the abridged guide.

jblow2• 12 years ago

Hey Steve,

Who do we have to harangue to get Rust to rename "Vector"? It is kind of embarrassing and confusing terminology, and there is no reason to propagate it. Just call an array an array and an immutable array an immutable array.

There's no good reason to perpetuate the mistakes of the C++ people.

(Note to those not understanding the objection: A vector is defined an element of a group that is closed under addition and multiplication. This is a very specific and very widely-useful meaning, and any program that does stuff with math is going to use vectors. So when you come along and put into your standard the idea that 'vector' means an arbitrary collection of elements that probably are not even scalars, you not only show that you don't know what vector means, but you confuse the programs of many many of your users, because now they have two totally different things both of which are called Vector and that are both used very heavily. [There is no way in hell anyone is going to call a math vector anything but vector, since that would be insanely confusing.])

lambda2• 12 years ago

My understanding is that in order to make a proposal like this (any change to the syntax or semantics of the language or standard library), the way to advocate a change is to write an RFC. To do so, you fork the rfcs repo on GitHub (https://github.com/rust-lang/rfcs), and write a document describing your proposal and its pros and cons. Then the community can discuss it, and if there's sufficient interest someone will champion for it a shepherd it through the RFC process.

steveklabnik9• 12 years ago

Short because I'm on my phone: my sibling is correct. But I think it's important to understand that Vec<T>, [T, ..N], and &[T] (vectors, arrays, and array slices) aren't different because of mutability. The differences are in ownership, growability, and where the backing memory is allocated. Also, Vec<T> isn't part of the language, but part of the standard library, while the other two are language items. Any RFC would have to take this into account.

jblow2• 12 years ago

In the Guessing Game, you suggest using abs() to get a nonnegative number, but this is wrong, since it would make 0 less probable than all the other values.

bmurphy1976• 12 years ago

Wow. That's a lot of text. I'm going to side with others out there, it's too informal and needs to be tightened up considerably.

It's a decent start, but needs some serious editing.

Good luck!

gtani• 12 years ago

quick comments (from s.b. who has been recently learning D and cuda C++)

- Most important, and nota bene: I liked it!

- this seems to be targeted as a crossover guide for experienced c/java/C++/C# family devs, but written a little below that level (whereas tutorial would be for people that have some programming experience in any language

- top level summaries before you launch into litany of language features: what is the object model, are there entities that can be inherited, how do interfaces/traits/mixins? how does allocation/initialization/destruction/cleanup typically work?

- Needs to note conventions ("_" in file/directory names, 4 space soft tabs) vs things enforced by compiler/tooling

- needs inline references/footnotes/bibliography for H-M type inference, FP style pattern matching, i.e. the "new" FP concepts for people without haskell/ocaml/scala experience

niix• 12 years ago

This language really interests me, but I would like to know some real world applications that are being used for it. While I may enjoy writing it as a hobby, could this be something that I utilized in production as well?

reubenmorais• 12 years ago

Mozilla is writing Servo, a parallel browser engine: https://github.com/servo/servo

There's a group of game developers writing Piston: http://www.piston.rs/

pdovy• 12 years ago

The last I heard OpenDNS was using it for some data processing and Skylight was using it - see "Is Rust Ready Yet?" in http://cmr.github.io/blog/2014/01/12/the-state-of-rust-0-dot.... This is 9 months old now, so maybe there are more projects now.

That said I think the language is still too much in flux to really use for production systems. It seems to still be undergoing syntax changes, standard library changes, etc that might make code that works today not compile tomorrow.

davidu• 12 years ago

We're using it. (OpenDNS)

bjz_6• 12 years ago

Game development, Application development (things like photoshop), high-load web service backends, embedded systems... basically anywhere that C++ is currently used.

The cool thing about Rust is that it guides you towards writing performant code, with a much lower likelihood of ugly bugs. This means it has a lower barrier to entry that languages like C++ or C, where you need a high level of domain specific knowledge and experience in to avoid nasty pitfalls and mistakes.

damien• 12 years ago

Probably the largest application written in Rust is the Rust compiler itself.

Rust Guide

Related Stories