Live data from Hacker News

Rust 1.0: Status report and final timeline

blog.rust-lang.org

11–20 of 128 posts

Re: Rust 1.0: Status report and final timeline

#11
Even though 1.0 isn't out yet, today you can use Rust for many real projects. I'm unsure whether I'd bet my business on it yet, but I'd be open to the idea. And I'm usually a very late adopter.

I've been building a 3d game with Rust and OpenGL, ported from a C++ codebase. So far, my experience has been very positive. Despite Rust's supposed immaturity, it feels more polished than C++ in many ways. Forward progress has been much faster than it was with C++.

Does anyone else have a story (positive or negative) about using Rust in real projects?

Re: Rust 1.0: Status report and final timeline

#12
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 people who say that the release is premature, but I'm personally not one of them. The core of the language is ready, even if some pieces around the edges could still use some refinement (and will see refinement, backwards-compatibly, in the coming releases).

  > I'm surprised at how aggressive the release schedule is, 
  > given how things are still churning a good deal.
You'd be surprised at how much of a motivator a concrete release date is. :) Churn is happening now because of the impending release, not despite it. The language intends to have a solid compatibility story (via semver) for post-1.0 releases, so everyone who'd been holding off on changes for the past few years has suddenly come out of the woodwork to implement them.

Re: Rust 1.0: Status report and final timeline

#13

Even though 1.0 isn't out yet, today you can use Rust for many real projects. I'm unsure whether I'd bet my business on it yet, but I'd be open to the idea. And I'm usually a very late adopter. I've been building a 3d game with Rust and OpenGL, ported from a C++ codebase. So far, my experience has been very positive. Despite Rust's supposed immaturity, it feels more polished than C++ in many ways. Forward progress ha…

Here's a company using Rust to sandbox executable financial contracts: https://codius.org/blog/codius-rust/ . The blog post is unfortunately light on details, but I'm hoping to hear more from them soon. I'd also love to see wycats or carllerche weigh in on Skylight.io's use of Rust from within a Rubygem.

Re: Rust 1.0: Status report and final timeline

#14
post #10
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.

There's a governance structure? That's news to me. I was under the impression that a few primary contributors (mostly/all mozilla employees?) are gatekeepers to merging anything. Having an "RFC" issue tracker isn't the same as having a governance structure. Edit: I suppose you could call the above a 'governance structure', but I'm having a hard time seeing anything impressive/different about it from other open source…

There's a core team (https://github.com/rust-lang/rust/wiki/Note-core-team) responsible for final decisions on the direction of the language and libraries. Proposed changes go through a public RFC process (https://github.com/rust-lang/rfcs#what-the-process-is), including those proposed by members of the core team -- which are frequently revised or even rejected as part of this process. See for example the path API RFC (https://github.com/rust-lang/rfcs/pull/474).

PRs can be reviewed by anyone from a large pool of reviewers. PRs that introduce new features etc. have to come after an RFC is approved, however.

The core team includes Huon Wilson, Yehuda Katz, and Steve Klabnik, none of whom work for Mozilla (though the latter two have done some contracting work). We hope to continue expanding to include other stakeholders.

EDIT: Steve tells me he's currently working as a "seasonal employee" at Mozilla for doing Rust docs, but it's a short term thing.

Re: Rust 1.0: Status report and final timeline

#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, in, parenthesis), proc syntax made consistent sense, then lambda is this crazy || linenoise thing that doesn't fit in at all. The "borrow the good ideas from other languages" approach has resulted in a great language, but "cram random syntax from other languages that doesn't fit" doesn't work out so well.

Re: Rust 1.0: Status report and final timeline

#16

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,…

As a Rubyist, I found the closure syntax quite comfortable, as they're almost identical. Passing a closure or lambda to some function foo:

        x = foo {|x|   x + 1 }    # Ruby
    let x =  foo(|x| { x + 1 }); //Rust
    let x =  foo(|x|   x + 1 );  // single expressions don't need {}s
That said, I'm not sure what the exact reason was for choosing the syntax, as that was before my time.

Re: Rust 1.0: Status report and final timeline

#17

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,…

The natural thing to want in a C-like syntax is the "arrow function" closure syntax (like ES6 or C#), but that required too much lookahead to parse. Having a keyword discourages functional style, which would be a shame in a language with a powerful iterator library. So Rust went with the Ruby/Smalltalk-style bars, which are nice, concise, and easy to parse.

Re: Rust 1.0: Status report and final timeline

#18

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,…

As a Rubyist, I found the closure syntax quite comfortable, as they're almost identical. Passing a closure or lambda to some function foo: x = foo {|x| x + 1 } # Ruby let x = foo(|x| { x + 1 }); //Rust let x = foo(|x| x + 1 ); // single expressions don't need {}s That said, I'm not sure what the exact reason was for choosing the syntax, as that was before my time.

> That said, I'm not sure what the exact reason was for choosing the syntax, as that was before my time.

I think the reason is just that it's very concise, and lightweight closure syntax makes things like `Option::map` feel like first-class parts of the language. The closure you pass just sort of seamlessly "blends in".

Note that having especially sugary here is not so uncommon, for example Haskell has `\x -> blah` for Rust's `|x| blah`.

I'm personally very happy that the closure syntax is as concise as it is.

Re: Rust 1.0: Status report and final timeline

#20
post #9

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

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.

This is the big one I'm waiting on before betting the farm on Rust, and I suspect I'm not the only one.
Post reply on HN