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

Rust 1.0: Status report and final timeline

blog.rust-lang.org

Post reply on HN
Print view View original

51–60 of 128 posts

Re: Rust 1.0: Status report and final timeline

#51

Post by haberman »

kibwen wrote: post #40
haberman wrote: post #37

I saw that integer overflow has been revised: it now defaults to checking overflow in unoptimized builds. I got a little nervous about this when reading the performance-related objections of @thestinger here: https://github.com/rust-lang/rfcs/pull/560 At least optimized builds aren't affected, but it sounds like lots of code (including Rust nightlies) aren't built optimized.

The nightlies are built with optimizations. And trust me, nobody's going to be distributing Rust binaries that weren't built with optimizations because Rust code built without optimizations has performance on par with Ruby rather than C++ (LLVM's optimization passes do a hell of a good job).

Ah sorry, my mistake. I think I had optimized builds confused with "ndebug" builds. But it sounds like only ndebug builds disable overflow checks, and Rust nightlies don't use ndebug.

Re: Rust 1.0: Status report and final timeline

#52

Post by baq »

haberman wrote: post #37

I saw that integer overflow has been revised: it now defaults to checking overflow in unoptimized builds. I got a little nervous about this when reading the performance-related objections of @thestinger here: https://github.com/rust-lang/rfcs/pull/560 At least optimized builds aren't affected, but it sounds like lots of code (including Rust nightlies) aren't built optimized.

thestinger seems to have a kernel hacker or embedded systems attitude, which is probably lower than 1% of all use cases; that's not to say it's not important, but he's generated an unproportional amount of, let's say, loud signal.

Re: Rust 1.0: Status report and final timeline

#53

Post by astrange »

MichaelGG wrote: post #35
AlyssaRowan wrote: post #33

Earlier quoted context omitted.

I see. Which would be kind of similar to how you do it in C; the destructor is actually guaranteed to run when it goes out-of-scope? But what I'm a bit more worried about is how the secret data gets in there, and what happens while I'm working with it: expansion, cipher state, key setup, all the little adds and xors and rots (dammit, why doesn't ROT ever get some real operator love? It's got first-class instructions……

I know nothing about writing crypto core code. But... Rust supports inline assembly, so after you're done, you could always zeroize every register, right?

Since the compiler can do whatever it wants, you can't be sure it hasn't put any part of the key anywhere on the stack, and there isn't sufficient information for the asm to know which registers contain tainted values.

Unless you can actually prove all parts of the compiler's data transforms going down to assembly I think the safest thing to do is sandbox your key-handling process so nobody else can examine it.

Re: Rust 1.0: Status report and final timeline

#54

Post by kibwen »

lastontheboat wrote: post #49
kibwen wrote: post #47

Earlier quoted context omitted.

In the linked Rust graph, eddyb (the third-highest committer) is a volunteer (an unimaginably prolific one), not a Mozilla employee. kmcallister (the fifth-highest committer) is a Mozilla employee, but not actually on the Rust team (they work primarily on Servo (though there is a fair bit of spillover between the two projects)). Rust has a few other full-time Mozilla employees that aren't represented on that chart fo…

sfackler is a volunteer, too.

Just goes to show how blurry the line is that I've never actually noticed that he's not an employee. :P

Re: Rust 1.0: Status report and final timeline

#55

Post by kibwen »

breckinloggins wrote: post #48
pcwalton wrote: post #44

Earlier quoted context omitted.

> The thing about "efficient code reuse" is it probably requires dynamic dispatch. Once you have dynamic dispatch, you suddenly have vtables. But who decides what those vtables look like? Where do they reside in memory? What's the layout of that? If a struct suddenly has an is-a pointer, where is that mentioned in the code? Now my struct isn't just a struct. 1. We already have vtables through trait objects (though no…

> Garbage collection and virtual dispatch are completely different things; having one in no way moves us closer to the other. Right, of course not. The comparison was philosophical rather than technical. My point was that I believe there's a "sweet spot" for a language that is expressive and convenient and modern, but also tries hard not to stray too far from C's spartan abstract machine model (and when it does, it e…

The best way to make that wish come true is to use Rust in a project where you would normally use C, and report your experience to help us discover the best ways to support that use case. :)

Re: Rust 1.0: Status report and final timeline

#56

Post by nikomatsakis »

haberman wrote: post #37

I saw that integer overflow has been revised: it now defaults to checking overflow in unoptimized builds. I got a little nervous about this when reading the performance-related objections of @thestinger here: https://github.com/rust-lang/rfcs/pull/560 At least optimized builds aren't affected, but it sounds like lots of code (including Rust nightlies) aren't built optimized.

The final draft made an effort to address those concerns -- but also they are completely inapplicable to optimized builds, as kibwen points out. (And if you care how fast your code runs, you really do want optimizations...)

Re: Rust 1.0: Status report and final timeline

#57

Post by jacquesm »

Artemis2 wrote: post #38
q2 wrote: post #25

Is it possible to estimate the amount of manpower and time required to develop a new language from scratch till it is stable and reasonably production ready? Adoption of language is different topic, since it depends on users. Rust and Go are two reasonably new languages. I understand scope and priorities of each language may be different but my idea is to get some approximation/thumb rule for any one before starting…

Both Google and Mozilla have teams dedicated to their languages, but they represent a very small portion of the total number of contributors to the language. I couldn't find exact lists of the team members inside both organizations. In terms of volume of contributions, for Go, Google employees are by far the most active: https://github.com/golang/go/pulse . In this graph, the 7 top contributors to the project are Goo…

The reason why we recognize the names of the Google people is because of past achievements but when they were working on those we did not know their names either. I think it is a bit much to couple 'quality' to notoriety, for all the same money the Rust people are every bit as good as the Go people and Rust will be their claim to fame (if it already isn't doing that) a couple of years down the line.

Re: Rust 1.0: Status report and final timeline

#58

Post by breckinloggins »

dkhenry wrote: post #45

I am going to be happy when I can program in rust and not spend the first hour making all my code work with the latest compiler changes. I really do like what rust is offering, but tracking head has been difficult

Me too! I have yet another NES-emulator-in-rust project [1] and I've been hesitating on picking it back up because I only want to convert to "new rust" once.

It looks like April will be a good month.

[1] https://github.com/breckinloggins/rusticom

Re: Rust 1.0: Status report and final timeline

#59

Post by haberman »

nikomatsakis wrote: post #56
haberman wrote: post #37

I saw that integer overflow has been revised: it now defaults to checking overflow in unoptimized builds. I got a little nervous about this when reading the performance-related objections of @thestinger here: https://github.com/rust-lang/rfcs/pull/560 At least optimized builds aren't affected, but it sounds like lots of code (including Rust nightlies) aren't built optimized.

The final draft made an effort to address those concerns -- but also they are completely inapplicable to optimized builds, as kibwen points out. (And if you care how fast your code runs, you really do want optimizations...)

AFAICS these concerns apply even to optimized builds unless they are also "ndebug", right?

Re: Rust 1.0: Status report and final timeline

#60

Post by tomjakubowski »

mbrubeck wrote: post #29
doctoboggan wrote: post #23

Earlier quoted context omitted.

I am not a Rust user and maybe I am reading the post wrong but it seems that syntax has been deprecated: > Closures: Rust now supports full capture-clause inference and has deprecated the temporary |:| notation, making closures much more ergonomic to use.

That's talking about something different. For a brief period, closures had to be annotated in certain cases like |&: args| or |&mut: args| or |: args| to determine whether they captured their environment by (mutable) reference or by value/move. Now that this is inferred in all cases, closure arguments can just be written as |args| in all cases, just as they were before the current Fn* traits were introduced.

> For a brief period, closures had to be annotated in certain cases like |&: args| or |&mut: args| or |: args| to determine whether they captured their environment by (mutable) reference or by value/move.

That particular annotation controlled the access a closure has to its environment, not how it's captured. |&:|, |&mut: |, and |:| corresponded to the Fn, FnMut, and FnOnce traits, respectively. If you look at the signatures of those traits, you'll see that Fn's method takes self by reference, FnMut takes it by mutable reference, and FnOnce takes it by value. In particular, this means that the body of an FnOnce closure can move values out from the closure (that's why it can only be called once), whereas Fn and FnMut can only access values in the closure by reference and mutable reference, respectively.

The way variables are captured from the environment into the closure is controlled by the "move" keyword. If the "move" keyword precedes a closure expression, then variables from the environment are moved into the closure, which takes ownership of them. "move" is usually associated with FnOnce closures, but it's also needed when returning a boxed Fn or FnMut closure from a function, as you can see below:

    fn make_appender(x: String) -> Box String + 'static> {
        Box::new(move |y|
            // The closure has & access to its captured variable, but
            // it has been moved into the closure so it outlives the
            // body of make_appender, thanks to the move
            // keyword.
            x.clone() + y
        )
    }

    fn main() {
        let x = "foo".to_string();
        let appender = make_appender(x);
        println!("{} {}", appender("bar"), appender("baz"));
    }
Post reply on HN