Announcing Rust 1.34.1 | Hacker News Reader

Announcing Rust 1.34.1

blog.rust-lang.org

47 pointspietroalbini17 comments

How much longer until async/await is as easy to use as it is in JavaScript?

Several releases at the minimum. The futures API has been stabilized for 1.36, but the async/await call syntax is still unstable (from what I understand).

Even then, there will still be more friction in rust compared to javascript, since there is just more to make decisions about (e.g. ownership, it's generally lower-level, etc.)

To see a full status on async stuff in rust, see https://areweasyncyet.rs/

Edit: There will be a ton of churn as well in the eco-system since everybody will need to move to the new api, but there are api shims that let you use the new stuff on the old stuff, so that makes it a little easier. There's going to be a ton of _visible_ progress this year.

async/await still scares me a little since I would prefer that the language core stay small and universal.

async/await is sooo much easier to use than combinators though. I struggle in remembering when I should be using and_then/or_else/map/then, and then juggling all the references as things pass into and out of closures.

I wrote a small redis clone with async/await and it was a joy to write. It was fast and so easy to reason about. It's so worth it to add it to the core language.

`async`/`await` syntax hasn't been implemented. `std::future` will be stabilized in 1.36. It will be a decently long time until it's as "easy to use as it is in JavaScript".

You can follow the progress here: https://areweasyncyet.rs/

I would say that a realistic target for being able to use async/await in general projects using the stable compiler is the end of the year. Any earlier than that you will be able to use it, but you'll be in the same situation as today: fragmented ecosystem (0.1/0.3/std futures split), incomplete or missing features, missing syntax (await/async for loops/etc.) and subpar diagnostics. Things are slowly but surely coalescing into a nice story, but right now the people that are excited are going off potential more than what is already there, as interesting as many of the individual pieces are.

Years, plural.

Isn't there a 'Rust announcements' mailing list instead of having HN polluted with every minor point release?

If it wasn't upvoted it wouldn't make it to the front page.

Just about anything with 'Rust' in the title makes it to the front page.

Note that HN's ranking algorithm also rapidly sinks things off the front page whose titles contain common keywords like "Rust", "Go", "Apple", etc.

That's an interesting observation, but not true!

As far as stories like this go, we do penalize minor release announcements across the board (unless there's something there that gratifies intellectual curiosity), but that's done manually.

Interesting, thanks for the insight. :)

The argument is flawed because the system doesn't ask for the majority's opinion. I consider minor releases just noise personally.

Yep. To put it simply: it would be quite different if every user had a downvote button available.

I'm a Rust fan, and I'd say that Rust announcements are so often upvoted because they contain interesting developments, but in this case it looks as though this patch release only contains minor bugfixes. When I saw it pop up on HN's front page I sort of thought we were going to get something juicy like a security advisory... the only interesting news here is apparently that the Rust developers also issue patch releases for relatively mundane reasons. :P

Rust is a major development in the world of systems programming and as such it definitely deserves its share of attention. But point releases are best kept to the in-crowd and major releases are the moment to make large public announcements.

Reply on news.ycombinator.com