ia0:

All crates can cause undefined behavior, even if they use #![forbid(unsafe_code)].

Let's consider a crate author that doesn't want to deal with undefined behavior. They write a crate foo which uses only safe code and forbids unsafe code. Another crate author writes a crate bar which depends on foo. They write unsafe code which relies on the safety guarantees of foo (which is…

I recently published matten, a small Rust library for working with multidimensional arrays. This is the first of four short posts introducing it. This one is about why it exists.

Rust is a great language for numerical and data-oriented work. But starting that work — just getting to the point where you have a matrix and can add two of them together — takes more effort than it probably should at…

My core point was supposed to be that, in my experience, overlapping impls aren't necessary and that the hashtable problem may be a bad and/or overly strict test.

(The rest of this post is going somewhat off-topic.)

dlight:

This works if only one crate can do this (the binary crate?)

But if two crates do this, then those impls can overlap.

Absolutely. Only one crate in the crate graph…

My core point was supposed to be that, in my experience, overlapping impls aren't necessary and that the hashtable problem may be a bad and/or overly strict test.

(The rest of this post is going somewhat off-topic.)

dlight:

This works if only one crate can do this (the binary crate?)

But if two crates do this, then those impls can overlap.

Absolutely. Only one crate in the crate graph…

benschulz:

I'd love to be able to declare "I depend on the two unrelated crates miniserde and jiff" in my Cargo.toml . By unrelated I mean that miniserde does not depend on jiff nor does jiff depend on miniserde. Having ruled that out, and assuming that neither adds any blanket impls or a dependency on the other , I ought to be able to define impls of miniserde::Serialize for…

flutpak — major update (0.8.0): Rust/Cargo support, flatpak-flutter-compatible registry, no local SDK required

Since the original post (and the first successful Flathub CI run) a lot has landed. I want to give a proper update, especially on two points raised in the thread.

A note on the proof-of-concept submission

The previous update in this thread reported that PR #8889 passed the…

flutpak — major update (0.8.0): Rust/Cargo support, flatpak-flutter-compatible registry, no local SDK required

Since the original post (and the first successful Flathub CI run) a lot has landed. I want to give a proper update, especially on two points raised in the thread.

A note on the proof-of-concept submission

The previous update in this thread reported that PR #8889 passed the…

flutpak — major update (0.8.0): Rust/Cargo support, flatpak-flutter-compatible registry, no local SDK required

Since the original post (and the first successful Flathub CI run) a lot has landed. I want to give a proper update, especially on two points raised in the thread.

A note on the proof-of-concept submission

The previous update in this thread reported that PR #8889 passed the…

flutpak — major update (0.8.0): Rust/Cargo support, flatpak-flutter-compatible registry, no local SDK required

Since the original post (and the first successful Flathub CI run) a lot has landed. I want to give a proper update, especially on two points raised in the thread.

A note on the proof-of-concept submission

The previous update in this thread reported that PR #8889 passed the…

Servo 0.1.0 represents Servo’s biggest month ever, with a record 530 commits and our first ever release on crates.io! For security fixes, see § Security.

With this release Servo becomes more accessible, thanks to tab navigation (@mrobinson, @Loirooriol, #42952, #43019, #43058, #43246, #43267, #43067), keyboard navigation with Alt+Shift and the accesskey attribute (@mrobinson,…

Servo 0.0.5 is here, bringing with it lots of improvements in web platform features. Some highlights:

• < link rel=preload> (@TimvdLippe, @jdm, #40059)
• < style blocking> and < link blocking> (@TimvdLippe, #42096)
• < img align> (@mrobinson, #42220)
• < select disabled> (@simonwuelker, #42036)
• OGG files can now be played in < audio> (@jdm, #41789)
  *…

• Feature Name: (fill me in with a unique ident, zst-scoped-safe-fncast)
• Start Date: (fill me in with today's date, 2026-05-22)
• RFC PR: rust-lang/rfcs#0000
• Rust Issue: rust-lang/rust#0000

Summary

The cast of a target-feature enabled function into a safe, callable rust-ABI function necessarily requires an intermediate unsafe cast step. Make this step safe in scopes where a…

Today, the Servo team has released new versions of the servoshell binaries for all our supported platforms, tagged v0.0.1. These binaries are essentially the same nightly builds that were already available from the download page with additional manual testing, now tagging them explicitly as releases for future reference.

We plan to publish such a tagged release every month. For now, we are…

Today the Servo team has released v0.1.0 of the servo crate. This is our first crates.io release of the servo crate that allows Servo to be used as a library.

We currently do not have any plans of publishing our demo browser servoshell to crates.io. In the 5 releases since our initial GitHub release in October 2025, our release process has matured, with the main “bottleneck” now being the…

Somewhat related: crates.io: Rust Package Registry

I've never realized how absolutely barebone crates.io was.

jmillikin:

If I were to publish a package https://crates,io/crates/jmillikin-serde-json then the only obvious choice for the name that's exposed to rustc is jmillikin_serde_json. If I were to set lib.name to serde_json then that would be confusing -- it's different from what users expect, and there's no way to predict it. There's no mechanical transformation that can be applied to…

I really don't think we should or want to extend that into a dependency system, where a domain expiry could easily lead to RCE on a dev machine unless cases like these are really solved.

The original proposal would not enable this -- permission to upload new versions of existing crates is controlled by crates.io package ownership, not domain registration.

Further, if people would be OK with…

jmillikin:

The main objection is that people often use their real-life name for a username, and sometimes they want to change their names.

Wouldn't this apply to domains as well?

jmillikin:

A cheap .com is like $15 a year,

jmillikin:

I'm not dismissing a monetary cost as "small", but when compared to the other costs involved in publishing Rust packages on crates.io it seems strange…

mathstuf:

How would this work with crate ownership? (This may very well be addressed in epage's prior collection of this topic.) If I add another developer as a maintainer (uploader) of the package, do I need to somehow give access to my domain?What if I later want to no longer maintainer? Do I have to transfer domain ownership too? What if I still have crates I'm continuing to maintain? Or do…

jmillikin:

I'm not sure I follow, sorry, though that might be because I'm used to the left-to-right order used by other package managers, Rust mod hierarchy, XML namespaces, and so on. Every sort of scoping/namespacing system I know of is big-endian.

If you were looking at a group of dependencies, wouldn't you normally want them ordered as (namespace, name) instead of `(name,…

Why does this require namespaces vs. just expanding the character set allowed in package names?

If you just expand the character set without introducing some form of access control then individual users could publish with names like google.com/protobuf or rust-lang.org/libc.

This would violate the crates.io team's requirement that the name of a crate should not mislead regarding which…

yaksher:

Finally, I want to remark that I think you're trying to solve 3 loosely related problems:

To clarify, I'm trying to solve the second one (multiple packages with the same crate name but different package names). The other two use cases (grouping by umbrella project, brand reputation) just sorta come along for the ride as a result of the imposed requirements.

I would personally be…

jmillikin:

• One prefix per account (GitHub model)
  • One less obvious drawback to this is that a user would only be able to have a single package with any given crate name. It's not obvious that someone would want to be the owner of multiple yaml crates, but maybe they've got some personal circumstances that have lead them to such a situation.
• One prefix per crate, which is…

I thought of another way to explain it, by analogy with lib.name.

If you have a package at https://crates,io/crates/some-example-lib, the name that will be exposed to rustc is expected to be some_example_lib. The transformation from crates.io package name to rustc library name is simple to understand and can be implemented mechanically.

The lib.name field can be overridden with an…

jmillikin:

The package jmillikin.github.io/json contains the crate json, whereas the package jmillikin_json contains the crate jmillikin_json.

As already mentioned in this thread you can make the package jmillikin_json contain the crate json. It can be a bit confusing to users, but there's no technical difference between the two. You could get the exact same result by allowing the…

jmillikin:

I understand that the current lack of namespaces means that there can be only one json crate on crates.io. This thread is an attempt to convince the team to relax that constraint.

I think you'll have a hard time convincing people if that's your stance. Even with namespaces there can only be one json, that won't change. You can have jmillikin.github.io/json, but that's not…

While it is often true that the simply named crate is well implemented and suffices for most purposes, that's not always true.

For instance, as noted earlier in this thread there are numerous crates for dealing with http servers, and the crate named http is not necessarily the best for it.

When I need a crate for something, I search for it on crates.io and look at the top couple results to…

Certain packages may have nicer names, but that doesn't mean that they're the best package implementing that thing for your given use case.

It ... kinda does, though? The json crate might not necessarily work for everything I want to do with JSON (e.g. it doesn't provide an event-based parser), but if you go to https://crates.io/search?q=json it's the top spot (screenshot) and seems to be…

I don't see why your own implementation would count as the fuse . Isn't the reference implementation by Linux kernel folks more deserving of being the fuse ? If your implementation isn't a fork or a drop-in replacement for the reference FUSE implementation, why would it be the fuse and not your take on it, like jmillikin_fuse ? (or something like jmfuse )

I'm having trouble parsing…

jmillikin:

My package is an implementation of FUSE, and therefore it is called fuse. If I had forked the FUSE protocol into my own personal variant, then I would publish the library as jmillikin_fuse.

This is a very strict and specific interpretation of the crate name.

I don't see why your own implementation would count as the fuse. Isn't the reference implementation by Linux kernel…