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

Rust's 2018 roadmap

blog.rust-lang.org

Post reply on HN
Print view View original

41–50 of 253 posts

Re: Rust's 2018 roadmap

#41

Post by steveklabnik »

gandreani wrote: post #33

Lots of nice language improvements lined up for this year I haven't played with Rust but I like the ecosystem and transparency. Something that stands out is the Compatibility across editions section. Seems like they really thought this through: > you can be on a different edition from your dependencies. > Edition-related warnings...must be easily fixable via an automated migration tool (rustfix). Only a small minorit…

Glad to hear your enthusiasm!

> might not finish in time for the year or will be sub-par.

Yeah, these areas of focus are where we think we can make substantial improvements, but it may be something like how the webs services goal: last year we shipped fundamentals, this year we're shipping end-to-end awesomeness. So we may only get the fundamentals in place for this year, and maybe we'll need to focus on it next year too. We'll see!

Re: Rust's 2018 roadmap

#42

Post by aturon »

kvark wrote: post #35
aturon wrote: post #20

Earlier quoted context omitted.

There are changes that require a new edition, particularly around new keywords. However, to be clear, editions are primarily a marketing/communication/project management tool. They give us a way to try to bring together a number of threads of work into a coherent whole, with a high level of polish across the board (including docs and tooling), and then to present that work to the world with a clear story. It's worth…

That's what I've been afraid of. When epochs were announced, I thought it is kinda nice to have backwards compatibility while introducing breaking changes. It's a good technical concept. Trying to change it's role into "marketing/communication/project management tool" out of a sudden is what puzzles me. > It's worth comparing this to the recent Firefox Quantum release I don't think it's a fare comparison. Firefox Qua…

> Trying to change it's role into "marketing/communication/project management tool" out of a sudden

FWIW, this was part of the story from the beginning (https://github.com/rust-lang/rfcs/pull/2052)

> Firefox Quantum doesn't involve much of breaking changes (if you don't consider deprecating the old plugins one, that is).

They weren't just deprecated; they stopped working.

> I don't see Q3 2018 as any sort of "quantum leap"

For people following Rust closely, the Rust 2018 release won't be so special. But most people aren't keeping up with the details of new releases every six weeks; for them, we have an opportunity to take stock of what's changed over the last couple of years, explain the impact on idioms and how to transition code.

Remember that Rust is fairly unique in having a six week release cycle. Most other languages have a much slower release cycle, where every release is "major". Editions give us a way to pull together the rapid work we're doing into a coherent story.

From a management perspective, it's also a very useful way of focusing our effort as a community, to make sure all the pieces we've been working on are coming together into a polished whole on a clear timeline.

Re: Rust's 2018 roadmap

#43

Post by pimeys »

I've been spending a good majority of my work hours with Rust and especially writing network services using Tokio. When things work there, it is very reliable, fast and has a tiny footprint with resources.

Now reading the promise to get a stable async/await and also having Tokio 0.2 in the pipeline, I'd say async Rust might be ready for prime time.

Don't get me wrong here, I enjoy using Tokio, but I'd say if you're not very experienced yet with Rust, and you try to mix an asynchronous database query and a web request together in the same event loop, or you wanted to use a reference to `self` in an inner future (which might suddenly want a static lifetime), you quite easily end up into trouble... Trouble like a couple of pages of errors, that are just not readable at all. And you get out maybe by knowing to use a `map_err` in that one future call after the second `then`, or by not referencing `self` in your futures...

Now when reading the announcement, and I've read and understood the RFC's, the next generation of async Rust will help here tremendously. And I will definitely be amongst the first ones adding the changes to my code, to finally make it cleaner and nicer for the next developer to jump in.

Re: Rust's 2018 roadmap

#44

Post by kibwen »

the_mitsuhiko wrote: post #14
kibwen wrote: post #11

Earlier quoted context omitted.

The tracking issue for const generics is here: https://github.com/rust-lang/rust/issues/44580

One of the biggest issues with looking at tracking issues for me is that it's impossible to judge either priority or complexity. This one for instance is a good one. Tags say implemented and approved, the checklist is mostly docs. Yet it looks like from the discussion that this issue is closer to not landing at all in this form than landing.

As with many large features, people with their heads down will be working on it for a long time without much fanfare, until suddenly the feature appears in a mostly-usable state shortly before it is able to be stabilized. Not much solace for the people who want to be able to predict when features will land, though the tracking issue should at least give some idea as to which developers are prioritizing this so that one can contact them directly for more information.

Re: Rust's 2018 roadmap

#45

Post by nothrabannosir »

steveklabnik wrote: post #2

You may have noticed a subtle change: what was previously called “epochs” is now “editions.” Lots of great stuff coming this year! As always, happy to answer any questions.

Thanks for keeping to normal, obvious names and reducing the cognitive load. I’m not a fan of unnecessary idiosyncrasies so this is a welcome change.

Re: Rust's 2018 roadmap

#46

Post by masklinn »

gandreani wrote: post #33

Lots of nice language improvements lined up for this year I haven't played with Rust but I like the ecosystem and transparency. Something that stands out is the Compatibility across editions section. Seems like they really thought this through: > you can be on a different edition from your dependencies. > Edition-related warnings...must be easily fixable via an automated migration tool (rustfix). Only a small minorit…

Editions sound like an interesting riff on C/C++'s standards thing.

The post isn't really clear what will be gated behind editions though, only non-BC syntactic changes (e.g. literally just new keywords)?

Re: Rust's 2018 roadmap

#47

Post by [deleted] »

kibwen wrote: post #36
pknopf wrote: post #19

Earlier quoted context omitted.

GC's have some kind of inherit reference counting which makes releasing pointers safe, in any direction. You can't do that with C/C++ without something like glib.

> GC's have some kind of inherit reference counting which makes releasing pointers safe, in any direction. It sounds like you're mostly worried about memory leaks, but the primary concern with trying to get two separate GCs to play nicely isn't leaking memory, it's double-frees (both GCs trying to collect the same resource) and use-after-free (code in one language trying to use a resource that's been accidentally col…

[deleted]

Re: Rust's 2018 roadmap

#48

Post by steveklabnik »

masklinn wrote: post #46
gandreani wrote: post #33

Lots of nice language improvements lined up for this year I haven't played with Rust but I like the ecosystem and transparency. Something that stands out is the Compatibility across editions section. Seems like they really thought this through: > you can be on a different edition from your dependencies. > Edition-related warnings...must be easily fixable via an automated migration tool (rustfix). Only a small minorit…

Editions sound like an interesting riff on C/C++'s standards thing. The post isn't really clear what will be gated behind editions though, only non-BC syntactic changes (e.g. literally just new keywords)?

Yeah, this post is intended to be a high-level explanation, so we didn't dig into the details. I left a comment below about this: https://news.ycombinator.com/item?id=16569751

Re: Rust's 2018 roadmap

#49

Post by pas »

nothrabannosir wrote: post #45
steveklabnik wrote: post #2

You may have noticed a subtle change: what was previously called “epochs” is now “editions.” Lots of great stuff coming this year! As always, happy to answer any questions.

Thanks for keeping to normal, obvious names and reducing the cognitive load. I’m not a fan of unnecessary idiosyncrasies so this is a welcome change.

For me epoch is more readily associated with new version new features, whereas edition is more like format, such as Mobile edition, Tablet edition, etc.

Re: Rust's 2018 roadmap

#50

Post by Symmetry »

As someone who does a lot of firmware I think I really need to explore more of what Rust brings to the table there. Interrupts are a major source of concurrency and I'd like to be fearless about those issues.
Post reply on HN