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

A 30 minute introduction to Rust

words.steveklabnik.com

Post reply on HN
Print view View original

111–120 of 161 posts

Re: A 30 minute introduction to Rust

#111

Post by dbaupp »

steveklabnik wrote: post #97
noelwelsh wrote: post #93

Earlier quoted context omitted.

Funnily, I see at being closer to Scala than either C++ or Java. I think it all comes down to background. The official tutorial isn't very good on issues of memory management. The first mention of managed references (I assume that means GCed) is in an example in section 11. Nowhere does it actually explain what managed means (and if I missed it, I blame the tutorial for not making it explicit enough!)

Yeah, so the syntax for managed references was removed, yet some of it lingers in the docs. I'll make a note to clean that up. The official tutorial is really bad but at least has a large bulk of information. I'd love to re-write it, but I haven't had the time. (And it was more reference counted than actually garbage collected: now we have Rc and Gc for both strategies.)

(GC still uses @ internally; i.e. it's reference counting and not garbage collection too. This will be fixed.)

Re: A 30 minute introduction to Rust

#112

Post by steveklabnik »

samth wrote: post #106
steveklabnik wrote: post #53

Earlier quoted context omitted.

> Also, it gives the impression that there's something fundamentally unsafe about all of this, whereas the whole point is that these abstractions are _safe_ to use. Right, this is my point. I should find a way to make it a bit more clear. I wrote it this way because the systems people I talk to are skeptical at times that a compiler knows best. After all, there's a reason you want that low-level control in the first…

> I wrote it this way because the systems people I talk to are skeptical at times that a compiler knows best. Well, the best way to combat that would be demonstrate that cool things can be done safely in Rust, but that probably requires a lot more than fits in your introduction. I think you could allay that fear by addressing it directly, rather than saying that Rust's secret sauce is unsafety.

Hm. I thought that talking about building ARC and discussing its implementation was something cool that directly addresses it. What would you like to see?

Re: A 30 minute introduction to Rust

#113

Post by Skinney »

acqq wrote: post #104

"Rust does not have the concept of null." How can I have the pointer to something that is maybe allocated or maybe present? Do I have to have additional booleans for such uses? Isn't that a waste? How can I effectively build complex data structures like graphs, tries etc then? I'd like to see that covered too.

You use the Option type. Option can either be None or Some(T). I think Rust optimizes this to (non)null, so there is very little, if any, overhead compared to the equivelent C++ code.

Re: A 30 minute introduction to Rust

#114

Post by acqq »

kibwen wrote: post #107
acqq wrote: post #104

"Rust does not have the concept of null." How can I have the pointer to something that is maybe allocated or maybe present? Do I have to have additional booleans for such uses? Isn't that a waste? How can I effectively build complex data structures like graphs, tries etc then? I'd like to see that covered too.

Rust uses the `Option` type for that (name taken from Scala and ML, it's called `Maybe` in Haskell). http://static.rust-lang.org/doc/master/std/option/index.html What's neat is that if you stuff a pointer inside an `Option`, then not only is it guaranteed to be memory-safe but it also compiles down to a plain old nullable pointer at runtime, so there's no extra overhead while still retaining safety.

So it doesn't have "null" but it has "None." On the linked page:

     // Remove the contained string, destroying the Option
     let unwrapped_msg = match msg {
         Some(m) => m,
         None => ~"default message"
     };
Now why is there that ";" at the end? Before that there is a construct without it:

    // Take a reference to the contained string
    match msg {
        Some(ref m) => println!("{}", *m),
        None => ()
    }
And did we have take the "reference" to print the value of m?

And one note more: the linked page doesn't explain that the Some actually introduces "Option" type. It writes about the Option but the code uses just "Some."

     let msg = Some(~"howdy");
Some as a "keyword" seems to have two different semantical purposes, depending if it's in the "match" or not. I don't see that explained too.

Re: A 30 minute introduction to Rust

#115

Post by steveklabnik »

Skinney wrote: post #113
acqq wrote: post #104

"Rust does not have the concept of null." How can I have the pointer to something that is maybe allocated or maybe present? Do I have to have additional booleans for such uses? Isn't that a waste? How can I effectively build complex data structures like graphs, tries etc then? I'd like to see that covered too.

You use the Option type. Option can either be None or Some(T). I think Rust optimizes this to (non)null, so there is very little, if any, overhead compared to the equivelent C++ code.

It compiles down to a nullable pointer if possible, and if not, it needs a tag, so yes, it's very minimal if any.

Re: A 30 minute introduction to Rust

#116

Post by mbreese »

Aloisius wrote: post #108
noelwelsh wrote: post #84

The focus on C++ as point of comparison is understandable given Mozilla's background, but in Internet land most systems software runs on the JVM, and is written in Java, or increasingly, Scala (see LinkedIn and Twitter, for example). The issues of memory layout and the like come up here, and unlike Rust the JVM doesn't give much control of this aspect. See Martin Thompson's blog for an example of someone very concern…

but in Internet land most systems software runs on the JVM, and is written in Java [[Citation needed]]. The Internet land I've lived in mostly lives in C with a smattering of non-JVM scripting languages (Python, Ruby, PHP, etc) on top.

It's probably more accurate to say that in the Enterprise most software is running on the JVM. But there are certain (large) internet companies that have significant system software running on the JVM (Google, Twitter).

Re: A 30 minute introduction to Rust

#117

Post by georgemcbay »

Jhsto wrote: post #86
stusmall wrote: post #76

Earlier quoted context omitted.

Sometimes these applications are written in C for the extreme portability rather than performance. I have a couple open source projects in mind that support a huge selection of OSes and hardware configurations that would not be possible with some of the other current higher level language but almost every platform supports C to some degree. I don't know how well Go supports weird configurations like MMU-less uClinux…

I don't really understand concepts of low level languages, but I've had a perception that if I'd wrote a program in Go using the standard libary and compiled it with go build it would run on all imaginable platforms. Now, as far as I've understood your comment suggests that I'm wrong. Lets suppose that some corporation would download the binaries of my project and use it on an embedded system, would it run?

In addition to what stusmall's said about "it depends what you mean by embedded":

Go compiles to native code, not bytecode. Your post makes it seem like you might be missing this fact.

Go has good cross-compile support so from say a Windows box I can compile a Go program using just the standard library that will run on Windows, or I can compile one that runs on MacOS, or I can compile one that runs on Linux, and I can even compile one that runs on a different processor arch (like I can be running Windows/x86 and compile a binary for Linux/ARM, for example).

But(!) you have to compile a separate binary for each of those platforms, you can't compile just one single executable that runs on all of those systems. The output of the Go compiler is native machine language code for a specific architecture and OS.

eg. I want to compile an http server and run it on either a Windows/x64 box or a chumby Linux device and I'm currently on a Linux/x86 system:

cd mygoprogram

export GOARCH=arm

export GOARM=5

export GOOS=linux

go build

I now have an executable in the current working directory named "mygoprogram" that will run on a Linux system with an ARMv5 processor (say, an old chumby device)

export GOARCH=amd64

export GOOS=windows

go build

I now have an executable in the current working directory named mygoprogram.exe that will run on a Windows/x64 system, but it is completely separate from the binary that will run on the Linux/ARM device despite being built from the same source code.

mygoprogram.exe will not run on the Linux system, and vice versa. Go is like C/C++ in this regard as opposed to say Java where a common bytecode format will make the compiled code still platform independent.

Re: A 30 minute introduction to Rust

#118

Post by nfoz »

0x001E84EE wrote: post #63

I'm a big fan of that kudos button! Very nice website and an interesting introduction to Rust.

I find it annoying to the point of offensive. Actions being actived on mouse-hover is terrible; I did not intend to give "kudos" but was curious what might be linked under it, and suddenly an action is recorded. Now I can't consider any webpage safe and have to watch where my mouse goes; that's wrong.

Re: A 30 minute introduction to Rust

#119

Post by zxcdw »

Daishiman wrote: post #85
pjmlp wrote: post #80

Earlier quoted context omitted.

When I start coding, GC enabled languages only existed in very expensive workstations in research places like Xerox PARC. Somehow I have this memory, maybe false, that on those days the developers had better skills than most of the younger developers I met on the last five years.

Sure, because it was expected that certain features would take a exponentially longer time to develop because many features were not created back then and the market was not as competitive. If I'm asked to make an image gallery for a GUI you can bet 99% of people will go for an existing solution out of a matter of productivity, and the reality is that even if I was interested in making a gallery of my own or acquirin…

> At least the vinyl has some aesthetic, subjective vintage value.

For some of us so does working with assembly and other low-level quirks and domains. :) The challenges and problems, tools and solutions are very differnt and IMO much more interesting than "getting shit done for real life value". To each their own I guess.

Re: A 30 minute introduction to Rust

#120

Post by kybernetikos »

steveklabnik wrote: post #19
tptacek wrote: post #12

This isn't so much an introduction to Rust as it is an introduction to Rust's concurrency model. The example of returning a reference to an automatic variable isn't super compelling, since every competent C/C++ programmer knows not to do it. That bug does pop up every once in awhile, but almost always in the context of a function that returns a reference to one of many different possible variables depending on some c…

Salespeople qualify leads by determining if you're ready to buy or not. If you're not, they stop wasting time on you. The general idea for a quick introduction is to qualify your lead. So this isn't a "introduction to Rust's syntax" it's "an introduction to why you should (or should not) care about Rust." > since every competent C/C++ programmer knows not to do it. Everyone knows, yet programs still segfault. The poi…

> I happen to write like I talk, it gets good and bad reviews.

I found it unusually clear, which I liked a lot. There was a bit at the end to do with unsafe that was a bit difficult to follow, but a sentence like 'but wait, RWArc is just a library, how come it was able to do the thing that I said the compiler wouldn't let you do?' would have cleared it up just fine.

Post reply on HN