Rust 1.0: Status report and final timeline • Hacker News Board

Re: Rust 1.0: Status report and final timeline

#21

Post by netcraft » Fri, Feb 13, 2015, 8:40 PM UTC

warnhardcode wrote: post #8

netcraft wrote: post #6

From the outside looking in, I am mostly impressed with the governance structure of the whole endeavor. It seems to me that it is a great model for other open source projects. Edit: as someone involved with other, less mature (and less ambitious) open source projects, if you know of pain points in the governance of rust, i'd be interested in learning about them.

I have only the vague understanding that there are governance structures in place for open source projects. Can you go into a little detail about what aspects of this project's governance impress you?

aturon's response below (https://news.ycombinator.com/item?id=9046882) outlines most of what I would say - really its the RFC process that I'm most interested with and how that is managed in an open way. There are always pet ideas and desires that complicate processes like this - the volume of RFC's the project has dealt with is impressive with no major community rifts that I have heard of.

This page talks about the process and their code of conduct: https://github.com/rust-lang/rust/wiki/Note-development-poli...

Re: Rust 1.0: Status report and final timeline

#22

Post by AlyssaRowan » Fri, Feb 13, 2015, 8:43 PM UTC

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 registers because the compiler figured since I don't reference it again, the memory's contents are no longer important.

Current approaches to this involve explicit_bzero(), or other similar memset(0)-and-I-really-mean-it-don't-optimise-this-out techniques. (And a fair bit of testing and prayer when it comes to potential temporary copies or registers.) But unless you're doing it in assembly language, you don't really know. (The stack beneath you, such as the OS, any hypervisors, SMM, AMT, SGX, µcode etc, aside, of course!)

I'm not quite clear what Rust's behaviour with this scenario is. If it can do this easily, even potentially, I am very interested…?

Re: Rust 1.0: Status report and final timeline

#23

Post by doctoboggan » Fri, Feb 13, 2015, 8:45 PM UTC

drobilla wrote: post #15

I'm very happy to see Rust stabilize, about time we get a systems(ish) programming language with a half decent type system. With that said... I need to get some bikeshedding off my chest: I hate to let such a triviality lower my enthusiasm for a language so much, but I just can not get over that awful inconsistent closure syntax :/ I don't get it. Most everything else has a nice unique keyword syntax, fn uses (args,…

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.

Re: Rust 1.0: Status report and final timeline

#24

Post by steveklabnik » Fri, Feb 13, 2015, 8:46 PM UTC

netcraft wrote: post #21

warnhardcode wrote: post #8

Earlier quoted context omitted.

I have only the vague understanding that there are governance structures in place for open source projects. Can you go into a little detail about what aspects of this project's governance impress you?

aturon's response below ( https://news.ycombinator.com/item?id=9046882 ) outlines most of what I would say - really its the RFC process that I'm most interested with and how that is managed in an open way. There are always pet ideas and desires that complicate processes like this - the volume of RFC's the project has dealt with is impressive with no major community rifts that I have heard of. This page talks about th…

Oh, since you quoted that page, you might want to know about this PR: https://github.com/rust-lang/rust/pull/22282

Re: Rust 1.0: Status report and final timeline

#25

Post by q2 » Fri, Feb 13, 2015, 8:46 PM UTC

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

As per Github and wikipedia:

Number of contributors for Rust and time taken so far: 840, and 2 years. Number of contributors for Go language and time taken so far: 424 and 6 years.

Financial details are not known.

It seems developing new language and bringing it to reasonable level is not trivial effort.

1. Is above data correct i.e. are those contributors full time working on those languages i.e. is it full time job of those people?

2. Can we get details like number of developers/number of test engineers/number of documentation writers ...etc?

3. Is it possible to know the total amount of financial resources consumed so far in the effort?

4. Is there any research into resources required for new language development in terms of man power, time, financial resources for various languages?

It is fascinating to see a new language developed in front of us.

Re: Rust 1.0: Status report and final timeline

#26

Post by heinrich5991 » Fri, Feb 13, 2015, 8:50 PM UTC

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…

You need to put the key material into an opaque struct, which does store it on the heap. Using the `black_box` function you can zero the key material out in the destructor.

Re: Rust 1.0: Status report and final timeline

#27

Post by yuriks » Fri, Feb 13, 2015, 8:51 PM UTC

doctoboggan wrote: post #23

drobilla wrote: post #15

I'm very happy to see Rust stabilize, about time we get a systems(ish) programming language with a half decent type system. With that said... I need to get some bikeshedding off my chest: I hate to let such a triviality lower my enthusiasm for a language so much, but I just can not get over that awful inconsistent closure syntax :/ I don't get it. Most everything else has a nice unique keyword syntax, fn uses (args,…

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.

What was deprecated is the explicit closure type specification, which is only the ":" part.

Re: Rust 1.0: Status report and final timeline

#28

Post by steveklabnik » Fri, Feb 13, 2015, 8:51 PM UTC

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…

To give you an idea, Rust is actually about 8 years old in total, though it was just Graydon for the first four and a half. The language recognizable as today's Rust is about two years old, though. But it still needed that gestation to get to that state, so I'd count all of them.

Re: Rust 1.0: Status report and final timeline

#29

Post by mbrubeck » Fri, Feb 13, 2015, 8:52 PM UTC

doctoboggan wrote: post #23

drobilla wrote: post #15

I'm very happy to see Rust stabilize, about time we get a systems(ish) programming language with a half decent type system. With that said... I need to get some bikeshedding off my chest: I hate to let such a triviality lower my enthusiasm for a language so much, but I just can not get over that awful inconsistent closure syntax :/ I don't get it. Most everything else has a nice unique keyword syntax, fn uses (args,…

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.

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.

Re: Rust 1.0: Status report and final timeline

#30

Post by mbrubeck » Fri, Feb 13, 2015, 8:57 PM UTC

breckinloggins wrote: post #2

One thing I'm less clear on is what will happen after 1.0. Is there a "post 1.0 wishlist" somewhere?

This is not an official list, but it's one developer's opinion on post-1.0 priorities:

http://featherweightmusings.blogspot.com/2014/12/my-thoughts...

It also links to the list of RFCs that have been postponed until post-1.0:

https://github.com/rust-lang/rfcs/issues?q=is%3Aopen+is%3Ais...