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.
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.
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.
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.
Thanks! That's just the first instance I spotted — there were a few dozen similar things I saw after skimming for 2-3 minutes. I'll post an issue if I find time.
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.
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.
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.
Some manpages have quite helpful "examples" sections, eg. find(1). Usually, if they do, these sections are towards the end, which isn't necessarily the first place you'd look unless you knew that that was typically where they were.
Many manpages, of course, do not provide examples.
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.
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>."
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.
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).
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.
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.
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.])
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.
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.
I know you're not exactly opposing the above comment, but I'll make a supporting argument here which acknowledges what you've said:
I feel as though we can retain understanding of those differences without using the name "Vec", which can be considered a poor choice for the reasons mentioned above (by C++ and Rust alike).
Array<T> for a growable array
[T, ..N] for a fixed-length array
&[T] for a slice into either of these array types
Even forgetting the mathematical concept, I would argue that throwing the term "Vector" into the mix only makes things more complicated than they need to be, since sticking to "Array" homogenizes everything. For good reason, we don't call a resizable string a "Hobnob" in an attempt to disambiguate, so why call a resizable array a "Vector", which makes just as much sense?
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.
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.
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.
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.
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
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.
> "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.
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.
As someone else describes, void is the "uninhabited" type, i.e.: it cannot be created. Void is a way of indicating the absence of valid output.
I think null is wrong too, because it references the fact that in most languages, types are a sum type of "all possible valid inputs" plus "null". Rust avoids null and has no null pointers unless you use unsafe code.
Unit means "there is precisely one instance of this type". It is the unitary type.
First you have to say if you are talking about () the type or () the value. () the type is fairly close to void in meaning. () the value is fairly close to null in meaning. Thus both comparisons are accurate, which is applicable depends on which () you are referring to.
While your post is correct for () the type, if I consider () the value, your post could be transformed without loss of accuracy to:
Void is not a value either, and you cannot return it from a function. I think null is a closer match.
I guess you could argue that 'null' refers to the '1' in a sum type 'T + 1'. I still think 'unit' is the most precise term though, especially seeing as Rust doesn't have structural sum types. `None` is the closest we get to null.
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.
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
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.
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.
Yes it could be implied if left out. Due to type inference.
`5` would be signed or unsigned if left off. Depends on how you use it.
So you could try.
use std::num::abs;
let v = vec!['a', 'b', 'c', 'd'];
let x = 3;
let c = v[x]; // v.index (operator overload) constrains x to type uint.
let y = abs(x); // error: failed to find an implementation of trait core::num::Signed for uint.
// abs can't constain the type to an int because abs can take anything that
// implements `Signed` (eg BigInt)
If you wanted to make sure that x was signed.
let v = vec!['a', 'b', 'c', 'd'];
let x = 3i;
let y = abs(x); // Ok as x is signed.
let c = v[x]; // error: mismatched types: expected `uint` but found `int`
If you really wanted to index to try an index with an int you can use a checked cast.
let casted = x.to_uint(); // Returns None if x is negative or Some(x) if it's postive.
Also a generic int doesn't have to be int or uint, it can be any integer value: signed: i8, i16, i32, i64 or int. Unsigned: u8, u16, u32, u64 or uint.
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.
That's an option. I think for me personally the implication that the number is somehow pluralized is more potentially confusing than the idea that it is irrational, but YMMV.
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).
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?
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.
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.
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.
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.
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.
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.
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)
Gc<T> is not actually a garbage collector. It's a refcount + cycle detection. It was intended to turn into a real GC, but instead, it's in the process of being removed entirely.
I've gone through and cleaned up all the references to it in our docs and marketing, so we stop misleading people with this notion.
I wouldn't be so quick to give up on GC support yet! "We have a plan!" But I don't think we'll have it in for Rust 1.0. And it's true that, even if we never do get it to work in a satisfactory way, the language works just fine without it.
I'm curious about the reasoning behind the removal and what it means to Rust. Do you have any links on that? I tried looking on both Github and Discourse but couldn't find any more info.
Historically, @T, which is now Gc<T>, was assumed to be the 'default' pointer type. Like, from a conventions standpoint. And it was used all over the place.
As we wrote more and more Rust, it became clear that unique ownership (~T, now Box<T>) was just as useful, faster, and better. Remember, this type basically compiles down to a regular pointer, with compiler inserted malloc/free. So you can imagine how much less that is compared to a refcount + cycle detection.
So, Gc<T> was never really improved, and it's usage in the compiler itself was less and less. The last place it was used was in the AST, and so syntax extensions used it, but we didn't recommend it for anything else.
Now, this past week, a contributor managed to re-write the AST to not use Gc<T>, so even than is gone. Or will be soon, I forget if it's passed CI so far. But anyway, now that it's gone, it will probably be simply removed, though that decision hasn't been made yet.
Basically, what it means is that affine types are awesome.
So, so that mean that Gc will probably be phased out of the standard library. Now I come to think of it, since Rust knows the lifetime of most (all ?) the memory, would it be thinkable that the compiler also optimise memory mapping/fragmentation ? Or would that interfere with Dynamically Sized Types ? I feel I really out to dig deeper into Rust once it's a bit more stable.
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.
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...
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
I like fn a lot more than fun. fns are serious business! (and personally I have a hard time dealing with abbreviations that are themselves actual words, fn stands out more)
fwiw, continue and return used to be cont and ret, match used to be alt, crate used to be not a keyword iirc.
fun would have been better:
- ML heritage for named functions (fn was anon)
- muscle memory with the leading part of javascript function
- the other abbreviations take the leading part of the word
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
You better get over that problem because, depending on the language and context, you will find function written as fn, func, def, ->, lambda and many more. Some languages even don't offer a keyword for it.
In Rust, the function keyword is written 'fn', there're no assumptions or ambiguity there. You just have to learn "in Rust fn means function". It's as capricious as any other keyword, including function.
As a non-native English speaker I find this amusing because for me it's very clear that keywords are magic incantations for the compiler or interpreter, they aren't meant to explain anything. You just learn how to use those keywords and deal with it. For me, it's not clearer to write function instead of fn because in my native language you write it 'función'.
In my experience, it's not rare for Spanish-speaking programmers to ommit the t in function as it is the clearest and most natural way for them to write it. Then, when the program doesn't work, they have to add the missing ts. I feel fn is an improvement with regards to this, as it's not so English-centered. Let's stop pretending that programming a computer is a mixture of Logic, Math and English.
I agree with the core of what you're saying. fn vs function vs whatever is simply a way for the compiler to read your program. However, I feel like it's a mistake to say natural language has nothing to do with programming.
The most powerful metaphor I use when I explain to newer developers how to write clear code is simply "tell a story." Of course you're telling a very constrained story, and some parts need a little comment to explain them, but I strongly believe that even if you're using english keywords, you should be telling a story in the development team's native language if possible. Not everything is a binary choice, even in computing. ;)
You should try Haskell for size before complaining about Rust. IMHO, it's really a matter of taste, and something which most people get over with quickly if they find it an issue. Actual semantics are much more important than a small number of language keywords. Libraries, on the other hand, should definitely use easy-to-understand symbols.
You already have the 'conceal' feature in vim, which in vim2hs is used to replace \_ with a λ_. No need for plugins. I think the vim Rust plugin has support for it, but you need to set an option.
Yes, exactly, we can make translations of symbols so that it is actually easier for human readers to decode the meaning and message of the symbols. Perhaps we could even reuse previous symbols and meanings to convey what we want to convey instead of offering ambiguity.
I just wonder, who would have thought of such an idea. That is genious. And something that has completely evaded Rust designers.
Weed, caffeine, and sleep deprivation. Staring at Harris mainframe assembly language core dumps on reams of green bar paper... does things to a man. ;-)
HTML5 and Unicode are wonderful toys. Go play. My notes and early efforts on this go back to 1979. Anyone is welcome to them. It does take quite a bit of effort to transmit, so patience is a virtue here.
(P.S. Don't overlook color.)
(P.P.S. Or animation.)
---
Edit: You'd be surprised how easy input becomes. It removes a huge mental load from context switching (e.g. hitting the same button to get Control F4, Control W, Apple W, Alt F Alt C, etc.).
Use a few touchpads which can change the symbols based on current context, and baby - you got a stew goin'.
Try to wrap your head around how many API's, tools, training materials, releases, updates and so forth have been done in thirty years which are effectively redundant.
The iWatch will contain regurgitations of the same todo lists, logging, sticky notes, etc. as the Palm Pilot, but without AAA batteries.
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.
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.
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...
Ultimately I need to spend some more time with it. I'm sure it's fine, I just find it jarring. One major issues is the official tutorial doesn't explain all possible variances of syntax for declaration in one place so my brain wasn't given a chance to compare them side by side.
Also i'd much rather live without type inference, so I guess rust gives me that option. I'm just too neurotic (low level networking code/parsers/etc) to not specify types.
let mut monster_size: int = 50;
I'd really really just like the type to be first.
let mut int monster_size = 50;
But wait, there are yet more options:
let monster_size = 50i32;
Boxes are just plain confusing on first sight. They make pointers look like a lucid breath of fresh air.
let owned = box 10i;
let borrowed = &20i;
let sum = *owned + *borrowed;
I find options in a language quite distressing (see also perl). I'm also not sold on the mut keyword and i'm likely to become confused when one gets to complex types.
Don't get me started on the automatic dereferencing. That's seriously confusing.
Is there a rule of thumb for when I am meant to use which of these? can i use the type annotation anywhere i use a number as a literal?
Raw string literals:
> They are written as r##"blah"##, with a matching number of zero or more # before the opening and after the closing quote
Why? Why the optional number of #'s?
Syntax extensions? !
Why is print a syntax extension? why isn't it in the library? if it is a macro why are we running around putting ! at the end of them... why does it matter? Why do that?
I prob don't know what I'm talking about but that's my initial impression from last week
The "let monster_size : int = 50"/"let monst_size = 50i32" is an example of special cases for numeric values. For other types, only the first style is available. I would imagine that it's a shortcut to let you specify easily what kind of representation you want for a numeric value in a less noisy way (since numeric values don't have explicit constructors).
Boxes and lifetimes get a bit used to, but comparing Perl and Rust is, I feel, quite unfair. Rust's syntax is much smaller than Perl's, and from what I've seen the team has taken pains to make it smaller and more regular.
As for println!, it's a macro which gives you compile-time checks on your format string (same as OCaml), which is very nice.
The variable number of #s is in case the string contains some number of #s.
print is a macro so it can be strongly typed and checked by the compiler. As far as I know, "!" is just a convention to make macros obvious -- it seems unnecessary to me, too.
Putting the type of a variable at the end is common in new C-likes. Go does it too. In the case of Rust, I'm pretty sure it's inherited from ML. It avoids a lot of the problems and complexities caused by C's type keywords (see: typedefs of pointers to functions; const pointers to values and pointers to const values; etc.).
> As far as I know, "!" is just a convention to make macros obvious -- it seems unnecessary to me, too.
No, it's very necessary, as macros actually take arbitrary token sequences as an 'argument', so there's no guarantee that the contents will parse as Rust code (e.g. https://github.com/huonw/brainfuck_macros), furthermore, macros can transform this argument into arbitrary code.
Hence it's nice to have an in-source marker to avoid humans and compilers having to work out if a certain name has strange semantics (particularly for compilers, to avoid having to intertwine parsing and name resolution: makes this simpler).
While this isn't exactly the same, the convention of appending "!" in scheme/racket to denote a function that mutates a value is helpful in my opinion. You don't absolutely need it, but reading through your code and easily identifying where your values can change is nice.
I'm wondering if it would be more readable with actual angle brackets rather than less than and greater than signs.
from_str::<Option<uint>>
vs
from_str::‹Opton‹uint››
Hmm. Those are a little lightweight, are actually angle quotes, not angle brackets. Actual angle brackets aren't available on my keyboard, but would look like:
from_str::⟨Option⟨uint⟩⟩
Jeez, why does Unicode have so many different variations on angle brackets? The above are "mathematical left/right angle bracket", but there's also:
from_str::〈Option〈uint〉〉
Which uses "left/right-pointing angle bracket" and:
from_str::〈Option〈uint〉〉
Which uses "left/right angle bracket"
At least in the font I'm typing this in, the "left/right-pointing angle brackets" look the best to me. It would be really nice if now that Unicode is ubiquitous, we could standardize on keyboard layouts that get you access to more punctuation like this, so that people didn't have to keep fighting over a fairly limited amount of punctuation to use as technical notation in programming languages.
