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

91–100 of 147 posts

Re: Rust Guide

#91

Post by pdovy »

niix wrote: 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?

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

#92

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

#93

Post by stonemetal »

jeremyjh wrote: post #54
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

#94

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

#95

Post by georgemcbay »

blt wrote: post #77
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

#96

Post by andypants »

saosebastiao wrote: post #87
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

#97

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.

Re: Rust Guide

#98

Post by Bob8000 »

As a n00b programmer, this entry in this guide was the first entry that made the concept of closures clear to me. I don't know if it's because of the use of the two pipes to denote a closure, but it makes it clear for some reason:

  let x = 3;

  fn fun () -> () { println!("{}", x) }  // cannot capture from enclosing scope
  let closure = || -> () { println!("{}", x) }; // can capture from enclosing scope
  
  fn fun_arg (arg: int) -> () { println!("{}", arg + x) }  // cannot capture
  let closure_arg = |arg: int| -> () { println!("{}", arg + x) }; // can capture

Re: Rust Guide

#99

Post by andrewflnr »

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…

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.

Re: Rust Guide

#100

Post by roywiggins »

jfarmer wrote: post #97
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…

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