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

41–50 of 128 posts

Re: Rust 1.0: Status report and final timeline

#41

Post by gtaylor »

kibwen wrote: post #12
gtaylor wrote: post #5

I haven't been tinkering with Rust, merely keep an eye on it until 1.0 lands. For those who are currently more in touch with the situation, does this release date look realistic, without quality suffering? Is the 1.0 release premature, aggressive, or very realistic? It seems like the standard library has seen a ton of work in the last month or two. I'm surprised at how aggressive the release schedule is, given how th…

> For those who are currently more in touch with the situation, does this > release date look realistic, without quality suffering? Is the 1.0 > release premature, aggressive, or very realistic? I think it's aggressive, but I don't think it's unrealistic. Personally I had hoped for a late June/early July release to give more time to solidify the docs and to shake out bugs in the compiler. There will definitely be peo…

That's re-assuring to hear. Thanks!

Re: Rust 1.0: Status report and final timeline

#42

Post by steveklabnik »

breckinloggins wrote: post #39
kzrdude wrote: post #9

Earlier quoted context omitted.

A feature that has already seen many proposed rfcs and long discussions is "Efficient code reuse" (a.k.a some kind of inheritance), summarized here: https://github.com/rust-lang/rfcs/issues/349 It was explicitly postponed until after 1.0.

I just wrote a comment on that issue with some half-baked ideas, but I really think that this is one of those "line in the sand" features that will determine (at least for me) whether rust is really staying true to its emerging identity or whether it's on the road to becoming another opinionated kitchen sink language. The thing about "efficient code reuse" is it probably requires dynamic dispatch. Once you have dynam…

Rust already supports dynamic dispatch[1], and the 'code re-use' proposals may not look like traditional inheritance. [2] Furthermore, they're being driven _by_ those low-level requirements: it's about being able to efficiently represent things that truly need it, like the DOM.

1: http://doc.rust-lang.org/book/static-and-dynamic-dispatch.ht...

2: http://www.reddit.com/r/rust/comments/2j78oh/i_heard_that_ru...

Re: Rust 1.0: Status report and final timeline

#43

Post by kibwen »

breckinloggins wrote: post #39
kzrdude wrote: post #9

Earlier quoted context omitted.

A feature that has already seen many proposed rfcs and long discussions is "Efficient code reuse" (a.k.a some kind of inheritance), summarized here: https://github.com/rust-lang/rfcs/issues/349 It was explicitly postponed until after 1.0.

I just wrote a comment on that issue with some half-baked ideas, but I really think that this is one of those "line in the sand" features that will determine (at least for me) whether rust is really staying true to its emerging identity or whether it's on the road to becoming another opinionated kitchen sink language. The thing about "efficient code reuse" is it probably requires dynamic dispatch. Once you have dynam…

Rust has had dynamic dispatch via since time immemorial, because there are a few things that static dispatch can't express (the original motivating factor was having an array full of different types that all implement the same interface). It is achieved by leveraging a feature of the traits system known as "trait objects": http://doc.rust-lang.org/book/static-and-dynamic-dispatch.ht...

But you are correct in that one of the loudest objections to the potential inclusion of inheritance in Rust is that people don't want two ways of achieving dynamic dispatch, because suddenly then you're in the same boat as C++ where you must decide which incompatible subset of the language to use in your codebase.

Re: Rust 1.0: Status report and final timeline

#44

Post by pcwalton »

breckinloggins wrote: post #39
kzrdude wrote: post #9

Earlier quoted context omitted.

A feature that has already seen many proposed rfcs and long discussions is "Efficient code reuse" (a.k.a some kind of inheritance), summarized here: https://github.com/rust-lang/rfcs/issues/349 It was explicitly postponed until after 1.0.

I just wrote a comment on that issue with some half-baked ideas, but I really think that this is one of those "line in the sand" features that will determine (at least for me) whether rust is really staying true to its emerging identity or whether it's on the road to becoming another opinionated kitchen sink language. The thing about "efficient code reuse" is it probably requires dynamic dispatch. Once you have dynam…

> 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 not for structs), so this would be nothing new. It's important that we have them, because otherwise common dynamic dispatch would be very annoying to write.

2. Structure layout is already not defined. The compiler is permitted to reorder structure fields as it likes. However, you can force it to adopt your specified in-memory order with the `#[repr(C)]` annotation.

> It would be nice to have a new C, finally. But the more a language has an opinion on runtime layout, behavior, and symbol names, the less C-like it becomes.

The language already has an opinion on runtime layout and symbol names. However, you can specify the layout and symbol names manually if you like (through `#[repr(C)]` in the former case and `#[no_mangle]` in the latter case).

> Rust got this right when it decided that GC was NOT the correct default behavior for a language. The reason you see people playing with OS kernels in rust and not as much in D is, I think, mainly due to this decision. I think rust should continue carrying this torch.

GC has performance costs, while trait objects and symbol names do not, as long as they're opt-in. Garbage collection and virtual dispatch are completely different things; having one in no way moves us closer to the other.

Re: Rust 1.0: Status report and final timeline

#46

Post by breckinloggins »

steveklabnik wrote: post #42
breckinloggins wrote: post #39

Earlier quoted context omitted.

I just wrote a comment on that issue with some half-baked ideas, but I really think that this is one of those "line in the sand" features that will determine (at least for me) whether rust is really staying true to its emerging identity or whether it's on the road to becoming another opinionated kitchen sink language. The thing about "efficient code reuse" is it probably requires dynamic dispatch. Once you have dynam…

Rust already supports dynamic dispatch[1], and the 'code re-use' proposals may not look like traditional inheritance. [2] Furthermore, they're being driven _by_ those low-level requirements: it's about being able to efficiently represent things that truly need it, like the DOM. 1: http://doc.rust-lang.org/book/static-and-dynamic-dispatch.ht... 2: http://www.reddit.com/r/rust/comments/2j78oh/i_heard_that_ru...

In the book, you mention that "the std::raw modules contains structs with layouts that are the same as the complicated built-in types". I suppose what I'm asking for is some way for std::raw (plus some contract-like traits and other things) to somehow be the complicated built-in types.

I know that's a hard ask, but the upside would be that anything in the language that's represented by a complex layout + behavior could in principle be replaced by another implementation that preserves the size and behavior contracts. If an implementation is not provided, those features of the language are unavailable. This kind of takes the "you can't use x and y until you give me an allocator" approach and turns it up to 11.

Re: Rust 1.0: Status report and final timeline

#47

Post by kibwen »

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…

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 for whatever reason (working on feature branches, perhaps?), such as nrc and pcwalton.

Re: Rust 1.0: Status report and final timeline

#48

Post by breckinloggins »

pcwalton wrote: post #44
breckinloggins wrote: post #39

Earlier quoted context omitted.

I just wrote a comment on that issue with some half-baked ideas, but I really think that this is one of those "line in the sand" features that will determine (at least for me) whether rust is really staying true to its emerging identity or whether it's on the road to becoming another opinionated kitchen sink language. The thing about "efficient code reuse" is it probably requires dynamic dispatch. Once you have dynam…

> 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 exposes that complexity in a composed pluggable fashion).

I'm beginning to believe rust really has a shot at replacing C and needs to court "bare metal" programmers as well as higher-level programmers to do it; I'm just preemptively registering my wish that rust continue to head down that path.

Re: Rust 1.0: Status report and final timeline

#49

Post by lastontheboat »

kibwen wrote: post #47
Artemis2 wrote: post #38

Earlier quoted context omitted.

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…

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.

Re: Rust 1.0: Status report and final timeline

#50

Post by erickt »

AlyssaRowan wrote: post #22

Rust looks interesting. One thing I'm not clear on it if can do, and that I'm interested in, is secure destructors. Say I'm handling crypto, and I'm carting around an ephemeral key. When this goes out of scope, I definitely no matter what, want this zeroised by its destructor - as opposed to just having it (or a temporary copy made by a compiler optimisation!) zombling around the heap, stack or forgotten unused xmm r…

We had a Bay Area Rust meetup [0] all about cryptography back in December (here[1] is a video if you want to watch the event). One of the subjects of that talk was about a project tars[2] that tries to provide for a secure buffer for keys that is protected against it being leaked using a variety of techniques. It hasn't yet been analyzed, so of course you shouldn't actually trust it yet.

There's a lot of interest in our community to build out a solid foundation and verified foundation of cryptography primitives. If you're interested in helping out, hop in the #rust-crypto channel on irc.mozilla.org.

[0]: http://www.meetup.com/Rust-Bay-Area/events/210632582/

[1]: https://air.mozilla.org/bay-area-rust-meetup-december-2014/

[2]: https://github.com/seb-m/tars

Post reply on HN