Rust 1.72.0
blog.rust-lang.org
blog.rust-lang.org
Is this "period" measured in statements or computer time?
> By default, the compiler will also emit a deny-by-default lint (const_eval_long_running) after a large number of steps to catch infinite loops, but you can allow(const_eval_long_running) to permit especially long const evaluation.
So the default behaviour now is to nonetheless "catch" infinite loops by default? Why not make the default behaviour to just notify a user by emitting a message after some time (as described)? If rustc "catches" infinite loops by default, how is backwards compatibility preserved with respect to `const` functions? If I split one statement into two in `const fn`, do I break BC?
It sounds like computer time is used now.
> So the default behaviour now is to nonetheless "catch" infinite loops by default? Why not make the default behaviour to just notify a user by emitting a message after some time (as described)?
Because lots of builds don't have a user. Having the user have to time out rustc because of this would be frustrating.
> If rustc "catches" infinite loops by default, how is backwards compatibility preserved with respect to `const` functions?
As long as the time is much larger than it takes to handle the old statement limit it is preserved.
> If I split one statement into two in `const fn`, do I break BC?
The old version might have prevented your code from compiling as mentioned in the notes.
The new version should in theory allow it if the unsplit version worked since it is based off compilation time.
Also there is an opt flag where it will go infinite
As a library developer, how can I know that?
> The old version might have prevented your code from compiling as mentioned in the notes.
Does it mean that rustc tracks function BC? I think I've misunderstood you.
In this case they modified the old hard error that you could opt out of into a deny by default lint.
Additionally if you opt out of the lint you get progress notifications of how much work has been done.
Looks like the whole thing is still statement based to avoid slow machines breaking on a timer.
Though to be honest this problem existed even before rust 1.72.0 and likely can't be solved while preventing infinite computations.
Just to be clear, this was the case before the new changes in 1.72. They already had that limit, and code could break in exactly that way. There were two problems with that beyond the simple backwards compatibility break. One is that there was no opt out, so if you broke you were kinda hosed at the library level. The second is that the limit was relatively low and so it was very possible to hit it.
Now if you end up running too long and the compiler fails, you’ve at least got an opt out, and the limit before failure is much higher.
Presumably for the sake of people who blindly upgrade an automated Rust build toolchain and wouldn't be aware that this would be signing them up for potentially-unbounded build times (and therefore potentially-unbounded CI/CD service fees.)
The Rust compiler error team keeps delivering feature to make the developer experience more pleasant. Thank you so much!
e,g, https://docs.rs/clap/latest/clap/macro.command.html
To enable
- Add a `cfg`: https://github.com/clap-rs/clap/blob/master/Cargo.toml#L48
- Enable the nightly feature when the `cfg` is present: https://github.com/clap-rs/clap/blob/master/src/lib.rs#L79
More likely it's that they have to keep running CI pipelines on those machines, and that's painful the older the OS gets.
I don't think they always emit code that looks the same, otherwise Windows wouldn't have that awesome compatibility mode in their binaries, where you could run a Win10 binary as if it's a WinXP one.
The MCP they're referring to goes into some detail about what's likely to happen. Older versions of Windows could still be community-supported if someone is willing to do so.
[0]: https://doc.rust-lang.org/nightly/rustc/platform-support.htm...
For all intents and purposes Rust is dropping support for anything below Windows 10.
It is suggested in the MCP that a new target can be created for older versions of Windows if members of the community will step up to support it.
If you put it into a tier of support that states "I won't be proactively maintaining compatibility and fixing issues here", then your answer is "nothing." A failing test won't spur you to action, because of the support level.
So if the test result doesn't change your behavior, why run the test in the first place?
The Rust test job is to compile every single public open-source package on the crates.io registry. This is an amazing way to test. But it's also expensive, because that actually takes a lot of machine time.
Windows is actually astonishingly backwards compatible but the older you want to support in Windows, the more jank your code has to be.
Like for example, in the zulip chat (linked in the issue for this change) they mention that the next versions they may drop are those Windows 10 releases prior to May 2019 as that release finally made UTF-8 the standard text encoding and being able to generally assume UTF-8 simplifies a lot of things for developers.
This is a bit of a reach unfortunately. UTF-16 (most often broken WTF-16) is still the standard text encoding on NT. The manifest change only makes A-suffixed functions always do a "UTF-8 to UTF-16" conversion, instead of the unhelpful "local codepage to UTF-16" conversion. Sure, that's better, but:
- Microsoft has expressed no interest in switching the actual underlying encoding to UTF-8, they will likely never do so in NT.
- A-suffixed functions only exist for some Win32 API. Newer Win32 functions are defined only taking Unicode strings. All COM, WinRT and native (Rtl/Nt) APIs use Unicode strings as well. The UTF-8 API surface is actually quite small - one might have to step out of the UTF-8 comfort zone in practice.
- Performance is being left on the table. Transcoding still has to be done, it would be more beneficial to at least keep it local for optimization purposes. The most trivial, yet still important use case: constant string conversions can't be optimized across DLL boundaries.
- Unlike, say, DPI awareness mode, there is no official API to change this behavior at runtime. It has to be done through the manifest, a compiler implicitly embedding such a manifest into every executable it produces is not ideal.
TL;DR: It's an improvement, but just barely, so bumping the minimum version just for this "feature" is not worth it IMO. Just bite the bullet and convert to UTF-16 if you have to, it's conceptually simpler and likely faster, too.
Unicode is not a binary encoding, perhaps you meant UTF-16/WTF-16, which are binary encoding of Unicode?
My post specifically mentions UTF-16 and WTF-16, too. The term "Unicode string" exists and is well established: https://unicode.org/glossary/#unicode_string.
Windows Unicode strings happen to fit this definition, but of course, so would UTF-8 strings. Either way, in Windows's version of reality the definition is narrowed to mean "potentially ill-formed UTF-16LE encoded string", but that doesn't exactly roll off the tongue, so for better or for worse, "Unicode string" is the consistently and widely used Windows-specific nomenclature.
The problem is that newer versions of Windows offer plenty of features which make library implementation simpler and/or give better performance. Someone else mentioned some threading/synchronization APIs, which is also the most common non-XP feature I've found in use in various C++ libraries.
Windows XP has been EOL for 9 year already[1], the vast majority of developer don't care about it. And if you happen to be a Rust developer who care about Windows XP you can either stick to an older version of the Rust compiler that still supports it. If you can afford to use a 22-years old OS that hasn't received patches for the past decade, you can probably afford to use an older Rust compiler…
[1]: https://learn.microsoft.com/en-us/lifecycle/products/windows...
And that's perfectly fine. Windows 8.1 is unsupported by Microsoft since early this year, and all older releases were already unsupported.
They are dropping tier 1 support for Win 7 and Win 8. That means they are no longer going to guarantee that the project builds on those platforms and passes all tests via CI.
As long as it is feasible they will probably keep CI runs for those platforms and if interested parties step up and provide sufficient maintenance support, it will remain tier 2. i.e a guarantee that it builds on those platforms via CI but not necessarily that all features are supported and guaranteed via passing tests.
If interested parties can provide sufficient maintenance that all tests continue passing, it will be tier 1 in all but name. However the rest of the development community won't waste their time with issues like Win 7 and 8's partial support for UTF-8.
And once CI stops being feasible for the compiler team to host, it'll drop down to tier 3. If there's sufficient interest from the community towards maintaining these targets, in practice you should see comparable support to with tiers 1 or 2 however now any CI will be managed externally by the community and the compiler team will stop worrying about changes that could break compilation on those targets.
TLDR: They aren't saying "it'll no longer work" but rather "if you want it to stay maintained for these targets, you have to pitch in dev hours to maintain it and eventually support the infrastructure to do this because we don't see a reason to continue doing this". So if you care for these targets, you'll have to contribute to keep it maintained.
[1]: https://github.com/rust-lang/compiler-team/issues/651
[2]: https://doc.rust-lang.org/rustc/target-tier-policy.html
The main effect is to split out Windows 7 and Windows 8 as their own targets, such that
> it also leaves open the door for new targets that can commit to broader support
And thus
> Individuals or organisation(s) who can commit to providing some level of legacy testing and support should go through the normal process for creating new targets.
Feel free to apply.
So, no, the executable code is not the same on XP or 11.
PS: Good job Microsoft, receive our acknowledgment. Say hello to the busy telemetry guys. /s
It's certainly bound to happen someday. Rust has a lower bound on official support for every OS, not just Windows. For example, Rust doesn't support compiling for Linux kernels older than 2012.
There also a couple of Win32 APIs used alongside the related frameworks.
Steve Klabnik one said he hoped Rust would be more like Ruby, and have some more weird projects. Maybe with this improvement, Rust can be more weird.
However it doesn’t solve any problems I have at work. I routinely deploy very large C++ applications to large international companies around the world.
And I haven’t had a memory or multi-threading problem causing any production issues for as long as I remember. I routinely use Valgrind and Helgrind to make sure it stays that way.
However I do have 9000+ auto tests that push the code way beyond any possible real life customer use cases. Enabling me to make major changes and optimizations to the code and drop it into production with confidence. I haven’t had a production bug for 5+ years.
Switching to Rust won’t change that. I would still need those 9000+ tests to make sure my Rust deployment would be error free.
So my point is this: No programming language will magically make your code bug free or eradicate the need for you to use sound software engineering practices like comprehensive auto tests.
There are of course languages more powerful than Rust that will allow you to write proven correct bug free code (Agda/Idris/Coq/..) However those languages won’t prove that your code has the performance and latency needed in a real world environment for example.
So I would rather spend more time polishing and improving my auto test skills rather than investing in switching languages. My ROI will be way higher.
If reading this makes you angry and eager to defend the honour of Rust and discredit what I am saying, please understand that I have nothing against Rust. This is more a summary of my current thinking on Rust and any other new programming language wanting to take over from C++.
I would love to hear the thoughts of other experienced C++ developers who are responsible for very large C++ applications used by real customers.
It's a feature I'm eagerly keeping tabs on as it have so many hacks in my active work that will [just work] once I can use async traits.
With that said, I can't help but feel that Rust development has noticeably slowed down over the years. Don't get me wrong, I appreciate the hard work behind each release! It's just that, from my totally uninformed bystander perspective, there's been a sharp drop in people working on the language and compiler full-time since around Mozilla layoffs, and Rust still hasn't recovered from that. It's surprising and quite disappointing to see no significant manpower commitment from other corporations using Rust, like Microsoft [2] and Google [3].
As a result, while there's definitely new exciting things happening, more and more issues are piling up, many sitting unaddressed for years. Granted, it's mostly the small things that you can live without, but they all add up. Here are some examples just off the top of my head:
1. If-let chains [4] and if-let guards [5], proposed back in 2018, are still not there. I constantly encounter cases where having them would make the code much shorter and clearer. I guess that depends on what you do, though. My code is heavy on state machines and pattern matching, otherwise this may be less of an issue.
2. Const generics are still very limited (no const trait impls [6], no enums as const generic parameters [7], no float arithmetic in const [8], etc.). I understand those are hard problems, but most are known for 3-5 years by now, and there's no finishing line in sight. Comparing const in Rust to constexpr in modern C++ will leave you disappointed.
There's definitely more problems that I hit less frequently, but each compiler error linking me to some stabilization issue with years-long discussion takes away a bit of joy...
And yet I heartily recommend trying out Rust if you haven't done so yet! Behind those papercuts hides a very practical and empowering language that gives you functional constructs at high performance and with much lower chance of shooting yourself in the foot as a newbie compared to C++.
[1] https://robert.kra.hn/posts/2022-09-09-speeding-up-increment... [2] https://blogs.windows.com/windows-insider/2023/07/12/announc... [3] https://security.googleblog.com/2021/04/rust-in-android-plat... [4] https://github.com/rust-lang/rust/issues/53667 [5] https://github.com/rust-lang/rust/issues/51114 [6] https://github.com/rust-lang/rust/issues/67792 [7] https://github.com/rust-lang/rust/issues/95174 [8] https://github.com/rust-lang/rust/issues/57241
They brought this on themselves being Leadership By Community rather than forming a working group to get a standard out. The reason C and C++ got incredibly popular was two fold:
1. There was really no other choice
2. They were rapidly adopted by a wide variety of people, competition led to standardization, and eventually convergence on a few good compilers. `mrustc` is basically the only alternative and it's only REAL use is for an alternative bootstrap story since Rust bootstrapping is still a problem.
The entire story for Rust is rather pathetic because it would appear at every turn they made the wrong choice despite having a lookback of over 50 years of compiler evolution. Which is sad, because Rust does bring a lot of very nice things.
Because the Rust team doesn't want this path (as in, they are not even entertaining the idea) you're left with a relatively small group of very brave volunteers trying to do their best to be The Standard (TM). The hope was that with adoption from Cloudflare/Amazon/Google/Facebook you'd see a similar standardization story. But it seems none of these groups are interested in the compiler itself and instead are just interested in promoting its use.
Stabilization will be a long term concern. The inclusion in the linux kernel is minimal at best, there are some limited use cases in Asahi, etc. The success of Rust is largely mythical rather than reality. The community at large is extremely vocal to the point of zealotry which also is likely driving people off of helping with the effort. There are a lot of very smart compiler developers in the C and C++ world that don't want anything to do with Rust strictly because of it's community.
Finally, it's also possible companies that may contribute more are being driven away by the politics of the core team. There was an unbelievable discussion on whether they should allow Palantir to continue to work with them because they Do Bad Things (TM). While I can respect their opinion on the subject I cannot respect the general lack of professionalism that you see from the team. While these things don't matter with small languages they do matter a lot with big ones. This lack of professionalism bleeds into every part of the language. It's time we stop talking about Rust like it's a toy language that can get away with being edgy and hip. If it wants to survive it needs to make drastic changes towards a model used by nearly every successful language for the last 50 years.
My conclusion is if Rust wants to succeed it needs to standardize, eject every member of the existing team, and aim for a more professional (e.g. not Mozilla's brand of politics) version of itself. Otherwise it's doomed to hobbytown for the rest of its days and C++ will continue to reign supreme.
Side note:
It's nice to see they dropped the politics for this set of release notes. Maybe they're learning.
Well, since it's community driven, this makes perfect sense. Freedom of association and all.
The current situation with the language is somewhat sad.
- Async traits: coming soon https://blog.rust-lang.org/inside-rust/2023/05/03/stabilizin..., actively in development (and has been for a while now, please don't confuse "this problem is hard and taking a long time" with "we don't care about this problem" https://github.com/rust-lang/rust/issues?q=is%3Aissue+label%...).
- async `Drop`: there have been multiple "false-starts", trying to come up with an acceptable design. We don't have a good answer for this at the moment. It is unknown to me how long it might take for us to figure it out.
- TAITs: same as async traits. It'll likely land after async fn in traits, but it's part of the same design and implementation effort.
- variadic generics (unlikely they will every be implemented): agree with your assessment, at least in the short to medium term.
- generic closures: same as above.
- optional/named parameters: I believe that this feature as such might never exist in rust but think that a combination of structural structs (`struct { bar: usize, baz: usize }`) and/or struct literal inference (`let x: S = _ { bar: 1, baz: 2 }`) and default const values in structs (`struct S { foo: usize = 42, bar: usize }`/`S { bar: 0, .. }`) would be more generally useful and would nicely cater to this use case (`foo(_ { bar: 42, .. }`).
- anonymous enums: I want this as well, but it interacts poorly with type parameters and automatic type upcasting (if you have `A | B` can you convert it into `A | B | C`? Does it need syntax? What about `Result<(), ()> | Option<()> | Result<i32, ()>`? If you have a function that returns that, what does `return Err(())` do?). Type downcasting could be done by forcing a match expression on the value. Whether `A | B` should `impl T` if `A: T, B: T` is an open question. I want to push for a solution here in the coming year.
I personally find these 4 letter acronyms difficult to lookup and understand. One of the T is probably "trait", but I always forget.
TAIT stands for `type Alias = impl Trait;`, which would let you do something like
type Alias = impl Display;
fn foo() -> Alias {
42
}
fn bar() -> Alias {
0
}
fn main() {
let x: Alias = if rand() > .5 {
foo()
} else {
bar()
};
}
There's also the related
- RPIT, "return position impl trait" (we already have this)
- RPITIT, "return position impl trait in traits" (the foundation for async unctions in traits, `trait T { fn foo() -> impl Trait; }`)
- AFIT, "async functions in traits"
No, you shouldn't need to know what these things mean, beyond them "just working" in terms of what you would expect from writing impl Trait in different places.
I can't speak for you, but I endorse Rust because I like the language as it exists, not as it might exist in the future, and it seems safe to assume that the other people endorsing it feel the same way, and that people who feel differently are not (and should not be) endorsing Rust. As far as my use cases are concerned, there's no language feature that Rust is missing or that would significantly improve my life (although I suppose inline const would be nice).
(And as far as tooling features go, the only thing that I want is sandboxed builds.)
Why shouldn't people fall in love with Rust and post about it? I fell in love with Rust before NLL even.
That's expected on any forum dedicated to <subject>. People tend to only specifically seek out communities around subjects they like, not dislike.
I also don't really see zealotry anymore. I see new projects being written in Rust left and right, and C++ developers bitching about it because they don't want to learn it or have been so scarred by moderately advanced language features implemented poorly they think Rust does it poorly too.
99% of all programmers just want their chosen tool to succeed.
Consider that you might have been influenced by rage-baiting trolls. That's understandable and it happened to all of us at one point.
Don't judge a community by the 0.1% bad apples. Every community has them.
This. This is what I find baffling that somebody can believe in. Every community has the 0.1% of insufferable zealots and Rust is no exception.
I worked with absolutely brilliant Rust programmers that made me question if I know anything at all about programming in general -- and I have 21.5 years of experience.
I keep seeing your sentiment expressed in a number of Rust threads which becomes more and more confusing with time because I scarcely see anyone at all advocate zealously for Rust but I am seeing plenty of people like you who keep insisting that Rust fans are torturing them. :D
It gets funny at one point.
I mean, try to be more data-driven. Scan the last 5 big Rust threads and just try to do basic sentiment analysis. I have, and I am mostly seeing very balanced and curious debates. I haven't noticed any zealotry. Last time I noticed people being as annoying was I think somewhere back in 2018.
you have been tricked into being mad at something that literally doesn't matter.
What about your language? And his?
"Bitching", "baffling", "rage-baiting trolls", "completely wrong", "literally doesn't matter".
My language: "in my experience", "more often than not", "I'd like to be wrong and happened to have came across mostly bad apples."
So, I'm not the one who is "mad" and "bitching" here. You are the one mad at me.
Who is being tricked? Sounds like you are tricking yourself.
First of all, the idea that the C++ standards process is some pinnacle of productivity and velocity is endlessly funny to me. Maybe by the time C++26 comes out, all of the features in C++23 might be considered "usable" with more than one compiler. That's saying nothing of the purgatory that certain features have been in for years.
Second, who implements the standards? Google pulled back most of their resources from Clang. Most development on C/C++ compilers is currently done by companies like Microsoft and Red Hat and Intel that have a lot of paying customers relying on those ecosystems. That's a function of time and penetration, not whether there's a "committee" involved.
Third, politics exist in C++ as well. People snipe at each other in public and on private mailing lists and conferences. They are not immune from "unprofessionalism".
The whole line of argument is just absurd. Look at Go or Python or Ruby - none of them are ruled by a standards committee, and all of them are very popular and see plenty of development. And frankly I don't think Rust actually develops slower than C++ does. Rust delivers features every 6 weeks rather than every 3 years, so it can be hard to tell just how much progress has actually been made even when it is actually quite a lot.
politics
As someone who's not a compiler guru, I've found contributing to rust (whether rustc or third party crates) to be generally frictionless and overall a pleasant process. It's great to not have to deal with the drama surrounding so many other projects (EGCS anyone?). Quite frankly I'm glad there's no need to hold your nose and put up with RMS' antics.
eject every member of the existing team
Rust bootstrapping is still a problem
In terms of number of commits to the rust-lang/rust repo, activity peaked in late 2019/early 2020, whereas the Mozilla layoffs took place in late 2020. Activity since late 2020 has mostly stayed stable, and remains well above where it was at any point prior to 2018: https://github.com/rust-lang/rust/graphs/contributors
In addition, I know of several former Mozillians who remain employed to work on Rust, including one who heads the Rust team at Amazon.
As far as the number of contributors to each release, it's currently hovering around an all-time average high (although a handful of past releases have anomalously high peaks): https://thanks.rust-lang.org/
The reason that progress appears slower these days is because the low-hanging feature fruit has mostly been plucked, and what's left are the harder problems. Maintenance tasks don't make for very interesting release notes. In addition, as the language matures much of the interesting feature work has shifted from the compiler/stdlib to tooling like Cargo, rust-analyzer, etc. (whose activity might not be reflected in the above graphs).
~100 issues are either Critical/High/Prioritize
There are few good things in life unlimited. One can add above in that list now.
> The caller has free choice over the returned lifetime, including 'static. Indeed, this function is ideally used for data that lives for the remainder of the program’s life, as dropping the returned reference will cause a memory leak.
I can see the use case of the function and from reading the commit discussion, it seems it was based on Vec::<u8>::leak() but I'm not able to understand why either of the functions are safe instead of unsafe.
https://doc.rust-lang.org/book/ch15-06-reference-cycles.html
It composes (if A doesn't leak and B doesn't leak, then a combination AB also does not leak) which is a property safety also has, but I don't see another connection.