Rust 1.88.0 released [LWN.net]

Version 1.88.0 of the Rust language has been released. Changes include the ability to chain let expressions, "naked" functions that have no compiler-generated prologue or epilogue, automatic garbage collection in cargo, a set of stabilized APIs, and more.

to post comments

automatic garbage collection in cargo

Posted Jun 27, 2025 8:25 UTC (Fri) by Nico57 (subscriber, #63763) [Link] (6 responses)

Finally! Garbage collection in Rust!

Automatic garbage collection in cargo

Posted Jun 27, 2025 10:10 UTC (Fri) by butlerm (subscriber, #13312) [Link] (3 responses)

Not sure, but it said automatic garbage collection in "cargo", not Rust. And if it were me I wouldn't want tracing garbage collection in Rust except as an option anyway, for the same reason almost no one uses that kind of thing in a kernel or other latency sensitive software.

Automatic garbage collection in cargo

Posted Jun 27, 2025 10:51 UTC (Fri) by fenncruz (subscriber, #81417) [Link] (2 responses)

The release notes explain it's garbage collecting old files in cargo's cache folder on the filesystem. So not a garbage collector for rust itself.

Automatic garbage collection in cargo

Posted Jun 27, 2025 10:58 UTC (Fri) by jem (subscriber, #24231) [Link] (1 responses)

https://en.wikipedia.org/wiki/Tongue-in-cheek

Automatic garbage collection in cargo

Posted Jun 27, 2025 19:28 UTC (Fri) by willy (subscriber, #9762) [Link]

https://en.wikipedia.org/wiki/Poe%27s_law

automatic garbage collection in cargo

Posted Jun 27, 2025 10:49 UTC (Fri) by danielthompson (subscriber, #97243) [Link] (1 responses)

Cargo's garbage collection is essentially automatic cache cleaning. In other words it reduces wasted space on the filesystem, it won't clean up any leaked allocations.

automatic garbage collection in cargo

Posted Jun 27, 2025 13:01 UTC (Fri) by tialaramex (subscriber, #21167) [Link]

In some ways this is exactly like its runtime brother. If my ImportStuff object makes a huge Doodad, which I was intending to use for the extremely clever O(log N) algorithm I read about, but then during development we write a simple O(N^2) function instead and it's fine with our workload, a garbage collected language won't go "Oh! You don't actually need this Doodad you made" and automatically reclaim it - instead the garbage collector will only reclaim the Doodad when finally the program is exiting and ImportantStuff goes away, taking its unused Doodad with it.

[In some cases an optimiser might notice we don't need the Doodad and so never even make it, but that's often out of reach of practical optimisers depending on exactly how this was arranged]

Likewise, cargo won't realise you added an entire Rust web framework in early development, then switched to writing a command line tool with no web server, so that web framework is going to be brought along for the ride until you finally say "Hey, we don't need this at all!" and remove it, or development ceases.

diff needed!

Posted Jun 27, 2025 14:00 UTC (Fri) by eharris (guest, #144549) [Link] (13 responses)

So......version 1.88.0. Good to know....
But what version was used for my Rust bible?
Programming Rust
By: Jim Blandy, Jason Orendorff, Leonora F. S. Tindall
Unfortunately neither the bible (nor the O'Reilly site) tells me this important fact.
Then there's my problem of the diff between the bible and the latest version.

diff needed!

Posted Jun 27, 2025 14:29 UTC (Fri) by jem (subscriber, #24231) [Link] (8 responses)

From the O'Reilly site: "This revised, updated edition covers the Rust 2021 Edition." Apparently the third edition is being worked on, with an expected release next year. This edition will cover the 2024 edition.

But is not knowing the exact difference really a problem? The book is not a reference manual, it is for learning Rust.

Speaking of Rust learning resources: I came across an (in my opinion) excellent new Rust book. It is called Rust for C Programmers by Dr. Stefan Salewski, and is available for free on the web at http://rust-for-c-programmers.com .

diff needed!

Posted Jun 27, 2025 15:20 UTC (Fri) by khim (subscriber, #9252) [Link] (7 responses)

> It is called Rust for C Programmers by Dr. Stefan Salewski, and is available for free on the web at http://rust-for-c-programmers.com .

Given the fact that it's written by AI (and not Rust expert) it would be interesting to know how many wrong and incorrect “facts” it includes.

At least S. Salewski doesn't try to hide the fact that it's not human-written text, that's a plus, I guess.

diff needed!

Posted Jun 27, 2025 16:54 UTC (Fri) by jem (subscriber, #24231) [Link] (6 responses)

The author states that he used AI mainly to check the English grammar of the text he had written. [1]

The book was created in the open before it was officially published, and you are free to look for errors yourself. Patches are welcome! [2]

[1] https://users.rust-lang.org/t/a-new-book-on-rust-i-am-wri...
[2] https://github.com/StefanSalewski/Rust_for_C-Programmers

diff needed!

Posted Jun 29, 2025 9:25 UTC (Sun) by bluss (guest, #47454) [Link] (5 responses)

This is how rust-for-c-programmers explains how they used AI: (It's in the original link, not on the forum)

> Initially, we considered listing every AI tool used, but such a list quickly became impractical. Today’s large language models (LLMs) possess substantial knowledge about Rust and can generate useful draft text, perform sophisticated grammar and style refinements, and answer specific technical questions. For the final editing phases of this book, we primarily utilized models such as OpenAI’s ChatGPT o1 and Google’s Gemini 2.5 Pro. These models proved particularly adept at creating concise paraphrases and improving clarity, sometimes suggesting removal of the author’s original text if it was deemed too verbose or tangential. Through interactive prompting via paid subscriptions to these services, we guided the AI towards maintaining a concise, neutral, and professional technical style throughout the final iterations, ensuring a coherent and consistent presentation across the entire book.

diff needed!

Posted Jul 11, 2025 22:30 UTC (Fri) by khim (subscriber, #9252) [Link] (4 responses)

The problem here is not that AI was used but by the fact that books was written by someone who doesn't know Rust well. Consider that piece (from the forum, this time):

Rusts box type depends not on T! A dependency would make no sense. But I agree, a slice is a fat pointer, containing the pointer to the data and the length. So I would assume that a box containing a slice would be a pointer to a fat pointer? At least in principle -- the compiler might optimize it?

This is very clearly book written by someone who have only very superfluous understanding of the subject that he is writing about and who is trying to fill the knowledge gap with AI. Said person may even believe that he knows subject well enough to write a book… but I would rather stick to writings of people who do know what they are writing about… or at least throughly reviewed by someone with such knowledge.

diff needed!

Posted Jul 11, 2025 22:54 UTC (Fri) by mb (subscriber, #50428) [Link] (3 responses)

so, do you want to explain what is wrong and what would be right?

diff needed!

Posted Jul 11, 2025 23:21 UTC (Fri) by khim (subscriber, #9252) [Link] (2 responses)

Are you asking about that quote or about the book? The misunderstanding about how box works was corrected on the forum:

Box<T> is a pointer with no metadata if T: Sized.

Box<T> is a pointer and some pointer-sized metadata if T is not Sized.

Example.

The size of the Box<T> type, and what it consists of, most definitely does depend on T.

Same with any other unsizing coercion supporting pointers.

And if you are asking about whether book have a mistake in the description of that part, then no, there are no problems either, it describes this particular thing correctly because this time ChatGPT and Gemini haven't decided to hallucinate something plausibly-sounding-yet-wrong into that particular piece of that book… and that's even worse IMNSHO: when “your” book describes something correctly and you, “the author”, on forums, describe things incorrectly… do you really want to trust such book?

P.S. And if you are asking about whether I read the book and caught some actual errors in it… nope, don't plan to do that. In my experience finding and fixing subtle errors in AI-generated text is very tedious and time-consuming work, much more tedious and time-consuming then doing the same for book written by humans without AI “help” (effect is similar to the well-known phenomenon of AI making people slower when they are thinking they are doing things faster), thus I'm definitely not wasting my time on that one…

diff needed!

Posted Jul 12, 2025 22:08 UTC (Sat) by Wol (subscriber, #4433) [Link] (1 responses)

> effect is similar to the well-known phenomenon of AI making people slower when they are thinking they are doing things faster

I notice they appear to be comparing AI to experienced Free/Open developers, who presumably have a much higher skill level than average. So it's quite possible that AI is better than your average programmer, but easily outclassed by the experienced guys they're using.

Like my experience where a user prototyped their tool with an AI, and I re-did it much better using our standards and my domain knowledge.

Cheers,
Wol

diff needed!

Posted Jul 12, 2025 22:25 UTC (Sat) by khim (subscriber, #9252) [Link]

> I notice they appear to be comparing AI to experienced Free/Open developers, who presumably have a much higher skill level than average.

That's entirely different aspect that everyone discusses… and it's, ultimately, not as disturbing: of course some things LLMs would do better, some things LLMs would do worse, that's not the problem.

This is the problem:

Developer's forecasts during study: 12-32% speedup.
Developer's estimates after study: 10-30% speedup.
Observed result: 19% slowdown.

The biggest issue is not difference between #1 and #2 or even difference between #1 and #3, but difference between #2 and #3!

It's the well-known fact that LLMs are a fraud machines. But it looks like this propensity of them to fool their users is extending to everything they touch: these developers were, all, firmly convinced that LLMs helped them in their tasks… while in reality it made them slower.

That is the worst thing here: it looks as if the whole thing is based on the ELIZA effect to a much larger degree than AI proponents try to make us believe.

> So it's quite possible that AI is better than your average programmer, but easily outclassed by the experienced guys they're using.

That's entirely different story. And tells us more about who we call “your average programmer” than about LLMs. Essentially LLMs are better than everyone (including you and me) on things outside of someone's area of expertise – but that's precisely why they couldn't be used to replace, basically, any worker: if someone does work outside of their area of expertise, doing things that they are not competent to do… then it's not the reason to try to help them with LLMs, but reason to hire someone who is more competent, instead!

diff needed!

Posted Jun 27, 2025 15:42 UTC (Fri) by tialaramex (subscriber, #21167) [Link]

The extremely good news is that you can write Rust, using everything you learned from your slightly out of date book and it'll work absolutely fine, even if you happen to install much newer Rust tooling such as Rust 1.88.0

The one small thing you want to do to ensure this behaves exactly as intended is, when you make a new Rust project add --edition 2021 to that command line, because your book is for 2021 Edition. This writes the line of text edition = "2021" to the new project's Cargo.toml which tells the tooling that this software was written for 2021 Edition, and so it must remains compatible with language from that era.

For example if you were learning from a 2015 book which names a function async that works fine in 2015 Edition, even on a brand new Rust compiler, and even though in your 2021 Edition of Rust, the word "async" is a keyword and the book example would not compile for that edition!

But to be honest even if you don't do that, most people will barely notice. Rust's changes mostly are taking a special case you maybe didn't realise was a special case and generalising it but in a sound way. So e.g. you learn if let in a book, and you've seen that you can chain "if" conditions such as "if happy && have_got(umbrella)" some people will wonder if they can chain if let, historically the answer was a disappointing "No" but in Rust 1.88 now the answer is now "Yes".

diff needed!

Posted Jun 27, 2025 15:42 UTC (Fri) by yodermk (guest, #3803) [Link]

I used that book to learn Rust; it is still excellent. It probably should be updated as there have been a lot of improvements since it was released, but even in its current state it remains useful.

diff needed!

Posted Jun 27, 2025 15:44 UTC (Fri) by job (guest, #670) [Link] (1 responses)

Any recommendations for a good Rust book that covers recent versions of the language?

diff needed!

Posted Jun 27, 2025 17:54 UTC (Fri) by tialaramex (subscriber, #21167) [Link]

I would expect that if your goal is to focus on very new things you'll have more luck with blog posts or (if you can learn this way) video or audio presentations.

If you just want to learn Rust, or even to go from "Somewhat competent" to "Confident non-expert" don't sweat it about the latest versions. Rust promises if it worked when it was written (not guaranteed but more likely in the modern era than when K&R was typeset) it should still work with your shiny new compiler, stdlib etc., modulo the caveat I wrote above about Editions and some edge cases about nasty bugs.

I found "the book" https://doc.rust-lang.org/stable/book/index.html (when I was reading it the 2018 edition was current) pretty good, but I'm definitely not the average Rust learner.