Rendered at 03:07:30 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
nirinor 9 hours ago [-]
Woohoo, that's a release! My personal favorites:
- Stabilize never type
- Stabilize custom allocators
- Introduced minimum publish age configurations, also known as dependency cooldowns. When the relevant config is set, the resolver ignores versions published more recently than that, unless they are already in Cargo.lock. (RFC 3923) docs #17335
- cargo-install: now uses the existing lockfile in the .crate tarball by default. --locked in cargo install becomes a no-op. #17388
nixpulvis 6 hours ago [-]
> cargo-install: now uses the existing lockfile in the .crate tarball by default. --locked in cargo install becomes a no-op. #17388
Long time follower of this. Very grateful it's been implemented.
That was one of the biggest gotchas with Rust. It’s unfortunate that it took so long to change this very unintuitive and potentially dangerous behavior.
SOLAR_FIELDS 2 hours ago [-]
Dependency cooldowns receiving such a whiplash this year. Earlier everyone was advocating for them because of the supply chain attacks. Now, people are worried because you might miss 0 days if you use them.
Nonetheless, the ability to set and configure it is a welcome feature.
woodruffw 23 minutes ago [-]
You should do both: you should let normal updates cool down, and you should immediately patch security advisories.
One of the biggest ergonomic problems with cooldowns is that many tools let the former goal obstruct the latter. Both should be part of the state machine of resolution itself, rather than things that get layered on.
saghm 38 minutes ago [-]
Some of us were saying they didn't understand the endgame of everyone using cooldowns at the time. We mostly got told we were wrong though.
n_u 8 hours ago [-]
> Cargo now reports unused dependencies to users, e.g.
> warning: unused dependency `tracing-subscriber`
--> Cargo.toml:23:1
|
23 | tracing-subscriber.workspace = true
| ^^^^^^^^^^^^^^^^^^
|
= note: `cargo::unused_dependencies` is set to `warn` by default
help: consider removing the dependency on `tracing-subscriber`
Heck yes
jtwaleson 6 hours ago [-]
Does this remove the need for machete or shear?
epage 6 hours ago [-]
I believe so. The maintaner of cargo-udeps did most of the work as an effort to upstream it.
The main limitation is in dev-dep detection since there isn't a way to exhaustively run everything that uses dev-deps yet. You can look at logging statements to get an approximation though.
minimaxir 7 hours ago [-]
I updated to 1.100 during a Claude session and it complained about new warnings, so I told it to fix them. It removed a large number of unused dependencies without issue.
saghm 34 minutes ago [-]
My semi-controversial take is that the best way to use agents for Rust is to literally turn every possible lint and warning on in clippy and require that they're treated as blocking for the agent to fix before ever saying things are done. While a few of them might be overzealous and feel tedious to work around manually, there's no need to care about it being tedious for an agent!
minimaxir 46 minutes ago [-]
I am legitimately confused why my parent comment is being mass downvoted: the point I was making is that this is change is more a perk for agent use with Rust since agents typically will resolve warnings by solving the issue (and therefore proactively remove redundant dependencies)
yuriks 18 minutes ago [-]
fwiw my immediate reaction (I didn't downvote) to your comment was "no one asked".
minimaxir 13 minutes ago [-]
My intent was to share a fun anecdote of an practical, unexpected impact of the change but I now see that agents + fun is still a tough sell on HN.
ammar_az 8 hours ago [-]
This release is so big that multiple useful stabilized API aren't event mentioned in the blog post like:
For someone who has decades of experience from other programming languages this does not look clear to me at all but rather confusing. Calling an method can change value of variable of primitive type?
ninkendo 4 hours ago [-]
There’s nothing special about primitives, they’re just types like any other. A method taking `&mut self` can always modify self, on any type. But you can only call such methods if the value is mutable to begin with, so it’s not really that interesting.
It’s only weird if you come from languages like Java where “primitives” are distinct from “objects”, which is a self-imposed limitation the language imposes.
Groxx 4 hours ago [-]
Or Go (also treats primitives rather specially) or roughly any language without extension methods (because primitives are at a minimum a pre-defined type). Which is quite a lot of languages really.
Otherwise agreed, methods like this can be mutable in any language that doesn't heavily specialize primitives.
saghm 27 minutes ago [-]
Not quite; the method uses `&mut self`, so it actually operates on a mutable reference to the value that happens to be a primitive. If you declare a boolean without specifying the binding as mutable, you'd get a compiler error from trying to call this method. Moreover, if anything else had a reference to it at the same time, it would also cause a compiler error to call this method.
This is definitely something that Rust does a bit different than most other languages, but it's not anything specific to this method, booleans, or particularly new to the language. Most people will learn about the common different ways of defining a method (via ownership, shared reference, or mutable reference) fairly early on in programming Rust.
zdimension 4 hours ago [-]
When you call a method on something in Rust, the method gets passed that something (as a parameter called self). But the method gets to choose whether it's by move/copy or by reference. Here, toggle gets the bool passed by mutable reference.
In effect, if x is a bool, doing x.toggle() is rewritten by the compiler as bool::toggle(&mut x), which can of course modify x.
jason_oster 1 hours ago [-]
Think of having the method for AtomicBool, where you are forced to call methods for all value accesses. `atomic_bool.toggle(Ordering::SeqCst)` would read much better than `atomic_bool.fetch_xor(true, Ordering::SeqCst)`.
stusmall 3 hours ago [-]
The big clue that'll jump out to any rust dev is the type signature:
pub const fn toggle(&mut self)
The "&mut" says that toggle takes a mutable reference to the instance it is called off of. This is also called a mutable borrow. You might think that would get buried in the program because you don't always check the type signature of every method you call, but there are a few reasons that muts really jump out in rust. The languages immutable by default nature is one and the other is that several IDE have features to specifically draw attention to mutable instances/references. It's a fairly common pattern in rust to have helper methods on a type that take a mutable reference or ownership of self.
TL;DR: Rust's ownership model is very unique. Once it clicks its the cat's pajamas, but experience in other languages don't map well to this part of the language.
rtpg 2 hours ago [-]
C++ lets you do this kind of stuff as well.
Primitive types and composite types having the same capabilities is a bit of a value statement for C++ and Rust IMO, and it's missing in a lot of languages downstream (IMO) of the "every variable is a reference to a slot/pointer" philosophy taken by most every managed language
tialaramex 1 hours ago [-]
C++ doesn't have methods/ "member functions" on the primitive types.
One reason is that C++ doesn't know where to put them, for user defined class, struct or union types these "member functions" as their name suggests live inside the class/ struct/ union definition but for a primitive where would these live?
In Rust they're just impl blocks, for example the method we're discussing here is:
What may be surprising to you coming from other languages, is that primitive types in Rust have their own methods! So methods applying to primitives is not unusual at all in Rust.
crabmusket 2 hours ago [-]
I guess you're experiencing the feeling a mathematician gets when seeing a line like
x = x + 1
scott_w 4 hours ago [-]
Why wouldn’t it be possible? The distinction in modern languages between primitive and not is an arbitrary one when it comes to stuff like this.
throwaway2037 3 hours ago [-]
> decades of experience from other programming languages
What languages?
adastra22 1 hours ago [-]
Most (not all) static & ahead-of-time compiled languages. C++ and Java come to mind. Method calls on built-in primitive types is more of a dynamic language thing (think: ruby, python) that got extended into compiled languages in recent memory.
worik 2 hours ago [-]
> Calling an method can change value of variable of primitive type?
So long as the variable is mutable it's value can be changed
kibwen 2 hours ago [-]
In addition to what the sibling commenters have written, in order for this to compile, the variable would need to be declared as mutable.
dxxvi 3 hours ago [-]
Is x = !x faster than x.toggle() because from my naked eyes no function is called? Or does the compiler know that the function toggle should be replace with `!=`? If the compiler does know that, how is that knowledge implemented? Is there a table of special functions that should be replaced with something else? Or some more clever way?
tialaramex 1 hours ago [-]
Thanks to Matt Godbolt, we can ask Compiler Explorer!
The LLVM backend used by Rust is jokingly said to have a inlining heuristic of "yes" ie it will always try to inline everything because that's usually faster.
xiej 54 minutes ago [-]
Unfortunately it's not inlined in debug/no optimization mode so that's rough.
saghm 24 minutes ago [-]
I'll go out on a limb and hypothesize that there are going to be much larger difference between debug and release mode for any non-trivial code that the overhead of `toggle` in debug mode will quite literally never end up mattering to anyone in practice.
"Good enough" is subjective, but I personally prefer the new way
thayne 41 minutes ago [-]
If you have a (&must) reference it would actually be x = !x. Also toggle is a function that can be passed to higher order functions without needing a lambda. For example, if you have a boolean in an option you can do opt.iter_mut().for_each(book::toggle). Or similar if you had a collection of booleans.
IshKebab 5 hours ago [-]
If you access the bool through a long path maybe.
foo.bar().baz[expensive()].qux.toggle();
crabmusket 1 hours ago [-]
This gives me the same feeling as when I saw Rust's map Entry API
Looks like part of the motivation was for things with long names like `some_struct_a.some_field_b.some_subfield_c`, where needing to name the field twice would have pushed people to using `^= true` instead, which is a bit more roundabout to decipher and risks people forgetting the idiom and writing `^= false` by accident. Not necessarily the most useful API, but not unmotivated and harmless to add.
ammar_az 4 hours ago [-]
I think `toggle()` is also much better for readability as `^=true`
afdbcreid 8 hours ago [-]
They are mentioned in the blog post, under "Stabilized APIs".
steveklabnik 8 hours ago [-]
A monumental release. Thanks to everyone who worked so hard on all of these long-term features that are finally landing.
caaqil 3 hours ago [-]
Plaudits to all involved, as the sermon goes.
jadbox 7 hours ago [-]
Is the compiler any faster now? Compiling takes forever. I'm also tired of always having to do "cargo clean" everyday to clear out 90gb of temp files.
epage 7 hours ago [-]
Faster compile and smaller build-dir can be at odds with each other.
That said, this release includes some incremental improvements as well as the unused-dependency lint to help reduce wasted work within the ecosystem.
Some changes that have been or are about to be merged for upcoming releases
- We will be reducing the debug info generated for the `dev` profile which reduces build-dir size and speeds up builds. We've split off a `debug` profile for when that is needed.
- Cargo will be deleting the directory rustc writes before each invocation, avoiding the leaking of debug files when split-debug is enabled (default on Mac)
- rlibs for workspace members will no longer be copied from build-dir to target-dir which takes up extra space on systems without hardlinking or where we skip it (like Mac)
- redundant information in rlibs and rmeta's is going to be de-duplicated
Examples of further out changes
- This release includes the foundational work to add a build-dir GC
And the large target directories is also being worked on as well.
small_model 7 hours ago [-]
Yes this is why I switched to Go for backend, much faster compiling and performance isn't an issue for the application yes using 100GB+ is just bad tooling.
the8472 1 hours ago [-]
Yes, lots of optimization work has it made faster despite gaining new features.
try disabling at least some debug-info for your dependencies.
use cargo's --timings option to identify the slow crates, then use measureme to figure where rustc is spending time.
try fiddling with detached debug-info, dwp files can be smaller than their constituent dwo files.
ensure really small "template wrappers" are inlined.
lower the number of compilation-units you use.
For incremental builds I have found it can _sometimes_ be effective to split out larger dependencies into a dynlib. You create a dylib crate that re-exports said dependencies and your executable depends on that. Ofc things like generics from the offending libraries will still end up in your executables; Though I think there is a way to mitigate this a little.
This mostly helps with link-time, and saving space if you have a bunch of executables (using the argv[0] trick will help more, though).
vlovich123 7 hours ago [-]
Any faster vs what baseline? They’ve constantly made improvements and Rust today is pretty darn quick, especially for incremental. There’s work to parallelize the front end which will help a little bit and you can always use the cranelift backend for debugging which is substantially faster than LLVM.
They’re also doing work to reduce the amount of disk space usage (by clearing out unused articacts) and make it easier to maintain.
jtwaleson 6 hours ago [-]
Best to do some benchmarks for cranelift on your codebases and system. It used to be quite a lot faster, but for me the advantage has disappeared over the last year of Rust improvements.
There's really a paradox here. Rust claims to be a fast language, but compiling, even without optimizations on, takes ages ...
barchar 5 hours ago [-]
Rust encourages a kind of generic programming that can result in generating too much code.
The compilation model is vastly, vastly, vastly better than languages like C++ and C, though, and it does compile much faster than an equivalent C++ build (doesn't count if you download precompiled binaries of your c++ dependencies)
cozzyd 3 hours ago [-]
But the lack of ABI stability means that's not a choice anyway, doesn't it?
SAI_Peregrinus 2 hours ago [-]
Rust can compile to dynamic libraries. If you don't use the C abi you have to compile anything that loads them with the same Rust compiler version and target triple. So you need to have some way to guarantee the correct compiler is being used, e.g. Nix or Bazel.
cozzyd 36 minutes ago [-]
And possibly compilation options?
IshKebab 5 hours ago [-]
That's not a paradox, that's how it always works. Compiling to fast machine code requires more work and takes longer.
Is Python a fast language because it barely takes any time to compile the code? No obviously not.
Matrixik 4 hours ago [-]
Looks like people extending rust never really focused on compile speed when designing features (from [1]):
> If you could reinvent/change any aspect of Rust, what would you do alternatively?
> A lot happened because we wanted to ship a useful thing with only so much time in the day, so some things were less deliberate than others. There’s an alternate version of Rust with significantly faster compiler times, because while we cared about compile times when designing we always prioritized other values more. We never asked ourselves how this feature or implementation impacted compiler analysis time and there are several spots where something slightly different would have much faster compiler times, which people do care about. But had we spent time on that, we would have neglected other things and not been any more successful.
This is important, because most often during development you want fast compilation times more than you want fast code.
afdbcreid 4 hours ago [-]
That still isn't a paradox. Furthermore it still makes sense: a language designed to generate the fastest code has constructs that cannot be compiled quickly, even without optimizations.
But some of it is implementation problems.
adastra22 42 minutes ago [-]
Rust's compilation speed issues are not due to optimizations. There is some intrinsic slowness, but also some boneheaded decisions that are now baked in. E.g. the unit of compilation being the crate, not file/module, makes it so you hit some bad scaling laws. And the borrow checker is SLOW, and unavoidably so, but borrow checking could have been avoided with different lifetime rules. Etc.
I say this as a full-time rust developer btw.
aw1621107 14 minutes ago [-]
> And the borrow checker is SLOW, and unavoidably so
IIRC for most codebases borrowck actually makes up a pretty small proportion of compilation time (e.g., see [0] for some admittedly rough estimates).
> but borrow checking could have been avoided with different lifetime rules.
I'm not sure you could entirely avoid borrow checking without a pretty significant change to what you're allowed to do with references.
There's no paradox here. You can use any benchmark you like to prove that Rust is a fast language. The work that the compiler does is irrespective of the language that rustc is written in.
amelius 6 hours ago [-]
Yes, the benchmark is compiler compiling itself. From scratch and incrementally.
kibwen 5 hours ago [-]
Unfortunately, that isn't how any of this works.
aw1621107 8 minutes ago [-]
> Rust claims to be a fast language, but compiling, even without optimizations on, takes ages ...
As usual, this begs the question of "compared to what"? "Fast" languages obviously don't have some magical ability to guarantee that every program written in them is Blazing Fast(tm); without further inspection one can come to any number of other equally plausible conclusions (e.g., the program is fast for what it does).
saghm 22 minutes ago [-]
Have you been similarly confused by how slow compiling can be for massive C++ projects for decades? I have trouble believing that you genuinely think that's what anyone means by saying Rut is fast.
eptcyka 6 hours ago [-]
On macOS there is a known bug where some temp files are always created anew, not reused, which slows down compilation and wastes more space than other platforms.
adastra22 48 minutes ago [-]
Do you have details? I think I'm running into this.
epage 6 hours ago [-]
Fixed on nightly.
0o777 6 hours ago [-]
All the big AI companies use Rust so this is probably something they should focus on improving.
panstromek 6 hours ago [-]
They do fund some of these efforts, yes.
flykespice 2 hours ago [-]
What the hell are you doing to produce 90gb of temp files? Is that normal on rust land?
adastra22 49 minutes ago [-]
It's large but not insane. I've got 20gb in a not-too-large repo.
kstrauser 54 minutes ago [-]
No. My target directory is 329GB at the moment. I wish mine were just 90GB.
(And yet I’m perfectly happy running `cargo clean` periodically in exchange for all the Rust loveliness. Sure, I wish I didn’t need to. Sure, I hope it’ll get better. I can live with the temporary inconvenience though.
Also, I’m developing in a tight auto-build-on-commit loop so I have a gazillion builds.)
benjiro29 4 hours ago [-]
Is the compiler any faster now?
If your codebase is not some small project, its excruciating slow. Even if you try different linkers, and other compilers, nothing really make incremental compiles eat so much of your system. Even more so if you have multiple AI agents doing security and other checks.
Switched to Go for several months, and the difference was very noticeable. Until you started to get there also 50k+ files that are interlinked. And let us not talk about Go and Rust their issues with insane amount of debug/cache buildup.
Imaging if you have 4 to 6 agents running that, with each seeing the cache grow from 20, 30, 40 ... To the point that a 100/1000GB SSD grows to 800, 900GB usage. Often in barely a day.
Seen my NVME drive its lifespan drop from 98% to 91% in barely a few month time. I dread looking at it again lol
What was the solution? Going back to C ... Despite right now working on a 800k lines project, it compiles way faster the Go, and well, Rust will have pegged all 16 cores for a minute, for EACH agent trying to recompile on a small change.
Memory safety? Instead of checking at compile time, and wasting my time, this has simply been moved to AI agents checking, making tools, checking, at night. So it does not disturb my own work.
Its ironic, how both modern projects, end up being worse off. Best of all, the C project is way faster then the same project in Go and Rust. Yea, it was "fun" having AI transcompile them twice but the difference on actual large codebase, and not some micro benchmarks is not a joke. To the point that now all my projects have gone back to C...
And yea, i expect some fast downvotes by our Rust friends because saying something negative about Rust always gets people downvoted here. No offence but Rust being linked to LLM and the whole checker was a benefit before AI came around. But now you can offload a lot of safety checks to the backend/offhours, instead of paying for it with every compile.
shevy-java 5 hours ago [-]
Well, the AI that slops out Rust code won't mind having to wait!
throwaway27448 7 hours ago [-]
I don't understand why people complain about this non-stop. If compilation time is such an issue use a different language. I can't say I've been bottlenecked by compilation in a very long time.
IshKebab 5 hours ago [-]
I don't think you can tell people not to complain about it - it is clearly very desirable to have faster compilation, like Zig or Go.
But that said I do agree it is pretty fast these days. Significantly faster than C++ and people have tolerated that for decades.
throwaway27448 3 hours ago [-]
I didn't tell anyone to do anything. I just don't get why people complain—it's like they don't grasp the concept of tradeoffs.
ComputerGuru 9 hours ago [-]
It would probably be better to wait for the official release blog post for submission to HN, no?
DropGuard is nice. This is basically `defer` in Go I think.
Groxx 4 hours ago [-]
A defer that you can explicitly skip (via `dismiss()`) - I like it, that'd clean up a fair bit of "do this for safety unless successful" Go code that I've encountered. I've built similar things before, sometimes it helps a lot, and often that's in especially gnarly code which generally benefits from any clarity improvement.
aw1621107 3 hours ago [-]
Minus Go's defer being function-scoped, of course.
(and what sibling comment mentioned)
pmichaud 8 hours ago [-]
Nice work... but I still yearn for a stable ABI!
JoshTriplett 7 hours ago [-]
The primary challenge in having a stable ABI is that we have generics. So, even if we never changed the calling conventions, an ABI is not as simple as exporting a symbol with the right name. We implement generics by providing MIR (our main intermediate representation) that gets compiled by the linking program for each instantiation of a generic.
Swift handles this through the equivalent of Rust's `dyn`. We could have a stable ABI that's based entirely on `dyn`. Such an ABI would have some limitations, since there are traits `dyn` can't represent (anything that's generic over something other than the type that implements the trait, which is quite common), though we're working on some of those.
Essentially, you wouldn't be able to have a `Vec<T>` in your ABI without either pinning down T or using something like `Vec<Box<dyn Trait>>`. Which is possible, but kind of awful.
We're still planning to ship a stable ABI at some point, but that gives a flavor for some of the kinds of problems we'd need to solve in order for that stable ABI to be useful.
(C++ typically handles generics by having types defined in header files, and those get compiled with the program consuming the library, which is effectively the same situation Rust is in. You could export symbols from a shared library for specific instantiation of a template, but people rarely do that.)
mamcx 6 hours ago [-]
I wonder why not make the ABI contract explicit, instead of do what C do that froze the lang.
Similar to :
#[rust_abi]
struct MustConform
fn must_conform
So the user must write the shims instead of rust magically build it. This also mean that ABI changes become visible, and changes to rust not mean worries about ABI.
chiffaa 5 hours ago [-]
To my knowledge this is what crABI is all about
yrjrjjrjjtjjr 5 hours ago [-]
A generic could be seen as a pure (in the functional sense) program that is run at link time that takes various type information as input and outputs an implementation.
pjmlp 6 hours ago [-]
You are forgetting C++ has modules now, and extern templates, as implementations for common type parameters.
IshKebab 5 hours ago [-]
I would be happy with something better than the C ABI even if it doesn't support everything in Rust on day one.
barchar 5 hours ago [-]
I think there's some work on that, getting at least slice and trait object ABIs that you can use in DSO interfaces.
JoshTriplett 5 hours ago [-]
Same.
gspr 5 hours ago [-]
Thank you for your work, it's always interesting to read your take.
Forgive the naive question on something that's probably been discussed many times over, but could there be a middle ground when it comes to a stable ABI and generics? Something where the person building the library for dynamic linking chooses which explicit monomorphizations they'd like to provide for each public generic function (and type), and the compiler stamps out all combinations of those concrete instances? Could the way these are named and stamped out be standardized so that this could be treated as a stable ABI for non-generics?
It seems to me that it would at least cover distros: they could make a pass over all their Rust code and determine which monomorphizations are needed throughout the distro.
orlp 8 hours ago [-]
We have it: unsafe extern "C" { }.
An actual stable native Rust ABI sounds like a forward compatibility nightmare.
Xirdus 8 hours ago [-]
An actual stable native Rust ABI is a prerequisite for distributing libraries as anything other than source code.
ChadNauseam 7 hours ago [-]
What is the advantage of doing so? Is it for cases where your source code is confidential but you want to sell access to your library?
cogman10 6 hours ago [-]
Operating systems.
If there's a CVE in tokio, the OS could theoretically publish a patched version of tokio and all apps that depend on that end up using the fixed code.
As it stands now, the OS needs to publish updated versions of all rust apps that depend on tokio.
afdbcreid 6 hours ago [-]
That's not how it works basically anywhere except in C/C++ apps on Linux.
cogman10 6 hours ago [-]
Yes and no.
Yes, in that it's primarily a linux thing as MS has gone the route of saving off basically all dlls for all their OSes for backwards compatibility (though they still backpatch).
No, in that other than Rust and Go (and maybe a few others that emit single binaries, zig?) this is how it works with OS distributed programming language packages. Python, ruby, java, perl, C#, the OS will for all of them control distribute and update the libs independent of the apps that use them.
Also, C/C++ still make up a huge percentage of all apps in pretty much any OS.
the8472 2 hours ago [-]
> prerequisite for distributing libraries as anything other than source code.
> Python, ruby, java, perl, C#, the OS will for all of them control distribute and update the libs independent of the apps that use them.
Those are all JIT'ed languages, so they're distributed in source or intermediate form, not as fixed-ABI-shared-libraries.
It's really just C where shared libs really work. Even C++ has wrinkles.
afdbcreid 5 hours ago [-]
> No, in that other than Rust and Go (and maybe a few others that emit single binaries, zig?) this is how it works with OS distributed programming language packages.
Uhmm... No? E.g.:
- Python has long strongly recommended virtual environments.
- Not to talk about JavaScript which of course manage things per project by default.
- I don't remember what was the state of things in .NET Framework, but in modern .NET NuGet packages are distributed as DLLs with your app.
I don't know other ecosystems well but I believe they aren't different.
cogman10 4 hours ago [-]
> Uhmm... No?
Ummm... yes.
How software is maintained by an OS is different from how software is maintained by 3rd party developers.
- Python has long strongly recommended virtual environments.
Yes, if you are developing a private application. But if that application gets adopted by the OS then you can expect all it's dependencies to be sent to a place like `/usr/lib/python3/dist-packages`.
> Not to talk about JavaScript which of course manage things per project by default.
I didn't bring it up because it's one I'm not familiar with. I expect OS maintainers will do similar things with it that they do with python but I'm not 100% on that.
> I don't remember what was the state of things in .NET Framework, but in modern .NET NuGet packages are distributed as DLLs with your app.
And if your .net application ends up installed as an OS package you can expect those dlls to be stored in /usr/lib.
If you are doing C/C++, as a 3rd party app, you aren't putting the .so files or the .dll files in /usr/lib or C:\Windows\System32. You are storing them in the same directory as your application. But if the OS decides to distribute your app, you can expect your .so files to get put into /usr/lib and even System32 (very very rare for MS to do that, but it does happen when, for example, we are talking about drivers).
But that's the thing: almost nobody ships software via the OS today. Even on Linux software is often managed in other ways.
cogman10 2 hours ago [-]
Let me rewind this to the top of the thread.
> What is the advantage of doing so?
To which I responded
> Operating systems.
To which you said
> That's not how it works basically anywhere
I think we have reached the point in the thread where you concede that yes, there is somewhere where it's how it works and yes it does apply to languages that aren't C/C++.
So now you're shifting the goalposts and topic to
> almost nobody ships software via the OS today.
That was never something I was trying to debate. The topic was "why would you want ABI stability". And the answer is that if I wanted to rewrite coreutils in rust, then it'd be really useful to have synchronized crates with a stable ABI so I could potentially update those crates independent of the apps that depend on them.
afdbcreid 2 hours ago [-]
I agree that sometimes other languages are packaged this way as well, and maybe I was moving the goalposts. My original meaning was that only for C/C++ (on Linux) the recommended method of distribution is via the OS, while other languages have their own mediums (not requiring stable ABIs). So when they are packaged like that that's mostly because the OS itself or its services need them.
gspr 5 hours ago [-]
Well yes exactly, because essentially nothing else has a stable ABI.
Xirdus 6 hours ago [-]
Because only C/C++ apps have stable ABI. Everyone else would love to do it too but they're S.O.L.
afdbcreid 4 hours ago [-]
That's not true. Scripting languages of course need no ABI. Managed languages like C# and Java often keep compatibility of the bytecode. Only AOT languages like Go and Rust cannot.
xigoi 4 hours ago [-]
Interoperating witt other languages without having to use C as a middleman?
saghm 16 minutes ago [-]
I agree that using the C ABI for interop between arbitrary non-C languages feels weird, but it's not like that wasn't a thing long before Rust ever existed. If you truly want a modern ABI for languages that are not C, something like the WASM component model is probably the closest thing that exists today.
Xirdus 3 hours ago [-]
An unstable ABI is entirely sufficient for that, as long as you update both sides in tandem.
flykespice 2 hours ago [-]
Yep, and it also imposes a big security risk relying on a closed binary blob that could be injected anytime with a backdoor.
Afaik, odin seems to get it right requiring libraries to be distributed source only.
xtajv 5 hours ago [-]
There is another thread complaining about compile times and tmp dir sizes.
Stable ABI dramatically improves the problem space there (without necessarily having anything to do with business model).
SkiFire13 8 hours ago [-]
It's not a strict prerequisite, you can just require the library being distributed to use extern "C".
gspr 8 hours ago [-]
Well yes, but then your interface is a C ABI. That's fantastic if the side using my library is any language where C is the only common ground. When the application side is Rust though, it leaves a lot to be desired. It would be delicious to actually interface in a way that respects Rust!
Hell, even if all exposed functions and types would need to be fully monomorphized at the interface, it would be a lot nicer to pass a `&'a [i64]` rather than a `const * int64_t` together with a `size_t n` and have to marshall the slice on both sides.
Xirdus 7 hours ago [-]
Or to put it another way, it is a strict prerequisite and Rust already meets it via extern "C".
wahern 8 hours ago [-]
Another year or three of insane memory and disk prices and people will come around.
A stable Rust ABI would be nice for not just Rust, especially if they refine or extend (formally or de facto) the SysV ABI to optimize passing and returning of discriminants. That could then smooth the way for developing these features in C and C++, such as a primitive error-result type that saw some brief attention in both C and C++ WGs a couple of years ago. Doing it properly--absolute minimum cost, ABI stable, and cross-language--seemed to require too much orchestration across the ecosystem so enthusiasm and ambition seemed to peter out. The work required for a stable Rust ABI could provide the inertia to get that done.
afdbcreid 8 hours ago [-]
Rust will almost certainly never have a stable ABI by default, and libraries will continue to be compiled from source by default. It might one day have an opt-in stable ABI.
fallingbananna 7 hours ago [-]
If you can drop the "native" requirement, then Wasm is also a way.
redox99 8 hours ago [-]
Why would you want libraries in any other format?
eviks 8 hours ago [-]
Not to waste time and space?
iknowstuff 8 hours ago [-]
Follow or contribute to efforts on a minimal crABI:
I don't think a stable ABI has enough advantages to be worth it. C++, IMHO, is a great examples of the downsides of a stable-enough ABI, where stability was never guaranteed, but is now so entrenched that it'll likely never be broken again (limiting the language & the usability in a bunch of ways).
It might make sense to have a subset Swift-style stable ABI, but that's a huge engineering effort, has lots of overhead and is also likely not worth it IMHO.
stillpointlab 8 hours ago [-]
stable ABI sounds great, but anything/everything that reduces build times is what I really want
Narishma 5 hours ago [-]
A stable ABI would help with that.
Svoka 8 hours ago [-]
Why the yearning for prebuilt Rust libraries? Seems like a nightmare which does not need to happen.
gspr 7 hours ago [-]
Dynamic linking is useful. Not to everyone and not always, but it is.
kibwen 6 hours ago [-]
Rust supports dynamic linking. What a stable ABI provides is cross-toolchain dynamic linking.
Woshiwuja 8 hours ago [-]
[dead]
silon42 8 hours ago [-]
So, all Linux will be Gentoo?
Svoka 33 minutes ago [-]
what? There is stable ABI. It's C's stable ABI. If you are reimplementing existing libraries like most of rust rewrites are, you already have ABI you have to follow.
ustad 8 hours ago [-]
“Never type” - Feel like I’m stupid for not having a clue what that means.
Xirdus 7 hours ago [-]
Mathematically, types are sets of possible values.
Any type (like in TypeScript; Rust doesn't have one) is a set of every possible value; a supertype of all types. Every expression regardless of type can be assigned to a variable of type any.
The opposite is the never type, which is an empty set; no value is of type never. Per set theory, an empty set is a subset of every set, which makes the never type a subtype of all types. An expression of type never can be assigned to every variable regardless of type.
If never type has no values, then how can an expression have never type? Easy: it must never evaluate. Infinite loops, unconditional panics/exceptions, process exit/abort, etc. Also, generics - you can have Vec<!> that's always empty, Result<T,!> that can never be an error, etc.
Also called top and bottom types, for this reason.
steveklabnik 6 hours ago [-]
Any is not a top type and ! is not a bottom type, actually. They are sort of similar from a lay perspective if you squint, though.
afdbcreid 5 hours ago [-]
Why not? I mean if you refer to Rust specifically, yes, because there is no subtyping except for lifetimes, only coercion (and `Any` also cannot contain any type). But in general, why not?
steveklabnik 5 hours ago [-]
I am speaking about Rust specifically, yes.
boston_clone 7 hours ago [-]
Comprehensive yet succinct, and appreciate you tying it to math - that helped solidify the idea.
saghm 11 minutes ago [-]
It's the type of what you get back from a `panic!` (a value you never actually get back).
A few other langs have it too. It's just something to return when no return is actually possible. And then it can propagate, so it makes some nice things possible that weren't before.
igravious 7 hours ago [-]
Without looking up the Rust implementation I would hazard a guess that it is loose language to say "something to return when no return is actually possible" because if it is anything like the Bottom Type then there is no something that is being returned which is what this function signature indicates. Generally used for exception handling or intentional infinite loops (in both cases the function does not return from whence it came) … please correct me if I'm wrong here …
kibwen 6 hours ago [-]
Basic use cases like that have always been possible in Rust, either via defining your own enum with zero variants (`enum Foo {}`), or by using a function return type of `!` which was hardcoded to work for certain things, e.g. infinite loops. What this release does is generalizes it so that `!` can participate in types in general, and the coolest part is that pattern matching is aware of this, so for example if you have a `Result<u8, !>` where the error variant is impossible, a `match` over this would allow you to omit the impossible error arm, and furthermore because this enum now effectively only has a single variant, it would allow you to use the pleasant irrefutable destructuring assignment syntax `let Ok(foo) = blah();`.
afdbcreid 6 hours ago [-]
It has existed as a real type for a very long time (I believe in the beginning it really wasn't a real type but that's a long time ago), you just weren't allowed to name it. There was also an (unsupported) hack that allowed you to use it on stable.
yccs27 6 hours ago [-]
If you have a variable x: ! in scope, your code can never be reached.
LoganDark 7 hours ago [-]
It's the type called "!", or the return value of diverging control flow, such as infinite loops, returns or function calls that panic or abort. It's an uninhabited type, meaning no values of it can actually exist, and that any code that would encounter such a value is unreachable.
NooneAtAll5 7 hours ago [-]
noreturn, basically
mkl 5 hours ago [-]
> cargo install ignores the minimum publish age, for both the installed crate and its dependencies
Why is that? It seems like that makes min-publish-age much less effective.
epage 2 hours ago [-]
This comes from usability and consistency.
When we added the MSRV aware resolver, we decided to have it not affect `cargo install` because you could get an old version and not notice (especially with how noisy cargo is) when the right answer might be to upgrade.
Somewhat similar for min-publish-age but also we had defined the parent table for these config fields to not affect install.
The change to `--locked` made us feel a little better with this non-ideal circumstance.
GolDDranks 3 hours ago [-]
The fact that install now uses the lockfile by default, mitigates this, I think.
AndruLuvisi 3 hours ago [-]
I can't find any mention of become. Does rust have proper tail calls now?
I just spent last few days fixing arena leaks (Bumpalo doesn't call drop) and had to use allocator-api2 for Vec::new_in which is now available in stable Rust.
Wait for the timing of the next release. It will be a Christmas present.
hobofan 8 hours ago [-]
Thanks to all the maintainers and contributors! That's one of the biggest releases in a long time!
fock 8 hours ago [-]
also humans contributing! Very cool!
fluffiac 8 hours ago [-]
yay never type!!
when can we expect `Result::into_ok` and `Result::into_err` to land? the blog post includes the `infallible_unwrap` demo which is the exact functionality these two functions implement. i wonder why they didn't release these at the same time as never?
(As for why they weren't stabilized at the same time: because it's not worth adding more baggage to a major, difficult stabilization process; as that would just be more surface area that has to be reviewed and another source of potential issues or delays. Instead, the stabilization process for infallible_unwrap was started immediately after `!` was stabilized. That process includes a 2-week final comment period for community feedback which is why they landed in different releases.)
saghm 9 minutes ago [-]
The six week release cadence means that stuff like this is not a huge deal, and it's honestly kind of insane how consistent it's been over what's now 100 minor releases over 11 years!
wpollock 6 hours ago [-]
This is great news! Well done Rust team!
As this release seems to include breaking changes, shouldn't the major version number have been bumped, as per semver?
Has the Rust book(s) been updated to include the new APIs?
kibwen 1 hours ago [-]
Rust's three stability caveats are as follows:
"We reserve the right to fix compiler bugs, patch safety holes, and change type inference in ways that may occasionally require new type annotations."
The breakage in question here falls under changes to type inference, which are allowed within reason when they're relatively minor, when steps have been taken to mitigate any breakage in the broader ecosystem, and when the compiler has emitted warnings regarding the imminent change during a grace period, all of which have been done here.
karavelov 9 hours ago [-]
Finally, "never" happened
JoshTriplett 8 hours ago [-]
And the running joke that the type is named after its stabilization date can finally be put to rest. :)
hbn 7 hours ago [-]
We got "never" in Rust before GTA6
Two jokes that are expiring this month
jmyeet 8 hours ago [-]
One might call this the moment when nothing never occurs [1].
Human intelligibility and coherence does not seem to matter any more,
for current software development.
sawirricardo 2 hours ago [-]
i wish for small storage and short duration compilation times
einpoklum 4 hours ago [-]
Would you say that having 100 releases of the language more of a positive thing or a negative thing?
For comparison, C has had, say, 4 versions, and C++ 7 had versions (depending on how you count). But - Java has had 27 main versions and probably more than a 100 if you count minor versions/updates.
estebank 2 hours ago [-]
They are completely different release processes, for different things. C and C++ are language specifications and Rust is a tool chain. Even comparing against another compiler tool chain like gcc it wouldn't be a 1 to 1 comparison. Rust having 100 minor releases is only a factor of the passage of time.
Last time I checked between a quarter and a third had a patch release, and those are closer to a signal of "a minor release had a problem". When analysing those my conclusion and the time was "for the most part they were needed because some niche feature or platform had a regression that wasn't caught by the suite and a handful of regressions causes by enabling a new feature or updating llvm".
Even Rust Editions are not a good point of comparison because they are also time based and only leveraged by things that would otherwise be breaking changes.
What you could use for direct comparison is accepted Rust RFCs against accepted C++ proposals papers or the equivalent for other languages. Or merged Pull/Merge Request counts for the different tool chains. But that's not perfect either (Rust only supports one language, while GCC several, but it has a package manager, which GCC doesn't).
tialaramex 3 hours ago [-]
101 stable Rust minor releases, because 1.0 was a stable release, and many more micro releases incorporating merely urgent bug fixes with no other work.
Even ignoring K&R C there is C89, C99, C11, C17, C23 and C2y is in progress. I don't see any way to squint at that and count four.
uncivilized 3 hours ago [-]
The blog post says min-publish-age depends on the registry recording a pubtime. Why would pubtime not exist in the index?
epage 2 hours ago [-]
It was only added to the registry spec a few releases ago. We can't guarantee that a registry has updated to provide it.
uncivilized 11 minutes ago [-]
Ah I see, but that means all new releases on crates.io will have that tag, correct?
wait other things not named jensen happened today? whoa
nazgulsenpai 8 hours ago [-]
once outlook broke we can't even share jensen memes
yoy0721 3 hours ago [-]
[flagged]
joshsyn 2 hours ago [-]
[dead]
theapiartist 8 hours ago [-]
[dead]
Sol- 5 hours ago [-]
Do language features still matter except insofar as they make the LLM verification loop better?
yodsanklai 4 hours ago [-]
You're downvoted but it's a very legitimate question. My main language at work is Rust, I had some expertise with the language (and deep interest for functional programming languages and type theory), but I almost don't read the code nowadays, I just skim though the functions and type definitions. I'm genuinely surprised that there are so many comments commenting the release. I thought most programmers wouldn't care anymore.
KolmogorovComp 7 hours ago [-]
I haven’t seen any blog on the topic but I fully believe in the age of coding agents and LLM backward compatibility is a bit less important than it has been in the past and should be relaxed in some cases to allow language to move faster.
raphlinus 7 hours ago [-]
I get your point but disagree strongly. One topic that's been on my mind a lot is durability. The culture of LLMs is that everything is transitory. Why bother keeping a vibe coded codebase around for more than a few weeks, when the next big model iteration will be able to vibe code it better?
By contrast, free software in general, and Rust very much in particular, has cultural norms that things should last a while, rather than immediately being thrown away. I think that's worth preserving.
Surac 8 hours ago [-]
Still non ABI. Why is ist so hard? what is holding them back. Andy why does it need a unsave keyword? can't they marshal types like other languages?
kbolino 6 hours ago [-]
You can marshal values, but you can't marshal lifetimes, ownership, (lack of) thread-safety, (lack of) side-effects, etc. The ABI carries far less information than the Rust compiler relies on. Thus, any FFI call is inherently unsafe. It takes you, the programmer, with knowledge the compiler doesn't have and the architecture doesn't provide, to determine whether the code as you use it actually is safe or not.
adamch 8 hours ago [-]
because they change the binary layout sometimes, and the benefits have not yet been judged to be worth freezing it.
vablings 5 hours ago [-]
I mean they could also have a stable ABI for 2.0 and then and changes are breaking herein. Its kind of a choice problem
galangalalgol 7 hours ago [-]
It is explained elsewhere, but a summary is that any language with generics is going to have any stable abi as a subset of the language. There is already a subset of the language that is a stable abi, it is the c abi. Expanding that subset has to be worth it in terms of what people actually want to export from a library. As I use generics fairly heavily I don't think I would use that expanded abi for anything.
- Stabilize never type
- Stabilize custom allocators
- Introduced minimum publish age configurations, also known as dependency cooldowns. When the relevant config is set, the resolver ignores versions published more recently than that, unless they are already in Cargo.lock. (RFC 3923) docs #17335
- cargo-install: now uses the existing lockfile in the .crate tarball by default. --locked in cargo install becomes a no-op. #17388
Long time follower of this. Very grateful it's been implemented.
Nonetheless, the ability to set and configure it is a welcome feature.
One of the biggest ergonomic problems with cooldowns is that many tools let the former goal obstruct the latter. Both should be part of the state machine of resolution itself, rather than things that get layered on.
> warning: unused dependency `tracing-subscriber` --> Cargo.toml:23:1 | 23 | tracing-subscriber.workspace = true | ^^^^^^^^^^^^^^^^^^ | = note: `cargo::unused_dependencies` is set to `warn` by default help: consider removing the dependency on `tracing-subscriber`
Heck yes
The main limitation is in dev-dep detection since there isn't a way to exhaustively run everything that uses dev-deps yet. You can look at logging statements to get an approximation though.
- bool::toggle() https://doc.rust-lang.org/stable/std/primitive.bool.html#met...
- Box::map() https://doc.rust-lang.org/stable/std/boxed/struct.Box.html#m...
- str::trim_prefix(), str::trim_suffix, Path::trim_prefix()
But under the hood it's all the same https://doc.rust-lang.org/stable/src/core/bool.rs.html#157-1...
It’s only weird if you come from languages like Java where “primitives” are distinct from “objects”, which is a self-imposed limitation the language imposes.
Otherwise agreed, methods like this can be mutable in any language that doesn't heavily specialize primitives.
This is definitely something that Rust does a bit different than most other languages, but it's not anything specific to this method, booleans, or particularly new to the language. Most people will learn about the common different ways of defining a method (via ownership, shared reference, or mutable reference) fairly early on in programming Rust.
In effect, if x is a bool, doing x.toggle() is rewritten by the compiler as bool::toggle(&mut x), which can of course modify x.
pub const fn toggle(&mut self)
The "&mut" says that toggle takes a mutable reference to the instance it is called off of. This is also called a mutable borrow. You might think that would get buried in the program because you don't always check the type signature of every method you call, but there are a few reasons that muts really jump out in rust. The languages immutable by default nature is one and the other is that several IDE have features to specifically draw attention to mutable instances/references. It's a fairly common pattern in rust to have helper methods on a type that take a mutable reference or ownership of self.
TL;DR: Rust's ownership model is very unique. Once it clicks its the cat's pajamas, but experience in other languages don't map well to this part of the language.
Primitive types and composite types having the same capabilities is a bit of a value statement for C++ and Rust IMO, and it's missing in a lot of languages downstream (IMO) of the "every variable is a reference to a slot/pointer" philosophy taken by most every managed language
One reason is that C++ doesn't know where to put them, for user defined class, struct or union types these "member functions" as their name suggests live inside the class/ struct/ union definition but for a primitive where would these live?
In Rust they're just impl blocks, for example the method we're discussing here is:
x = x + 1
So long as the variable is mutable it's value can be changed
https://rust.godbolt.org/z/dPn3Y4r59
The optimizer gives the exact same machine code for both functions, and so it just outputs a single function and gives it an alias.
The compiler has a technique called "inlining" https://en.wikipedia.org/wiki/Inline_expansion
The LLVM backend used by Rust is jokingly said to have a inlining heuristic of "yes" ie it will always try to inline everything because that's usually faster.
https://std-dev-guide.rust-lang.org/policy/inline.html
https://doc.rust-lang.org/std/collections/hash_map/enum.Entr...
It's very ergonomic.Looks like part of the motivation was for things with long names like `some_struct_a.some_field_b.some_subfield_c`, where needing to name the field twice would have pushed people to using `^= true` instead, which is a bit more roundabout to decipher and risks people forgetting the idiom and writing `^= false` by accident. Not necessarily the most useful API, but not unmotivated and harmless to add.
That said, this release includes some incremental improvements as well as the unused-dependency lint to help reduce wasted work within the ecosystem.
Some changes that have been or are about to be merged for upcoming releases
- We will be reducing the debug info generated for the `dev` profile which reduces build-dir size and speeds up builds. We've split off a `debug` profile for when that is needed.
- Cargo will be deleting the directory rustc writes before each invocation, avoiding the leaking of debug files when split-debug is enabled (default on Mac)
- rlibs for workspace members will no longer be copied from build-dir to target-dir which takes up extra space on systems without hardlinking or where we skip it (like Mac)
- redundant information in rlibs and rmeta's is going to be de-duplicated
Examples of further out changes
- This release includes the foundational work to add a build-dir GC
- Cross-workspace de-duplicating of build-dirs
- Cross-workspace build-dir cache
- Early cut off
“Relink, don't rebuild” #790
https://github.com/rust-lang/compiler-team/issues/790
- stable id's even when the source changes
- a separate output file dedicated to it so you hash that
Those aren't free, taking extra work to implement and possibly slow down the compiler
And the large target directories is also being worked on as well.
https://perf.rust-lang.org/dashboard.html
use cargo's --timings option to identify the slow crates, then use measureme to figure where rustc is spending time.
try fiddling with detached debug-info, dwp files can be smaller than their constituent dwo files.
ensure really small "template wrappers" are inlined.
lower the number of compilation-units you use.
For incremental builds I have found it can _sometimes_ be effective to split out larger dependencies into a dynlib. You create a dylib crate that re-exports said dependencies and your executable depends on that. Ofc things like generics from the offending libraries will still end up in your executables; Though I think there is a way to mitigate this a little.
This mostly helps with link-time, and saving space if you have a bunch of executables (using the argv[0] trick will help more, though).
They’re also doing work to reduce the amount of disk space usage (by clearing out unused articacts) and make it easier to maintain.
The compilation model is vastly, vastly, vastly better than languages like C++ and C, though, and it does compile much faster than an equivalent C++ build (doesn't count if you download precompiled binaries of your c++ dependencies)
Is Python a fast language because it barely takes any time to compile the code? No obviously not.
> If you could reinvent/change any aspect of Rust, what would you do alternatively?
> A lot happened because we wanted to ship a useful thing with only so much time in the day, so some things were less deliberate than others. There’s an alternate version of Rust with significantly faster compiler times, because while we cared about compile times when designing we always prioritized other values more. We never asked ourselves how this feature or implementation impacted compiler analysis time and there are several spots where something slightly different would have much faster compiler times, which people do care about. But had we spent time on that, we would have neglected other things and not been any more successful.
[1]: https://alexalejandre.com/interviews/interview-with-steve-kl...
This is important, because most often during development you want fast compilation times more than you want fast code.
But some of it is implementation problems.
I say this as a full-time rust developer btw.
IIRC for most codebases borrowck actually makes up a pretty small proportion of compilation time (e.g., see [0] for some admittedly rough estimates).
> but borrow checking could have been avoided with different lifetime rules.
I'm not sure you could entirely avoid borrow checking without a pretty significant change to what you're allowed to do with references.
[0]: https://kobzol.github.io/rust/rustc/2024/03/15/rustc-what-ta...
As usual, this begs the question of "compared to what"? "Fast" languages obviously don't have some magical ability to guarantee that every program written in them is Blazing Fast(tm); without further inspection one can come to any number of other equally plausible conclusions (e.g., the program is fast for what it does).
(And yet I’m perfectly happy running `cargo clean` periodically in exchange for all the Rust loveliness. Sure, I wish I didn’t need to. Sure, I hope it’ll get better. I can live with the temporary inconvenience though.
Also, I’m developing in a tight auto-build-on-commit loop so I have a gazillion builds.)
If your codebase is not some small project, its excruciating slow. Even if you try different linkers, and other compilers, nothing really make incremental compiles eat so much of your system. Even more so if you have multiple AI agents doing security and other checks.
Switched to Go for several months, and the difference was very noticeable. Until you started to get there also 50k+ files that are interlinked. And let us not talk about Go and Rust their issues with insane amount of debug/cache buildup.
Imaging if you have 4 to 6 agents running that, with each seeing the cache grow from 20, 30, 40 ... To the point that a 100/1000GB SSD grows to 800, 900GB usage. Often in barely a day.
Seen my NVME drive its lifespan drop from 98% to 91% in barely a few month time. I dread looking at it again lol
What was the solution? Going back to C ... Despite right now working on a 800k lines project, it compiles way faster the Go, and well, Rust will have pegged all 16 cores for a minute, for EACH agent trying to recompile on a small change.
Memory safety? Instead of checking at compile time, and wasting my time, this has simply been moved to AI agents checking, making tools, checking, at night. So it does not disturb my own work.
Its ironic, how both modern projects, end up being worse off. Best of all, the C project is way faster then the same project in Go and Rust. Yea, it was "fun" having AI transcompile them twice but the difference on actual large codebase, and not some micro benchmarks is not a joke. To the point that now all my projects have gone back to C...
And yea, i expect some fast downvotes by our Rust friends because saying something negative about Rust always gets people downvoted here. No offence but Rust being linked to LLM and the whole checker was a benefit before AI came around. But now you can offload a lot of safety checks to the backend/offhours, instead of paying for it with every compile.
But that said I do agree it is pretty fast these days. Significantly faster than C++ and people have tolerated that for decades.
(and what sibling comment mentioned)
Swift handles this through the equivalent of Rust's `dyn`. We could have a stable ABI that's based entirely on `dyn`. Such an ABI would have some limitations, since there are traits `dyn` can't represent (anything that's generic over something other than the type that implements the trait, which is quite common), though we're working on some of those.
Essentially, you wouldn't be able to have a `Vec<T>` in your ABI without either pinning down T or using something like `Vec<Box<dyn Trait>>`. Which is possible, but kind of awful.
We're still planning to ship a stable ABI at some point, but that gives a flavor for some of the kinds of problems we'd need to solve in order for that stable ABI to be useful.
(C++ typically handles generics by having types defined in header files, and those get compiled with the program consuming the library, which is effectively the same situation Rust is in. You could export symbols from a shared library for specific instantiation of a template, but people rarely do that.)
Similar to :
So the user must write the shims instead of rust magically build it. This also mean that ABI changes become visible, and changes to rust not mean worries about ABI.Forgive the naive question on something that's probably been discussed many times over, but could there be a middle ground when it comes to a stable ABI and generics? Something where the person building the library for dynamic linking chooses which explicit monomorphizations they'd like to provide for each public generic function (and type), and the compiler stamps out all combinations of those concrete instances? Could the way these are named and stamped out be standardized so that this could be treated as a stable ABI for non-generics?
It seems to me that it would at least cover distros: they could make a pass over all their Rust code and determine which monomorphizations are needed throughout the distro.
An actual stable native Rust ABI sounds like a forward compatibility nightmare.
If there's a CVE in tokio, the OS could theoretically publish a patched version of tokio and all apps that depend on that end up using the fixed code.
As it stands now, the OS needs to publish updated versions of all rust apps that depend on tokio.
Yes, in that it's primarily a linux thing as MS has gone the route of saving off basically all dlls for all their OSes for backwards compatibility (though they still backpatch).
No, in that other than Rust and Go (and maybe a few others that emit single binaries, zig?) this is how it works with OS distributed programming language packages. Python, ruby, java, perl, C#, the OS will for all of them control distribute and update the libs independent of the apps that use them.
Also, C/C++ still make up a huge percentage of all apps in pretty much any OS.
> Python, ruby, java, perl, C#, the OS will for all of them control distribute and update the libs independent of the apps that use them.
Those are all JIT'ed languages, so they're distributed in source or intermediate form, not as fixed-ABI-shared-libraries.
It's really just C where shared libs really work. Even C++ has wrinkles.
Uhmm... No? E.g.:
- Python has long strongly recommended virtual environments.
- Not to talk about JavaScript which of course manage things per project by default.
- I don't remember what was the state of things in .NET Framework, but in modern .NET NuGet packages are distributed as DLLs with your app.
I don't know other ecosystems well but I believe they aren't different.
Ummm... yes.
How software is maintained by an OS is different from how software is maintained by 3rd party developers.
- Python has long strongly recommended virtual environments.
Yes, if you are developing a private application. But if that application gets adopted by the OS then you can expect all it's dependencies to be sent to a place like `/usr/lib/python3/dist-packages`.
> Not to talk about JavaScript which of course manage things per project by default.
I didn't bring it up because it's one I'm not familiar with. I expect OS maintainers will do similar things with it that they do with python but I'm not 100% on that.
> I don't remember what was the state of things in .NET Framework, but in modern .NET NuGet packages are distributed as DLLs with your app.
And if your .net application ends up installed as an OS package you can expect those dlls to be stored in /usr/lib.
If you are doing C/C++, as a 3rd party app, you aren't putting the .so files or the .dll files in /usr/lib or C:\Windows\System32. You are storing them in the same directory as your application. But if the OS decides to distribute your app, you can expect your .so files to get put into /usr/lib and even System32 (very very rare for MS to do that, but it does happen when, for example, we are talking about drivers).
Edit: Re: node. Here's the debian guidelines for how dependencies ultimately get shredded and distributed. https://wiki.debian.org/Javascript/Nodejs/Manual?pow_referer...
> What is the advantage of doing so?
To which I responded
> Operating systems.
To which you said
> That's not how it works basically anywhere
I think we have reached the point in the thread where you concede that yes, there is somewhere where it's how it works and yes it does apply to languages that aren't C/C++.
So now you're shifting the goalposts and topic to
> almost nobody ships software via the OS today.
That was never something I was trying to debate. The topic was "why would you want ABI stability". And the answer is that if I wanted to rewrite coreutils in rust, then it'd be really useful to have synchronized crates with a stable ABI so I could potentially update those crates independent of the apps that depend on them.
Afaik, odin seems to get it right requiring libraries to be distributed source only.
Stable ABI dramatically improves the problem space there (without necessarily having anything to do with business model).
Hell, even if all exposed functions and types would need to be fully monomorphized at the interface, it would be a lot nicer to pass a `&'a [i64]` rather than a `const * int64_t` together with a `size_t n` and have to marshall the slice on both sides.
A stable Rust ABI would be nice for not just Rust, especially if they refine or extend (formally or de facto) the SysV ABI to optimize passing and returning of discriminants. That could then smooth the way for developing these features in C and C++, such as a primitive error-result type that saw some brief attention in both C and C++ WGs a couple of years ago. Doing it properly--absolute minimum cost, ABI stable, and cross-language--seemed to require too much orchestration across the ecosystem so enthusiasm and ambition seemed to peter out. The work required for a stable Rust ABI could provide the inertia to get that done.
https://github.com/joshtriplett/rfcs/blob/crabi-v1/text/3470...
It might make sense to have a subset Swift-style stable ABI, but that's a huge engineering effort, has lots of overhead and is also likely not worth it IMHO.
Any type (like in TypeScript; Rust doesn't have one) is a set of every possible value; a supertype of all types. Every expression regardless of type can be assigned to a variable of type any.
The opposite is the never type, which is an empty set; no value is of type never. Per set theory, an empty set is a subset of every set, which makes the never type a subtype of all types. An expression of type never can be assigned to every variable regardless of type.
If never type has no values, then how can an expression have never type? Easy: it must never evaluate. Infinite loops, unconditional panics/exceptions, process exit/abort, etc. Also, generics - you can have Vec<!> that's always empty, Result<T,!> that can never be an error, etc.
https://blog.rust-lang.org/2026/11/12/Rust-1.100.0/#never-ty...
Why is that? It seems like that makes min-publish-age much less effective.
When we added the MSRV aware resolver, we decided to have it not affect `cargo install` because you could get an old version and not notice (especially with how noisy cargo is) when the right answer might be to upgrade.
Somewhat similar for min-publish-age but also we had defined the parent table for these config fields to not affect install.
The change to `--locked` made us feel a little better with this non-ideal circumstance.
At least from a quick skim of the comments it seems there's still some stuff that needs to be worked on on the LLVM side of things as well.
Edit: This blog (https://trifectatech.org/blog/tail-calls-project-goal/) has a bit more info on current plans for stable tail call support
I just spent last few days fixing arena leaks (Bumpalo doesn't call drop) and had to use allocator-api2 for Vec::new_in which is now available in stable Rust.
https://github.com/bancek/rust-sass/pull/1
Wait for the timing of the next release. It will be a Christmas present.
when can we expect `Result::into_ok` and `Result::into_err` to land? the blog post includes the `infallible_unwrap` demo which is the exact functionality these two functions implement. i wonder why they didn't release these at the same time as never?
(As for why they weren't stabilized at the same time: because it's not worth adding more baggage to a major, difficult stabilization process; as that would just be more surface area that has to be reviewed and another source of potential issues or delays. Instead, the stabilization process for infallible_unwrap was started immediately after `!` was stabilized. That process includes a 2-week final comment period for community feedback which is why they landed in different releases.)
As this release seems to include breaking changes, shouldn't the major version number have been bumped, as per semver?
Has the Rust book(s) been updated to include the new APIs?
"We reserve the right to fix compiler bugs, patch safety holes, and change type inference in ways that may occasionally require new type annotations."
https://blog.rust-lang.org/2014/10/30/Stability/#what-are-th...
The breakage in question here falls under changes to type inference, which are allowed within reason when they're relatively minor, when steps have been taken to mitigate any breakage in the broader ecosystem, and when the compiler has emitted warnings regarding the imminent change during a grace period, all of which have been done here.
Two jokes that are expiring this month
[1]: https://www.youtube.com/watch?v=RFm9ClqlGuo
Is this good for AI vibecoding ?
Human intelligibility and coherence does not seem to matter any more, for current software development.
For comparison, C has had, say, 4 versions, and C++ 7 had versions (depending on how you count). But - Java has had 27 main versions and probably more than a 100 if you count minor versions/updates.
Last time I checked between a quarter and a third had a patch release, and those are closer to a signal of "a minor release had a problem". When analysing those my conclusion and the time was "for the most part they were needed because some niche feature or platform had a regression that wasn't caught by the suite and a handful of regressions causes by enabling a new feature or updating llvm".
Even Rust Editions are not a good point of comparison because they are also time based and only leveraged by things that would otherwise be breaking changes.
What you could use for direct comparison is accepted Rust RFCs against accepted C++ proposals papers or the equivalent for other languages. Or merged Pull/Merge Request counts for the different tool chains. But that's not perfect either (Rust only supports one language, while GCC several, but it has a package manager, which GCC doesn't).
Even ignoring K&R C there is C89, C99, C11, C17, C23 and C2y is in progress. I don't see any way to squint at that and count four.
Is that the raven that says Ni?
https://www.youtube.com/watch?v=bLiXjaPqSyY
By contrast, free software in general, and Rust very much in particular, has cultural norms that things should last a while, rather than immediately being thrown away. I think that's worth preserving.