Live data from Hacker News

Rust Guide

doc.rust-lang.org

81–90 of 147 posts

Re: Rust Guide

#81
post #9

let x = 5i; so, integers are written like complex numbers?

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

Re: Rust Guide

#82
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!

Re: Rust Guide

#83
post #71
post #2

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 bo…

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 "experienc…

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.

Re: Rust Guide

#84

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 l…

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.

Re: Rust Guide

#85

Earlier quoted context omitted.

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

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

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.

Re: Rust Guide

#86
post #20
post #14

Earlier quoted context omitted.

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…

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 wri…

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.

Re: Rust Guide

#87
post #7

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…

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.

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

    fn fooW>GGGW>>>FF>>A>(bar: AJKS>>>){
    ...
    }
Okay, I'm probably being a jackass, but I find Scala's use of [] for nested type annotations to be much easier to parse.

Re: Rust Guide

#88
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

Re: Rust Guide

#89
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?

Re: Rust Guide

#90
post #89

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?

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/

Post reply on HN