Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust Guide

doc.rust-lang.org

Post reply on HN
Print view View original

81–90 of 136 posts

Re: Rust Guide

#81

Post by gtani »

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

#82

Post by niix »

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

#83

Post by reubenmorais »

niix wrote: post #82

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/

Re: Rust Guide

#84

Post by pdovy »

niix wrote: post #82

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?

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.

Re: Rust Guide

#85

Post by pcwalton »

hippiehippo wrote: post #24
simias wrote: 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…

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

On the other hand, it is Huffman-coded: "fn", "impl", and "mod" are quite common, compared to, say, "continue", which is rare.

Re: Rust Guide

#86

Post by stonemetal »

jeremyjh wrote: post #52
the_mitsuhiko wrote: post #27

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.

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.

Value or type neither half is the whole story.

Re: Rust Guide

#87

Post by mercurial »

SideburnsOfDoom wrote: post #36
the_mitsuhiko wrote: post #27

Earlier quoted context omitted.

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

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.

Well, in Java you have http://docs.oracle.com/javase/7/docs/api/java/lang/Void.html

Not exactly first-class but useful at times.

Re: Rust Guide

#88

Post by georgemcbay »

blt wrote: post #70
georgemcbay wrote: post #41

Earlier quoted context omitted.

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

5s for 5 signed?

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.

Re: Rust Guide

#89

Post by andypants »

saosebastiao wrote: post #80
easytiger wrote: post #32

Earlier quoted context omitted.

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 foo W>G GGW>>>F F>>A>(bar: AJK 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.

I initially thought you were writing brainfuck

Re: Rust Guide

#90

Post by jfarmer »

axaxs wrote: 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…

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.

Post reply on HN