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.
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.
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.
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.
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.
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. :)
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.
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.
First of all, you have obviously no clue about any qualitative nor quantitative measure of improvement in terms of performance improvements. "Indeed awesome" is something that doesn't even relate to computer science as everything is context-dependent.
But that's not the point I want to make. What I would like people to see is what kind of profoundly uneducated, uninformed and blatantly misleading, perpetuating obvious fallacies, comments you post on this website on a daily basis. So I took about 5 minutes (but I could have literally kept on forever) to gather a sample of the kind of putrid garbage you comment daily on this website. I think that it is crucial that individuals of your kind are permanently prevented from spreading their beliefs-I insist, beliefs, not facts, when answering to people's questions. There is no ordering, all of the quotes below are equally pathetic :
1)
Yep. Exactly this. If you get a laptop that a GNOME developer uses, chances are you’ll run into maybe two issues a year. But try to get GNOME to run on two 4K displays and an RTX.
But here’s the thing. Linux has won. Desktop is a dying market. Linux is literally the most used operating system on phone and in the data center, which is where it counts.
>> I run three 4K displays using nVidia GeForce
>> You do not cite a single number about proportions of desktops to laptops, hence you are simply assuming being right based on the fact that you think so. Corporate offices are full of desktops and I can vouch for it first hand.
>> I wonder how much Microsoft/IBM DCs run Linux instead of licensed products they've been used to for years.
>> Android and Linux are not the same. I would have expected from such a knowledgable computer science professor as you are to be able to discern the two.
2)
Apple has transformed into a company that lags in innovation and only makes safe moves.
>> Yeah definitely haven't heard of any new chips/designs/connectors/models in the last 10 years
3)
I'm very worried about the bees. My theory is that the bees are going to go extinct, and that will be the butterfly that wipes us out.
At the very least it seems highly probably we'll be in a state of total anarchy in a new dark age within the next fifty years thanks in part to unethical uses of technology.
>> As much as bee extinction is an actual concern that should be addressed with particular emphasis on preserving the species, your formulation and the scenario you are extrapolating are plain and simple displays of the delusional person that you are and a medical treatment should be followed through immediately.
4)
The reality of a language as large as C++ is that each project will only use a small subset of the language and libraries, and the nature of object oriented programming leads to vastly different architectures for similar problems.
If you can, I would learn Rust instead. Rust is a much smaller language that purposely limits the way you use the language to encourage particularly safe practices, and tends to favor designs that are hierarchical instead of allowing hairball object graphs. Rust also guides you at the compiler level in ways that C++ programmers must learn to do by heart, or simply leak memory and create nasty patterns in their code.
>> Adequate OO implementations rely on architectural and design patterns to solve similar problems efficiently when applicable
>> I am not a Rust programmer and will not comment on anything related to it's features, nevertheless I can guarantee that only a mentally deficient individual would suggest a "purposely self-limiting language" for safety reasons and stating that C++ programmers "MUST LEARN BY HEART" how to write their code as there was not any sort of documentation available on earth.
5)
So I don't know how to fly a commercial airliner, but I could probably figure my way around a small single prop airplane. That's basically the difference between...
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.
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.
45 comments
[ 2.7 ms ] story [ 99.8 ms ] threadYou 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.
http://b.atch.se/posts/non-constant-constant-expressions/
http://wg21.link/p1073r3
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.
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...
maybe this is normal for the minor version Rust announcements, but is the page missing a link to the list of contributors?
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.
https://github.com/rust-lang/rust/pull/56568
Rust seems like a great language if you want the run anywhere capability of C, with considerably more safety.
* 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.
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.
I wonder if there were any big improvements to compile times? Is that in the road map for this year?
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.
But that's not the point I want to make. What I would like people to see is what kind of profoundly uneducated, uninformed and blatantly misleading, perpetuating obvious fallacies, comments you post on this website on a daily basis. So I took about 5 minutes (but I could have literally kept on forever) to gather a sample of the kind of putrid garbage you comment daily on this website. I think that it is crucial that individuals of your kind are permanently prevented from spreading their beliefs-I insist, beliefs, not facts, when answering to people's questions. There is no ordering, all of the quotes below are equally pathetic :
1) Yep. Exactly this. If you get a laptop that a GNOME developer uses, chances are you’ll run into maybe two issues a year. But try to get GNOME to run on two 4K displays and an RTX. But here’s the thing. Linux has won. Desktop is a dying market. Linux is literally the most used operating system on phone and in the data center, which is where it counts.
>> I run three 4K displays using nVidia GeForce >> You do not cite a single number about proportions of desktops to laptops, hence you are simply assuming being right based on the fact that you think so. Corporate offices are full of desktops and I can vouch for it first hand. >> I wonder how much Microsoft/IBM DCs run Linux instead of licensed products they've been used to for years. >> Android and Linux are not the same. I would have expected from such a knowledgable computer science professor as you are to be able to discern the two.
2) Apple has transformed into a company that lags in innovation and only makes safe moves.
>> Yeah definitely haven't heard of any new chips/designs/connectors/models in the last 10 years
3) I'm very worried about the bees. My theory is that the bees are going to go extinct, and that will be the butterfly that wipes us out. At the very least it seems highly probably we'll be in a state of total anarchy in a new dark age within the next fifty years thanks in part to unethical uses of technology.
>> As much as bee extinction is an actual concern that should be addressed with particular emphasis on preserving the species, your formulation and the scenario you are extrapolating are plain and simple displays of the delusional person that you are and a medical treatment should be followed through immediately.
4) The reality of a language as large as C++ is that each project will only use a small subset of the language and libraries, and the nature of object oriented programming leads to vastly different architectures for similar problems. If you can, I would learn Rust instead. Rust is a much smaller language that purposely limits the way you use the language to encourage particularly safe practices, and tends to favor designs that are hierarchical instead of allowing hairball object graphs. Rust also guides you at the compiler level in ways that C++ programmers must learn to do by heart, or simply leak memory and create nasty patterns in their code.
>> Adequate OO implementations rely on architectural and design patterns to solve similar problems efficiently when applicable >> I am not a Rust programmer and will not comment on anything related to it's features, nevertheless I can guarantee that only a mentally deficient individual would suggest a "purposely self-limiting language" for safety reasons and stating that C++ programmers "MUST LEARN BY HEART" how to write their code as there was not any sort of documentation available on earth.
5) So I don't know how to fly a commercial airliner, but I could probably figure my way around a small single prop airplane. That's basically the difference between...
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
* 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.
Also there are more resources here: https://doc.rust-lang.org/