8 ms·

Rust 1.72.0

234 points by thatxliner 3y ago

vbezhenar 3y ago
I don't understand why compilers drop old Windows compatibility. It makes no sense to me. They emit executable code which looks the same on Windows XP or on Windows 11.
- dijit 3y ago
  Likely it's not a statement about true compatibility. More likely it's that they have to keep running CI pipelines on those machines, and that's painful the older the OS gets.
- deleted 3y ago
  [deleted]
- nevi-me 3y ago
  Saying you're compatible with a target means that you're testing new changes against that target so it doesn't break. 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.
  - lionkor 3y ago
    Call it partial support then
    - nevi-me 3y ago
      Well, they're talking about "officially support", which sounds like it's sufficient. 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.
    - binary132 3y ago
      I think support implies a lot that I guess they don’t want to imply.
- pie_flavor 3y ago
  Rust platform support is tiered[0]. Tier 1 targets are automatically tested, tier 2 targets are automatically built, and tier 3 targets are best-effort. Windows 7 is tier 1 and Windows XP is tier 3; what they're going to do is change the tier 1 Windows build to 10, but the Windows XP support isn't going anywhere. [0]: https://doc.rust-lang.org/nightly/rustc/platform-support.html https://doc.rust-lang.org/nightly/rustc/platform-support.htm...
  - vbezhenar 3y ago
    That makes much more sense and wasn't really obvious from the announcement, thanks!
  - veber-alex 3y ago
    The tier 3 Windows XP target is no_std only, which makes it useless for the vast majority of developers. 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. https://github.com/rust-lang/compiler-team/issues/651 https://github.com/rust-lang/compiler-team/issues/651
    - queuebert 3y ago
      The question is why do newer versions of Windows break compatibility so badly?
      - jeremy_wiebe 3y ago
        It seems like the Rust team isn't saying that compatibility is broken, just that there is no testing or effort to ensure compatibility. In the end it's similar, but like any project, it comes down to allocation of time and resources. For something like Windows XP, I'd guess the pool of folks interested in targeting it is extremely small.
      - lambda_garden 3y ago
        But why not test? If we don't expect compatibility to break, then it will be little extra effort surely?
- jenadine 3y ago
  Rust also has a standard library. They may want to use new API for threads, file system access, and other things provided by the std.
- aseipp 3y ago
  Because those people can just keep using older versions of the compiler if they need binaries to run on those platforms (easier than ever with tools like rustup), and because actually maintaining things like build farms and testing a platform takes a lot of work.
- CuriousCosmic 3y ago
  I'd recommend reading the MCP[1] they linked regarding the decision as well as their target tier policy [2]. 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 https://github.com/rust-lang/compiler-team/issues/651 [2]: https://doc.rust-lang.org/rustc/target-tier-policy.html https://doc.rust-lang.org/rustc/target-tier-policy.html
  - gilcot 3y ago
    Thanks for that clarification. Wasn't obvious for everybody at first read.
- richardwhiuk 3y ago
  Tier 1 Rust Targets run all CI tests, and block tools - so it's about CI infrastructure and maintenance of that I think
- flohofwoe 3y ago
  I bet that's mainly for stdlib features.
- masklinn 3y ago
  > Currently Windows 7 and 8 are listed as Tier 1 supported platforms. However, this has not been true for a long long time. We simply do not have the testing infrastructure. And with so much software now abandoning Windows 7 and 8 (everything from Git to Go to every major browser), continuing to provide the little support that we do is only getting more difficult. There is also a lack of vendor support for these targets. 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.
- jcranmer 3y ago
  Because newer versions of kernels add new userspace APIs that can be hard to work around if it's not present. For example, Linux 3.7 added getrandom, which is a much easier way to get CSPRNG data from the kernel than /dev/urandom. With regards to Windows, I believe Windows 7 added some multithreading helpers that make mutex support much more performant compared to what you would have to do on XP or Vista. So, no, the executable code is not the same on XP or 11.
- drtgh 3y ago
  It will be interesting in the future to read the "oh, Windows 10 is no longer tier-1 !!" when the bell arrives at their windows. PS: Good job Microsoft, receive our acknowledgment. Say hello to the busy telemetry guys. /s
  - kibwen 3y ago
    > It will be interesting in the future to read the "oh, Windows 10 is no longer tier-1 !!" when the bell arrives at their windows. 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.
- codelikeawolf 3y ago
  I've worked pretty extensively with the Win32 API and Go. I needed to target Windows XP and had to use an older version of Go for stuff like reading/writing files, networking, etc. From what I could gather, newer versions of the Win32 API add abstractions that make common operations require less API calls. I remember needing to use 9 separate Win32 API calls just to bring a window to the foreground and set focus to it. So I think part of the reason Go drops support for older versions of Windows is they were able to simplify code on _their_ end by leveraging these new abstractions. I imagine Rust might be doing the same thing? This is all pure speculation and my memory is fuzzy on this, so take this with a grain of salt.
- pjmlp 3y ago
  No they don't, Visual C++ and .NET JIT take advantage of CPU instructions as per minimal supported CPU. There also a couple of Win32 APIs used alongside the related frameworks.
geodel 3y ago
> Const evaluation time is now unlimited There are few good things in life unlimited. One can add above in that list now.
littlestymaar 3y ago
> Rust reports potentially useful cfg-disabled items in errors The Rust compiler error team keeps delivering feature to make the developer experience more pleasant. Thank you so much!
- PoignardAzur 3y ago
  Yeah, I can think of a few times this would have been super helpful. Great feature!
- junon 3y ago
  The error messages were the first thing that really impressed me, and not only have they improved a lot over the years but clippy is a thing to add even more guidance to writing better code. Really impressive stuff.
- davidhyde 3y ago
  This is huge for embedded rust where cargo Features are used heavily. One of those trial and error things that can be frustrating when learning a new library with missing notes about features.
  - epage 3y ago
    They should enable the nightly-only "auto cfg" feature to also help out e,g, https://docs.rs/clap/latest/clap/macro.command.html 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 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 https://github.com/clap-rs/clap/blob/master/src/lib.rs#L79
rhodysurf 3y ago
Dying for async traits to someday come true
- kibwen 3y ago
  AFAIK it's just waiting on the fix in https://github.com/rust-lang/rust/pull/114489 https://github.com/rust-lang/rust/pull/114489 to land, I don't know of any other blockers.
- Fordec 3y ago
  Coming in 1.74 apparently but it seems to be behind schedule by what the plan was in the Gantt chart. 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.
  - bobbylarrybobby 3y ago
    Serious question: is the crate that fakes it with box dyn future really not performant enough for you?
    - Fordec 3y ago
      Not ergonomic for use by providing a public trait API in a library when step one is [also] import this other hack library to get up and running.
timlatim 3y ago
I love using Rust in my toy projects (and wish my job was more open to anything but C++, but oh well). With its functional-style iterators, sum types and pattern matching, Rust lets me write code in a way that just feels natural. And the borrow checker stopped bothering me once I embraced reference-counted pointers for those cases where lifetimes are not obvious. Compilation time also hasn't been much of an issue once I moved to using dylibs for dependencies [1]. So if you want to use Rust but are wary of those problems, don't be! :) 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-incremental-rust-compilation-with-dylibs/ https://robert.kra.hn/posts/2022-09-09-speeding-up-increment... [2] https://blogs.windows.com/windows-insider/2023/07/12/announcing-windows-11-insider-preview-build-25905/ https://blogs.windows.com/windows-insider/2023/07/12/announc... [3] https://security.googleblog.com/2021/04/rust-in-android-platform.html https://security.googleblog.com/2021/04/rust-in-android-plat... [4] https://github.com/rust-lang/rust/issues/53667 https://github.com/rust-lang/rust/issues/53667 [5] https://github.com/rust-lang/rust/issues/51114 https://github.com/rust-lang/rust/issues/51114 [6] https://github.com/rust-lang/rust/issues/67792 https://github.com/rust-lang/rust/issues/67792 [7] https://github.com/rust-lang/rust/issues/95174 https://github.com/rust-lang/rust/issues/95174 [8] https://github.com/rust-lang/rust/issues/57241 https://github.com/rust-lang/rust/issues/57241
Hirrolot 3y ago
> To avoid having long compilations without feedback, the compiler will always emit a message after your compile-time code has been running for a while, and repeat that message after a period that doubles each time. 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?
- Guvante 3y ago
  > Is this "period" measured in statements or computer time? 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
  - Hirrolot 3y ago
    > As long as the time is much larger than it takes to handle the old statement limit it is preserved. 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.
zengid 3y ago
> "Rust previously limited the maximum number of statements run as part of any given constant evaluation. However, especially creative Rust code could hit these limits and produce a compiler error" [my emphasis] 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.
nabeelms 3y ago
About String::leak: > 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.
- jack1243star 3y ago
  Rust's memory safety model does not prohibit memory leak. https://doc.rust-lang.org/book/ch15-06-reference-cycles.html https://doc.rust-lang.org/book/ch15-06-reference-cycles.html
  - tialaramex 3y ago
    Bjarne Stroustrup is emphatic that prohibiting all leaks must be part of safety, but I have no idea what the logical justification is to distinguish say Box::leak, which this prohibits, from the moral equivalent of freeing resources only on exit, which is fine under such a rule. 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.
- masklinn 3y ago
  > I'm not able to understand why either of the functions are safe instead of unsafe. https://cglab.ca/%7Eabeinges/blah/everyone-poops/ https://cglab.ca/%7Eabeinges/blah/everyone-poops/
deterministic 3y ago
I like Rust. It adapts a lot of nice features that C++ is lacking. 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.
alberth 3y ago
Is it expected that a programming language would have ~9,000 open issues? ~100 issues are either Critical/High/Prioritize https://github.com/rust-lang/rust/issues https://github.com/rust-lang/rust/issues

234 points by thatxliner 3y ago

I don't understand why compilers drop old Windows compatibility. It makes no sense to me. They emit executable code which looks the same on Windows XP or on Windows 11.

dijit 3y ago
Likely it's not a statement about true compatibility. More likely it's that they have to keep running CI pipelines on those machines, and that's painful the older the OS gets.
deleted 3y ago
[deleted]
nevi-me 3y ago
Saying you're compatible with a target means that you're testing new changes against that target so it doesn't break. 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.
- lionkor 3y ago
  Call it partial support then
  - nevi-me 3y ago
    Well, they're talking about "officially support", which sounds like it's sufficient. 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.
  - binary132 3y ago
    I think support implies a lot that I guess they don’t want to imply.
pie_flavor 3y ago
Rust platform support is tiered[0]. Tier 1 targets are automatically tested, tier 2 targets are automatically built, and tier 3 targets are best-effort. Windows 7 is tier 1 and Windows XP is tier 3; what they're going to do is change the tier 1 Windows build to 10, but the Windows XP support isn't going anywhere. [0]: https://doc.rust-lang.org/nightly/rustc/platform-support.html https://doc.rust-lang.org/nightly/rustc/platform-support.htm...
- vbezhenar 3y ago
  That makes much more sense and wasn't really obvious from the announcement, thanks!
- veber-alex 3y ago
  The tier 3 Windows XP target is no_std only, which makes it useless for the vast majority of developers. 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. https://github.com/rust-lang/compiler-team/issues/651 https://github.com/rust-lang/compiler-team/issues/651
  - queuebert 3y ago
    The question is why do newer versions of Windows break compatibility so badly?
    - jeremy_wiebe 3y ago
      It seems like the Rust team isn't saying that compatibility is broken, just that there is no testing or effort to ensure compatibility. In the end it's similar, but like any project, it comes down to allocation of time and resources. For something like Windows XP, I'd guess the pool of folks interested in targeting it is extremely small.
    - lambda_garden 3y ago
      But why not test? If we don't expect compatibility to break, then it will be little extra effort surely?
jenadine 3y ago
Rust also has a standard library. They may want to use new API for threads, file system access, and other things provided by the std.
aseipp 3y ago
Because those people can just keep using older versions of the compiler if they need binaries to run on those platforms (easier than ever with tools like rustup), and because actually maintaining things like build farms and testing a platform takes a lot of work.
CuriousCosmic 3y ago
I'd recommend reading the MCP[1] they linked regarding the decision as well as their target tier policy [2]. 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 https://github.com/rust-lang/compiler-team/issues/651 [2]: https://doc.rust-lang.org/rustc/target-tier-policy.html https://doc.rust-lang.org/rustc/target-tier-policy.html
- gilcot 3y ago
  Thanks for that clarification. Wasn't obvious for everybody at first read.
richardwhiuk 3y ago
Tier 1 Rust Targets run all CI tests, and block tools - so it's about CI infrastructure and maintenance of that I think
flohofwoe 3y ago
I bet that's mainly for stdlib features.
masklinn 3y ago
> Currently Windows 7 and 8 are listed as Tier 1 supported platforms. However, this has not been true for a long long time. We simply do not have the testing infrastructure. And with so much software now abandoning Windows 7 and 8 (everything from Git to Go to every major browser), continuing to provide the little support that we do is only getting more difficult. There is also a lack of vendor support for these targets. 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.
jcranmer 3y ago
Because newer versions of kernels add new userspace APIs that can be hard to work around if it's not present. For example, Linux 3.7 added getrandom, which is a much easier way to get CSPRNG data from the kernel than /dev/urandom. With regards to Windows, I believe Windows 7 added some multithreading helpers that make mutex support much more performant compared to what you would have to do on XP or Vista. So, no, the executable code is not the same on XP or 11.
drtgh 3y ago
It will be interesting in the future to read the "oh, Windows 10 is no longer tier-1 !!" when the bell arrives at their windows. PS: Good job Microsoft, receive our acknowledgment. Say hello to the busy telemetry guys. /s
- kibwen 3y ago
  > It will be interesting in the future to read the "oh, Windows 10 is no longer tier-1 !!" when the bell arrives at their windows. 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.
codelikeawolf 3y ago
I've worked pretty extensively with the Win32 API and Go. I needed to target Windows XP and had to use an older version of Go for stuff like reading/writing files, networking, etc. From what I could gather, newer versions of the Win32 API add abstractions that make common operations require less API calls. I remember needing to use 9 separate Win32 API calls just to bring a window to the foreground and set focus to it. So I think part of the reason Go drops support for older versions of Windows is they were able to simplify code on _their_ end by leveraging these new abstractions. I imagine Rust might be doing the same thing? This is all pure speculation and my memory is fuzzy on this, so take this with a grain of salt.
pjmlp 3y ago
No they don't, Visual C++ and .NET JIT take advantage of CPU instructions as per minimal supported CPU. There also a couple of Win32 APIs used alongside the related frameworks.

geodel 3y ago

> Const evaluation time is now unlimited There are few good things in life unlimited. One can add above in that list now.

littlestymaar 3y ago

> Rust reports potentially useful cfg-disabled items in errors The Rust compiler error team keeps delivering feature to make the developer experience more pleasant. Thank you so much!

PoignardAzur 3y ago
Yeah, I can think of a few times this would have been super helpful. Great feature!
junon 3y ago
The error messages were the first thing that really impressed me, and not only have they improved a lot over the years but clippy is a thing to add even more guidance to writing better code. Really impressive stuff.
davidhyde 3y ago
This is huge for embedded rust where cargo Features are used heavily. One of those trial and error things that can be frustrating when learning a new library with missing notes about features.
- epage 3y ago
  They should enable the nightly-only "auto cfg" feature to also help out e,g, https://docs.rs/clap/latest/clap/macro.command.html 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 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 https://github.com/clap-rs/clap/blob/master/src/lib.rs#L79

rhodysurf 3y ago

Dying for async traits to someday come true

kibwen 3y ago
AFAIK it's just waiting on the fix in https://github.com/rust-lang/rust/pull/114489 https://github.com/rust-lang/rust/pull/114489 to land, I don't know of any other blockers.
Fordec 3y ago
Coming in 1.74 apparently but it seems to be behind schedule by what the plan was in the Gantt chart. 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.
- bobbylarrybobby 3y ago
  Serious question: is the crate that fakes it with box dyn future really not performant enough for you?
  - Fordec 3y ago
    Not ergonomic for use by providing a public trait API in a library when step one is [also] import this other hack library to get up and running.

timlatim 3y ago

I love using Rust in my toy projects (and wish my job was more open to anything but C++, but oh well). With its functional-style iterators, sum types and pattern matching, Rust lets me write code in a way that just feels natural. And the borrow checker stopped bothering me once I embraced reference-counted pointers for those cases where lifetimes are not obvious. Compilation time also hasn't been much of an issue once I moved to using dylibs for dependencies [1]. So if you want to use Rust but are wary of those problems, don't be! :) 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-incremental-rust-compilation-with-dylibs/ https://robert.kra.hn/posts/2022-09-09-speeding-up-increment... [2] https://blogs.windows.com/windows-insider/2023/07/12/announcing-windows-11-insider-preview-build-25905/ https://blogs.windows.com/windows-insider/2023/07/12/announc... [3] https://security.googleblog.com/2021/04/rust-in-android-platform.html https://security.googleblog.com/2021/04/rust-in-android-plat... [4] https://github.com/rust-lang/rust/issues/53667 https://github.com/rust-lang/rust/issues/53667 [5] https://github.com/rust-lang/rust/issues/51114 https://github.com/rust-lang/rust/issues/51114 [6] https://github.com/rust-lang/rust/issues/67792 https://github.com/rust-lang/rust/issues/67792 [7] https://github.com/rust-lang/rust/issues/95174 https://github.com/rust-lang/rust/issues/95174 [8] https://github.com/rust-lang/rust/issues/57241 https://github.com/rust-lang/rust/issues/57241

Hirrolot 3y ago

> To avoid having long compilations without feedback, the compiler will always emit a message after your compile-time code has been running for a while, and repeat that message after a period that doubles each time. 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?

Guvante 3y ago
> Is this "period" measured in statements or computer time? 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
- Hirrolot 3y ago
  > As long as the time is much larger than it takes to handle the old statement limit it is preserved. 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.

zengid 3y ago

> "Rust previously limited the maximum number of statements run as part of any given constant evaluation. However, especially creative Rust code could hit these limits and produce a compiler error" [my emphasis] 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.

nabeelms 3y ago

About String::leak: > 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.

jack1243star 3y ago
Rust's memory safety model does not prohibit memory leak. https://doc.rust-lang.org/book/ch15-06-reference-cycles.html https://doc.rust-lang.org/book/ch15-06-reference-cycles.html
- tialaramex 3y ago
  Bjarne Stroustrup is emphatic that prohibiting all leaks must be part of safety, but I have no idea what the logical justification is to distinguish say Box::leak, which this prohibits, from the moral equivalent of freeing resources only on exit, which is fine under such a rule. 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.
masklinn 3y ago
> I'm not able to understand why either of the functions are safe instead of unsafe. https://cglab.ca/%7Eabeinges/blah/everyone-poops/ https://cglab.ca/%7Eabeinges/blah/everyone-poops/

deterministic 3y ago

I like Rust. It adapts a lot of nice features that C++ is lacking. 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.

alberth 3y ago

Is it expected that a programming language would have ~9,000 open issues? ~100 issues are either Critical/High/Prioritize https://github.com/rust-lang/rust/issues https://github.com/rust-lang/rust/issues