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

131–140 of 147 posts

Re: Rust Guide

#131

Post by lambda »

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'm wondering if it would be more readable with actual angle brackets rather than less than and greater than signs.

  from_str::>
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.

Re: Rust Guide

#132

Post by Shamanmuni »

eik3_de wrote: post #16

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

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.

Re: Rust Guide

#133

Post by mercurial »

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.

Well, you'd make type synonyms in this case.

Re: Rust Guide

#134

Post by steveklabnik »

jblow wrote: post #128
steveklabnik wrote: post #66

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…

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

Short because I'm on my phone: my sibling is correct. But I think it's important to understand that Vec, [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 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.

Re: Rust Guide

#135

Post by steveklabnik »

lambda wrote: post #131
saosebastiao wrote: post #87

Earlier quoted context omitted.

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'm wondering if it would be more readable with actual angle brackets rather than less than and greater than signs. from_str:: > 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…

There are some proposals to make that syntax go away. :: is certainly something we're not happy about.

Re: Rust Guide

#136

Post by jblow »

steveklabnik wrote: post #66

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…

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.

Re: Rust Guide

#137

Post by curtis17 »

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

fn bugs me as well.

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

Re: Rust Guide

#138

Post by mkishi »

steveklabnik wrote: post #127
ldng wrote: post #74

Earlier quoted context omitted.

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 )

Gc 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'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.

Re: Rust Guide

#139

Post by SapphireSun »

Shamanmuni wrote: post #86
antocv wrote: post #20

Earlier quoted context omitted.

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

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. ;)

Re: Rust Guide

#140

Post by steveklabnik »

mkishi wrote: post #138
steveklabnik wrote: post #127

Earlier quoted context omitted.

Gc 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'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, 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) 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 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, 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.

Post reply on HN