Rust 1.72.0

&gt; 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.<p>Is this &quot;period&quot; measured in statements or computer time?<p>&gt; 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.<p>So the default behaviour now is to nonetheless &quot;catch&quot; 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 &quot;catches&quot; 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?

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

I don&#x27;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.

&gt; &quot;Rust previously limited the maximum number of statements run as part of any given constant evaluation. However, <i>especially creative</i> Rust code could hit these limits and produce a compiler error&quot; [my emphasis]<p>Steve Klabnik one said he hoped Rust would be more like Ruby, and have some more <i>weird</i> projects. Maybe with this improvement, Rust can be more weird.

I like Rust. It adapts a lot of nice features that C++ is lacking.<p>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.<p>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.<p>However I <i>do</i> 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.<p>Switching to Rust won’t change that. I would still need those 9000+ tests to make sure my Rust deployment would be error free.<p>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.<p>There are of course languages more powerful than Rust that will allow you to write proven correct bug free code (Agda&#x2F;Idris&#x2F;Coq&#x2F;..) However those languages won’t prove that your code has the performance and latency needed in a real world environment for example.<p>So I would rather spend more time polishing and improving my auto test skills rather than investing in switching languages. My ROI will be <i>way</i> higher.<p>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++.<p>I would love to hear the thoughts of other experienced C++ developers who are responsible for very large C++ applications used by real customers.

Dying for async traits to someday come true

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&#x27;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&#x27;t be! :)<p>With that said, I can&#x27;t help but feel that Rust development has noticeably slowed down over the years. Don&#x27;t get me wrong, I appreciate the hard work behind each release! It&#x27;s just that, from my totally uninformed bystander perspective, there&#x27;s been a sharp drop in people working on the language and compiler full-time since around Mozilla layoffs, and Rust still hasn&#x27;t recovered from that. It&#x27;s surprising and quite disappointing to see no significant manpower commitment from other corporations using Rust, like Microsoft [2] and Google [3].<p>As a result, while there&#x27;s definitely new exciting things happening, more and more issues are piling up, many sitting unaddressed for years. Granted, it&#x27;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:<p>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.<p>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&#x27;s no finishing line in sight. Comparing const in Rust to constexpr in modern C++ will leave you disappointed.<p>There&#x27;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...<p>And yet I heartily recommend trying out Rust if you haven&#x27;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++.<p>[1] <a href="https:&#x2F;&#x2F;robert.kra.hn&#x2F;posts&#x2F;2022-09-09-speeding-up-incremental-rust-compilation-with-dylibs&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;robert.kra.hn&#x2F;posts&#x2F;2022-09-09-speeding-up-increment...</a> [2] <a href="https:&#x2F;&#x2F;blogs.windows.com&#x2F;windows-insider&#x2F;2023&#x2F;07&#x2F;12&#x2F;announcing-windows-11-insider-preview-build-25905&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;blogs.windows.com&#x2F;windows-insider&#x2F;2023&#x2F;07&#x2F;12&#x2F;announc...</a> [3] <a href="https:&#x2F;&#x2F;security.googleblog.com&#x2F;2021&#x2F;04&#x2F;rust-in-android-platform.html" rel="nofollow noreferrer">https:&#x2F;&#x2F;security.googleblog.com&#x2F;2021&#x2F;04&#x2F;rust-in-android-plat...</a> [4] <a href="https:&#x2F;&#x2F;github.com&#x2F;rust-lang&#x2F;rust&#x2F;issues&#x2F;53667">https:&#x2F;&#x2F;github.com&#x2F;rust-lang&#x2F;rust&#x2F;issues&#x2F;53667</a> [5] <a href="https:&#x2F;&#x2F;github.com&#x2F;rust-lang&#x2F;rust&#x2F;issues&#x2F;51114">https:&#x2F;&#x2F;github.com&#x2F;rust-lang&#x2F;rust&#x2F;issues&#x2F;51114</a> [6] <a href="https:&#x2F;&#x2F;github.com&#x2F;rust-lang&#x2F;rust&#x2F;issues&#x2F;67792">https:&#x2F;&#x2F;github.com&#x2F;rust-lang&#x2F;rust&#x2F;issues&#x2F;67792</a> [7] <a href="https:&#x2F;&#x2F;github.com&#x2F;rust-lang&#x2F;rust&#x2F;issues&#x2F;95174">https:&#x2F;&#x2F;github.com&#x2F;rust-lang&#x2F;rust&#x2F;issues&#x2F;95174</a> [8] <a href="https:&#x2F;&#x2F;github.com&#x2F;rust-lang&#x2F;rust&#x2F;issues&#x2F;57241">https:&#x2F;&#x2F;github.com&#x2F;rust-lang&#x2F;rust&#x2F;issues&#x2F;57241</a>

Is it expected that a programming language would have ~9,000 open issues?<p>~100 issues are either Critical&#x2F;High&#x2F;Prioritize<p><a href="https:&#x2F;&#x2F;github.com&#x2F;rust-lang&#x2F;rust&#x2F;issues">https:&#x2F;&#x2F;github.com&#x2F;rust-lang&#x2F;rust&#x2F;issues</a>

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

About String::leak:<p>&gt; The caller has free choice over the returned lifetime, including &#x27;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.<p>I can see the use case of the function and from reading the commit discussion, it seems it was based on Vec::&lt;u8&gt;::leak() but I&#x27;m not able to understand why either of the functions are safe instead of unsafe.