Rust 1.21(blog.rust-lang.org)
blog.rust-lang.org
Rust 1.21
https://blog.rust-lang.org/2017/10/12/Rust-1.21.html
41 comments
For those curious about getting involved with Rust, note that right now is an ideal time. :) This last quarter of the year is reserved for "the impl period", a collection of all-out heads-down sprints designed to make sure that none of the remaining milestones from our 2017 roadmap get left behind. There are currently 37 working groups in a variety of disciplines, some more involved than others and some more popular than others, but mentorship is offered to all who'd like to contribute!
See our most recent newsletter for the impl period here: https://internals.rust-lang.org/t/the-impl-period-newsletter...
See our most recent newsletter for the impl period here: https://internals.rust-lang.org/t/the-impl-period-newsletter...
Here's a page with lots of good starter issues to work on, and many other issues for more experienced community members.
https://www.rustaceans.org/findwork
Note that this page appears to be displaying open issues, but doesn't specify if someone is actively working on an issue, so it might take a few tries to find one that's up for grabs.
https://www.rustaceans.org/findwork
Note that this page appears to be displaying open issues, but doesn't specify if someone is actively working on an issue, so it might take a few tries to find one that's up for grabs.
Links to the different groups and their chat pages: https://blog.rust-lang.org/2017/09/18/impl-future-for-rust.h...
Hi, I'm the author of this Python parsing library: https://github.com/erezsh/lark
I would like to port it (or parts of it) to Rust, for fun and speed. Since the grammars are EBNF, it means the same grammars can work in both Rust and Python (I already support some interoperability with Javascript).
However, I'm very new to Rust, and its type system and memory management mechanics seem a bit intimidating. Do you think anyone would be interested in mentoring me or even in actively helping me to port it? And if so, where/who should I ask? Thanks
I would like to port it (or parts of it) to Rust, for fun and speed. Since the grammars are EBNF, it means the same grammars can work in both Rust and Python (I already support some interoperability with Javascript).
However, I'm very new to Rust, and its type system and memory management mechanics seem a bit intimidating. Do you think anyone would be interested in mentoring me or even in actively helping me to port it? And if so, where/who should I ask? Thanks
What if you have absolutely zero experience with LLVM or compilers in general (beyond reading about them)
I've been contributing to the compiler for years and have never really touched any of the LLVM stuff. Compilers are large, there's a lot of stuff to do, and plenty of it is not-complicated stuff that doesn't take effort to learn. Many (most?) of our contributors start off with zero compiler experience.
https://www.rustaceans.org/findwork might help you find something easy to work on.
https://www.rustaceans.org/findwork might help you find something easy to work on.
There's plenty of groups working on rust libraries rather than directly on the compiler.
And even in the compiler itself there's plenty of work to be done that doesn't even come close to the LLVM and that have mentoring instructions[1]. The point of entry that I personally found successful when starting to contribute was modifying and expanding the compiler's diagnostic output[2], as it gives you something to grep for and work it out from there.
Also, be aware that beyond just asking questions in the issue tracker and on the official #rust IRC channel, each Working Group has a room on gitter[3] where there are people more than eager to help any newcomers.
My advice would be to look out for anything that you might find interesting, ask for help whenever you get stuck and just read the code. There's plenty of opportunities to make an impact[4] :)
[1]: https://github.com/rust-lang/rust/labels/E-mentor
[2]: https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is...
[3]: https://gitter.im/rust-impl-period/
[4]: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.m...
Also, be aware that beyond just asking questions in the issue tracker and on the official #rust IRC channel, each Working Group has a room on gitter[3] where there are people more than eager to help any newcomers.
My advice would be to look out for anything that you might find interesting, ask for help whenever you get stuck and just read the code. There's plenty of opportunities to make an impact[4] :)
[1]: https://github.com/rust-lang/rust/labels/E-mentor
[2]: https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is...
[3]: https://gitter.im/rust-impl-period/
[4]: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.m...
Maybe I should have added "... but would like to learn a thing or two, without having to do follow a whole CompSci education specialising in the subject first"
I have recently started to get involved helping out with the rust-bindgen program for generating rust bindings to C++ programs. It really is amazing the amount of work they put into creating issues for small things for new people to fix and mentoring them through the issue. I don't know of any programming languages that put this much work into helping new people get started. It really was a great experience to be have bite sized things to fix that actually feel like contributing to a project without worry that you are taking on more than you can chew.
I had the same experience. I was given a small performance issue with iterators to diagnose and had help from someone more experienced in that area.
I learned about how llvm does loop optimization and wrote a small null loop optimization pass. It turned out to be related to another problem and not need, but the experience was terrific.
I learned about how llvm does loop optimization and wrote a small null loop optimization pass. It turned out to be related to another problem and not need, but the experience was terrific.
Looks like it's missing from the release notes 1.21 should also contains fixes for building Emscripten on Win32 which was broken by some small changes in 1.20.
Given that Emscripten isn't a tier 1 platform it wasn't a big deal but wanted to call it out in case anyone ran into it with 1.20.
Given that Emscripten isn't a tier 1 platform it wasn't a big deal but wanted to call it out in case anyone ran into it with 1.20.
Yeah, we don't include all fixes in the release notes; a volunteer goes through and looks at PRs tagged for the release notes, and possibly goes through all the PRs to see if there's anything missing. Determining what to include and what not to can be tricky!
Basically, the blog post is a subset of the release notes, the release notes are a subset of PRs, and PRs are a subset of commits.
Basically, the blog post is a subset of the release notes, the release notes are a subset of PRs, and PRs are a subset of commits.
Yeah, but this post seemed pretty barren. Since I skim a lot, it felt like nothing happened in the last release.
Yes, this release was fairly small. It happens!
What happened to impl Trait? I was quite excited to see it under 1.21 in the milestone predictions thread, but it has since been moved to "horizon".
https://internals.rust-lang.org/t/rust-release-milestone-pre...
https://internals.rust-lang.org/t/rust-release-milestone-pre...
To explain more besides Steve's commit, there has been another RFC that significantly expands the scope of impl Trait. It was accepted, but it also had the effect of punting the stabilisation of the feature a bit until things settle down. I don't know if the "conservative" version of impl Trait is going to land first anyway, but I find it just reassuring that people aren't rushing things.
(For reference: The original impl Trait: https://github.com/rust-lang/rfcs/pull/1522 The refinement, readying it for stabilisation: https://github.com/rust-lang/rfcs/pull/1951 The latest one, which gives it more expressive power: https://github.com/rust-lang/rfcs/pull/2071 )
(For reference: The original impl Trait: https://github.com/rust-lang/rfcs/pull/1522 The refinement, readying it for stabilisation: https://github.com/rust-lang/rfcs/pull/1951 The latest one, which gives it more expressive power: https://github.com/rust-lang/rfcs/pull/2071 )
The milestone prediction thread is just that; a prediction. It's still very much coming, just not yet. It won't be in 1.22 either, as that went into beta today.
https://github.com/rust-lang/rust/issues/44721 is the issue you want to track. There's been a lot of chatter in recent days.
https://github.com/rust-lang/rust/issues/44721 is the issue you want to track. There's been a lot of chatter in recent days.
Well, I rebuilt my RSS feed reader with the new Rust version, and nothing broke. Today is going to be a good day.
I have yet to see any breakage of any of my projects on stable break after an update with rustup to new versions, and only one on nightly.
There are some deprecation warnings that I've had to cleanup, but otherwise, it's been an amazingly stable upgrade process since the 1.0 release.
There are some deprecation warnings that I've had to cleanup, but otherwise, it's been an amazingly stable upgrade process since the 1.0 release.
> my RSS feed reader
Mind sharing a link?
Mind sharing a link?
No matter how bad those Learn X in 21 Days books were, I really wish there was something for Rust. Sometimes it seems like Rust moves too fast and docs are always quickly out if date or fail to inclusive enough to be useful.
I often hear "since 1.x you should be doing y with z feature now but that is only in current and the rust book doesn't have a section on it yet"
Rust to me is still very much feels to me a moving target.
I often hear "since 1.x you should be doing y with z feature now but that is only in current and the rust book doesn't have a section on it yet"
Rust to me is still very much feels to me a moving target.
These days, new features are required to be documented before they're stabilized, so you shouldn't be running into that anymore.
Plus, even with that advice, you can still do y the old way; we don't break things, we add new ones. Idioms are always evolving in every language, though it's true that in new ones, they evolve faster.
Plus, even with that advice, you can still do y the old way; we don't break things, we add new ones. Idioms are always evolving in every language, though it's true that in new ones, they evolve faster.
At the moment, there are two versions of the Rust book online. One is obsolete and the other is unfinished.[1]
[1] https://doc.rust-lang.org/book/
[1] https://doc.rust-lang.org/book/
To be clear about the unfinished status of the new book, it's just becuase we have much, much higher standards this time around. All of the chapters have a draft of some kind, and are basically in various stages of editing, plus I need to finish the appendix. That editing is "by the professional editors at No Starch", so it's a bit of a higher bar than most docs included with open source projects.
The old book is not so much "obsolete" as it is "has significant weaknesses as a text so we re-wrote it"; everything in there still applies, and still works.
The old book is not so much "obsolete" as it is "has significant weaknesses as a text so we re-wrote it"; everything in there still applies, and still works.
> That editing is "by the professional editors at No Starch", so it's a bit of a higher bar than most docs included with open source projects.
How is your experience with No Starch, if I may ask? I have a few eBooks by them that I got in various humble bundles; they're usually decent enough introductions to the subject matter at hand.
How is your experience with No Starch, if I may ask? I have a few eBooks by them that I got in various humble bundles; they're usually decent enough introductions to the subject matter at hand.
I have generally enjoyed the experience. I own a lot of their books. They were one publisher that generally aligned with our open source values. The book is much better because of them.
That is entirely untrue. Releases are regular, big changes are anything but.
Responding "this is entirely untrue" to someone who is saying how something feels to them is not only overly harsh, but entirely inappropriate. You cannot dictate people's feelings. You might think they have misconceptions that are leading to how they feel, but that doesn't make how they feel untrue.
I can understand if you feel frustrated because you don't think this feeling is warranted, but this is not a constructive way to express that, nor fix the problem.
I can understand if you feel frustrated because you don't think this feeling is warranted, but this is not a constructive way to express that, nor fix the problem.
I think there was just enough content in his reply to escape the accusation that he was merely gainsaying (which would be dictating feelings, as opposed to providing information that might dispel them.)
Depending on how you define "big changes". For example, I consider the static reference convenience feature described in the 1.21 release announcement to be a small new feature, but it does affect how people write code (that's kind of the point! :P ).
> Depending on how you define "big changes".
The way every reasonable person would. This release being the obvious example.
The way every reasonable person would. This release being the obvious example.
Rust to me is still very much feels to me a moving target.
1.X is backwards compatible to 1.(X-N), and the releases are on a regular cycle... like Go and Linux (well minus semvar stuff, linux just doesn't break userland). Each release _does_ add new things, but they don't do _break_ old things.
I think that's missing the point. A language can be a moving target while still being backwards-compatible. The textbook example is C++: A C++17 compiler can compile C++03 code, C++11 code and C++14 code [1], so the language is backwards-compatible. Meanwhile, each new release seems to add so many new features to the language and stdlib that idiomatic C++17 code can be wildly different from idiomatic C++11 code and even more so from idiomatic C++03 code.
[1] Except, probably, for corner cases that I'm not aware of because I don't do C++ anymore.
[1] Except, probably, for corner cases that I'm not aware of because I don't do C++ anymore.
It's not quite like that in Rust though - in C++ modern features replace older features but in Rust that only happens in the detail. There isn't often an equivalent to unique_ptr/shared_ptr changing how you should to all pointer work.
its not just the lang. can't use two random libraries together because one still uses old hyper and another uses new hyper.
DLL hell is far older then Rust.
Can anyone recommend a good video course for learning Rust? I find I do better with video courses than simply reading (though I will take a look at the books mentioned in other comments).
http://intorust.com/ is pretty good
I did a double take there, since more parallelism often has the opposite effect (like computation, memory usage that would be spread out over time now happens at once, causing more memory overhead). The linked github issue[0] explains though:
> It also allows the main thread to switch between either translation or running LLVM, which allows to reduce peak memory usage since not all LLVM module have to be kept in memory until linking.
So I guess the idea is: the code that has already been translated can be processed by LLVM before all translation is finished, so it can also be released earlier. Very nice!
[0] https://github.com/rust-lang/rust/pull/43506