Announcing Rust 1.33.0 | Hacker News Reader

Announcing Rust 1.33.0

blog.rust-lang.org

232 pointssteveklabnik42 comments

This release also enables Windows binaries to run in Windows nanoserver containers. Previous releases would produce Windows binaries that depended on shell32.dll for parsing the commandline into argv, but this DLL is not present in nanoserver. With this release the standard library implements the logic of parsing argv itself.

https://github.com/rust-lang/rust/pull/56568

That is quite cool

This is news to me! This is pretty cool.

Rust seems like a great language if you want the run anywhere capability of C, with considerably more safety.

Expanding the capabilities of const fn is a tremendous achievement, years in the making. Congratulations to all involved (though of course there's much work yet to be done)! I especially appreciate that the syntax for const fn is "just" Rust, without being any sort of DSL or metalanguage, making it quite approachable and usable. The stabilization of the Pin API is also quite the achievement; the GitHub issue discussing it is one of the densest and most extensive threads I've seen: https://github.com/rust-lang/rust/issues/49150

I have been paying attention to Rust for the past year or so and I think it'll be the next language I will end up learning. I do have a question: what is const fn supposed to be used for? Is it for denoting pure functions? That would be really nice, considering that not many non-functional languages explicitly recognise pure functions.

const fn is used for compile-time programming. "pure" is a bit over-loaded of a term, but you can sort of think of it that way, sure.

You can of course also run these functions at runtime; they're a more restricted kind of function. You cannot even currently use if inside of them, for example. We're working on expanding it out, but we're going slow because it's important for soundness reasons.

Should we think of them like the equivalent of constexpr functions in C++?

I am not familiar enough to declare an equivalence, but roughly the same, yes.

Yes, but hopefully without the amusing issue of non-constant constexpr functions in C++ :)

http://b.atch.se/posts/non-constant-constant-expressions/

So they're more like C++20's consteval?

http://wg21.link/p1073r3

As I understand it, not really no.

The conceptual difference between constexpr and consteval is that consteval is guaranteed to be evaluated at compile-time, so unlike constexpr code, consteval code will never actually end up as a function in your binary.

Rust's const fns on the other hand can be called at runtime, so in that respect they'd be closer to constexpr.

Ah thank you, that makes a lot of sense! It's good that this sort of stuff can be made explicit... a lot of C++ compile-time evaluation optimisations feel like magic to me.

When a const fn is called from a const context, like assigning a value to a constant, the compiler interprets the function at compile time.

If you're interested in more info the docs [1] and the New Rustacean 1.31 Part 2 podcast [2] are helpful.

[1] https://github.com/rust-lang-nursery/reference/blob/master/s...

[2] https://newrustacean.com/show_notes/news/rust_1_31/part_2/in...

Finally, the Duration::as_... functions are stable. Allows one to do duration calculations much more nicely now that it's one variable.

I was actually on nightly for a bit because of this, then I realized I only needed them in a few places so I did it myself so I could go back to stable. I'm glad this is in the release. :)

It is nice to see the const fn improvements!

maybe this is normal for the minor version Rust announcements, but is the page missing a link to the list of contributors?

We're going to publish that soon -- it needs to be generated after the release is tagged and it took longer today. We'll edit the blog post when it's ready to go.

To be even more clear, I had to give my old computer back to Mozilla, and had not yet set up all of the necessary stuff on my new computer yet. For Reasons(tm), the contributor list is a full webapp backed by postgres, and so I have to get all that set up locally. Oops!

I really need to re-write it to make it more simple this time.

UPDATE: list is live at https://thanks.rust-lang.org/rust/1.33.0, blog post has been amended to include the link. Should show up in a few minutes. Thanks for your patience, everyone.

Does anyone use Rust for hobbyist game development? What is your experience?

You might want to ask over at /r/rust_gamedev

You may find this site useful: http://arewegameyet.com

Is there a list of these websites anywhere?

I don't think so, but so far the only other such websites I've seen are http://www.arewewebyet.org/ and https://areweasyncyet.rs/ .

Though looks like there used to be a areweembeddedyet.org[1], but now https://docs.rust-embedded.org/ seems to be the main jumping off point for rust embedded.

[1]: https://github.com/rust-embedded/wg/issues/15

Check http://arewemetayet.com/

https://wiki.mozilla.org/Areweyet

I do, it's generally pretty nice and there are a lot of well thought-out libraries available. However, figuring out how to interop between a scripting language and an ECS isn't the most trivial thing since rust's type system doesn't always want to be flexible, YMMV. I'm currently using GGEZ for rendering and utility functions, but if you wanted something a bit larger and more opinionated/mature, amethyst is your current best bet. I'm happy to answer any other questions about it! It's been an interesting learning experience so far and I plan to put a lot more down on paper once I have at least a small game running end to end.

* The edit-compile-run cycle is pretty slow in the default configuration. If you compile in debug, it's too slow to run nicely, if you compile in release, you wait for the compile to finish. What I've done is to override the debug profile to optimize dependencies, it makes the game much faster. Also, I'm setting the linker to lld because it is multithreaded and much faster in general than the default linux bfd.

* You have to do a lot of stuff yourself. The experience is not like with unity or godot where you have a powerful editor together with a powerful engine taking care of everything for you.

* There is a large ecosystem below the level of unity/godot which lets you choose very precisely how much you want to do yourself and how much you want to have abstracted away. Games in Rust have been published so most of the stuff is around and if you are already familiar with SDL or LÖVE you will find the two in Rust as well.

* The community on IRC and Gitter and other places is really helpful to people with questions. Both gamedev related and unrelated to gamedev.

In general, I think if you like gamedev as a hobby and want to learn Rust, it's a great opportunity. If you want quick progress on your game and don't like unpolished stuff then I'd recommend C# or Gdscript. For me, I've already done Rust in other areas and really enjoyed doing games as well.

Where does async stand at this point?

https://areweasyncyet.rs

To summarize:

* The Pin trait is stable.

* std::task/std::future, i.e., the ability to use futures is still unstable.

* The async/await syntax is still unstable. And apparently being bikeshedded like mad, from what I've heard.

Note that it is usable in nightly. So if you just want to play with it, don't let the fact that it's unstable stop you.

Occasionally a nightly will break your code (the most recent case being when LocalWaker was renamed), and you might have to wait a few more days after that for the futures-preview crate to catch up.

It's more common on less popular OSes, like FreeBSD, so I ended up sticking to stable for those platforms (e.g. production).

https://areweasyncyet.rs/

right about where ocaml-multicore is :)

The const improvements are indeed awesome.

I wonder if there were any big improvements to compile times? Is that in the road map for this year?

We have not published a roadmap yet (I'm getting there), but compile times are always of a lot of concern to the compiler team and they're going to be working on it for sure. It's the #1 requested feature.

I personally don't understand why compile times are such a concern, as the larger libraries I have worked with take less than a minute to compile. Are there programs that take hours to compile?

The edit + reload cycle is the biggest concern, though it's mostly moot these days with incremental compilation. However, I still dislike updating dependencies because it'll take several minutes to rebuild everything.

Also, building third-party tools is a pain as well (compile diesel or ripgrep sometime), which is the most annoying part for me.

Also, it's a bit annoying for CI since I like to make sure everything can build from scratch, and it can be quite the wait to see if your build succeeded.

Could you say more about the annoyances you experienced while compiling ripgrep? Is it just the time it takes to build it or is there something else?

I think one of the main problems is programs compiled in debug mode are surprisingly slow and unrepresentative of things compiled in release mode. So, some projects have to always compile in release mode while testing things, and it takes a long time.

Does anyone know of any good resources for learning Rust from a beginner's perspective? For someone with very little or no C/C++ experience?

I think The Rust Book might be good for you: https://doc.rust-lang.org/book/

Also there are more resources here: https://doc.rust-lang.org/

Reply on news.ycombinator.com