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

91–100 of 161 posts

Re: A 30 minute introduction to Rust

#91

Post by steveklabnik »

politician wrote: post #90
steveklabnik wrote: post #19

Earlier quoted context omitted.

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 personally have only ever written unsafe when wrapping something with FFI. Is discussion of unsafe in an introduction article esoterica? By the way, loved the proposal video [1] you did on docs for rust: it's a pretty solid proposal for any language. [1] https://air.mozilla.org/rust-meetup-december-2013/

Unsure. I think it's really important that people know the rules _can_ be broken if you think you know better than the compiler.

Thanks. :)

Re: A 30 minute introduction to Rust

#92

Post by ChuckMcM »

kibwen wrote: post #81
steveklabnik wrote: post #79

Earlier quoted context omitted.

Glad you liked it, Chuck. Some of my closest friends in college specialized in operating systems, and we (mostly them) worked on http://xomb.org , an exokernel in D. I'd hope that today we'd choose Rust instead. Julia Evans has been writing _fantastic_ series about a kernel in Rust: http://jvns.ca/blog/categories/kernel/ As she says "This is typical of a lot of Rust code I’m writing – I need to write a lot of unsafe…

> I need to write a lot of unsafe code. To contrast with application-level code, pcwalton has measured that less than 1% of Servo's code is contained within `unsafe` blocks.

Exactly, and of course this leads me to wondering about computer architectures that "require" unsafe things in their kernels, versus things like Multics where the OS and hardware co-operated at some level to make things safe. Lots of interesting questions.

Re: A 30 minute introduction to Rust

#93

Post by noelwelsh »

steveklabnik wrote: post #88
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…

I think that's totally true. It's not just so much because of Mozilla, but also because Rust is probably closer to C++ than Java... The official tutorial contains much of that information.

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!)

Re: A 30 minute introduction to Rust

#94

Post by doublec »

steveklabnik wrote: post #44
tptacek wrote: post #41

Earlier quoted context omitted.

Oh, don't get me wrong, I'm sold on memory protection as a type system feature. I'm just suggesting that the example you're using might make it sound less valuable, because returning stack variable references isn't the most common kind of error made by C programmers; when you do that, more often than not your program doesn't work at all.

Absolutely, I don't want people to think I'm attacking a straw man. Maybe a heap allocated example would be better?

One thing I did when trying to come up with a "What features of language X help safety" article for ATS was to work through a simple example from unsafe, to safer, to safe. This is one such article I did:

http://bluishcoder.co.nz/2012/08/30/safer-handling-of-c-memo...

I think something similar for Rust would make for a great article subject too.

Re: A 30 minute introduction to Rust

#95

Post by dbaupp »

twsted wrote: post #70
minimax wrote: post #50

Earlier quoted context omitted.

"Second, shared_ptr isn't very fast, due to some design decisions like ... not being intrusive (requiring 2x the allocations)." Not quite. You can use std::make_shared to allocate the object and the ref count in one allocation. You get improved locality of reference as an added bonus.

And it uses (or may use) a lock-free implementation on many platforms.

An atomic increment is still significantly more expensive than a normal one.

Re: A 30 minute introduction to Rust

#96

Post by dbaupp »

pcwalton wrote: post #35
saosebastiao wrote: post #31

Earlier quoted context omitted.

tptacek, I've been meaning to ask this question to someone with some extensive security experience: Is there a compelling story for security researchers and engineers for low-level languages with an emphasis on memory safety (like Rust or Cyclone)? From my admittedly limited perspective, it seems like it could eliminate a lot of mistakes that lead to insecure software, but then again, I don't know how common memory-f…

> From my admittedly limited perspective, it seems like it could eliminate a lot of mistakes that lead to insecure software, but then again, I don't know how common memory-flaw exploits are. We have done measurements on this for Firefox code. 100% of the security vulnerabilities for Web Audio were memory safety flaws.

How many bugs in total? And, memory safety that Rust would've protected against?

Re: A 30 minute introduction to Rust

#97

Post by steveklabnik »

noelwelsh wrote: post #93
steveklabnik wrote: post #88

Earlier quoted context omitted.

I think that's totally true. It's not just so much because of Mozilla, but also because Rust is probably closer to C++ than Java... The official tutorial contains much of that information.

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

Re: A 30 minute introduction to Rust

#98

Post by kibwen »

dbaupp wrote: post #96
pcwalton wrote: post #35

Earlier quoted context omitted.

> From my admittedly limited perspective, it seems like it could eliminate a lot of mistakes that lead to insecure software, but then again, I don't know how common memory-flaw exploits are. We have done measurements on this for Firefox code. 100% of the security vulnerabilities for Web Audio were memory safety flaws.

How many bugs in total? And, memory safety that Rust would've protected against?

I forget the exact number, but it was at least 20. And I believe they concluded that, yes, Rust would have caught them. I'll need to ask pcwalton to be sure though.

Re: A 30 minute introduction to Rust

#99

Post by pjmlp »

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?

Depends on the implementation.

Don't mix languages with implementations.

Currently there are two native compiler toolchains for Go, which only support a given set of OSs and computer architectures.

Additionally some people written Go interpreters with another set of supported targets.

So to answer your question, it would run on the embedded system if :

1 - the hardware could cope with Go runtime requirements

2 - it would be a supported target for one available native code toolchain

Re: A 30 minute introduction to Rust

#100

Post by bsaul »

Is rust borrowing any kind of code from what is used for objective C ARC technology relative to detecting the lifetime of a variable and automaticaly freeing the resource ? Is it a common known algorithm ?
Post reply on HN