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

141–147 of 147 posts

Re: Rust Guide

#141

Post by iopq »

the_af wrote: post #83
coldtea wrote: post #71

Earlier quoted context omitted.

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.

I skip the manfile part and go straight to google. It's just as fast and I probably get better examples/explanation.

Re: Rust Guide

#142

Post by ecl3ctic »

steveklabnik wrote: post #134
jblow wrote: post #128

Earlier quoted context omitted.

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

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

Re: Rust Guide

#143

Post by joshmarinacci »

bsdshepherd wrote: post #50
antocv wrote: post #48

Earlier quoted context omitted.

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.

> Perhaps we could even reuse previous symbols You do. The symbol is given meaning by context. > who would have thought of such an idea. That would be me. > genius 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. Anyo…

Wait. Who are you? I'd love to see you notes on this stuff from the 70s and 80s.

Re: Rust Guide

#144

Post by joshmarinacci »

bsdshepherd wrote: post #50
antocv wrote: post #48

Earlier quoted context omitted.

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.

> Perhaps we could even reuse previous symbols You do. The symbol is given meaning by context. > who would have thought of such an idea. That would be me. > genius 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. Anyo…

I've been working on similar stuff here: http://joshondesign.com/2014/08/22/typopl

Re: Rust Guide

#145

Post by ldng »

steveklabnik wrote: post #140
mkishi wrote: post #138

Earlier quoted context omitted.

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…

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.

Re: Rust Guide

#146

Post by nikomatsakis »

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

Re: Rust Guide

#147

Post by davidu »

pdovy wrote: post #91
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, et…

We're using it. (OpenDNS)
Post reply on HN