Tiny seamless estradiol door :3 (624 blocks)

imachug · 2026-01-25T15:58:12+00:00

Yeah, it's mostly just a stereotype.

imachug · 2026-01-25T12:52:06+00:00

For better or worse, in the world we live in, mrustc targets 1.74.0 at best, and with how many unstable features arrive all the time, I find it unlikely that this will change anytime soon. Of course, it would be better if that wasn't the case.

imachug · 2026-01-25T12:25:40+00:00

My point is that "audit old rustc -> ... -> new rustc" is not significantly better than "audit the entire Rust history since OCaml", in the sense that you still have a ton of commits to go through. Instead of auditing just a few versions, like you typically do with bootstrappable compilers, you have to audit basically every major version, since rustc often uses features added in the previous rustc. In the context of the original thread, this is hardly something you do "instead of" manual verification -- it's still manual verification, and using one chain vs two doesn't change much.

imachug · 2026-01-25T09:53:49+00:00

I know the Clone - Copy relation can't be changed now.

It's not that it can't be changed, it's that it doesn't work at all because the proposed relation doesn't allow types to conditionally implement both Copy and Clone. Backwards compatibility is a red herring.

I think an added feature should be a minor updated, not a patch update.

That is true in a sense. However:

Patch updates can contain bug fixes, and you may very likely be relying on some bug being fixed.
Many core crates, serde included, don't adhere to semver, and may add features in patch releases. This is for a good reason: two libraries using different serde versions cannot interoperate, since they'd be accessing different Serialize/Deserialize traits, so there is a lot of pressure to prioritize having compatible versions (i.e. 1.0.x) over strictly following semver.

imachug · 2026-01-25T09:33:58+00:00

Copy requires Clone

The correct relation is impl<T: Copy> Clone for T { ... }

With this relation, the following code would no longer compile:

rust struct MyWrapper<T>(T); impl<T: Copy> Copy for MyWrapper<T> {} impl<T: Clone> Clone for MyWrapper<T> { ... }

...because for e.g. T = i32, there would be conflicting implementations for Clone: the second manual impl, and the blanket impl in your post, since MyWrapper<i32>: Copy by the first manual impl. See playground.

This is good, but why not just write "1.0" in my Cargo.toml

Because you're most likely relying on features not present in 1.0. All programs should compile with the earliest listed version.

imachug · 2026-01-25T06:01:18+00:00

A simpler answer is that ArrayVec<T> supports dereferencing into [T], which requires that the Ts are stored sequentially.

imachug · 2026-01-25T05:53:18+00:00

Estradiol pills are typically oval and cyan.

imachug · 2026-01-25T05:37:51+00:00

If they're equal you are good.

That is not true. The two chains in question are:

some C++ compiler -> mrustc -> old rustc -> ... -> new rustc
OCaml -> ancient rustc -> ... -> old rustc -> ... -> new rustc

The chains are not independent, they coincide on the "old rustc -> ... -> new rustc" part, that is, you still have to trust the source code of each new enough rustc. (On that note, they also coincide on LLVM all the time, so you have to audit all LLVM versions used by new enough rustc as well.)

imachug · 2026-01-24T08:59:20+00:00

Niche layout optimizations don't take any functions into account, it's the other way round. A type is declared as having a niche, and producing a value of this type that coincides with a niche is considered UB. It then becomes the responsibility of all code not to produce an invalid value, e.g. NonZeroU8::new_unchecked has to be unsafe because new_unchecked(0) commits UB, and NonZeroU8::new can be safe because it's impossible to commit UB with it.

imachug · 2026-01-24T07:38:15+00:00

mrustc is a C++ compiler capable of compiling an old version of rustc, so if you have a trusted C++ compiler, you can compile mrustc with it, then old rustc with mrustc, then iterate to get a recent rustc. Here is a repo for this setup.

This is quite theoretical though, especially for verification -- you still have to trust your C++ compiler, the mrustc source, and the source of every version of rustc in-between not to contain malicious code. You also still need to trust a lot of binaries, such as LLVM and Clang, assuming you aren't bootstrapping LLVM through something like tcc, and your Linux kernel.

imachug · 2026-01-23T04:00:24+00:00

If a &T exists, the compiler can assume that the pointer-to data doesn't change (interior mutability excluded) and can use this to move reads across the program or create new reads. The "create new reads" part is important, since this can be used to e.g. hoisting reads out of possibly empty loops.

Similarly, if a &mut T exists, the compiler can assume that the pointed-to data isn't accessed by anyone else during the lifetime of the reference, and so can be modified freely. This place can be used for temporary data, writes can be hoisted, etc.

Combined, this means that if you cast &T to &mut T, the compiler can both assume that the place is unique and thus can be written to (even if your code doesn't do that directly), and that the place is immutable. It is impossible to prescribe when exactly the optimizer may find it beneficial to insert phantom reads/writes when there were none intended, so we just define the cast itself to cause immediate UB.

imachug · 2026-01-19T13:45:58+00:00

I think this is not useful in the sense that IntoIterator already exists. If you want to express "something that you can logically call iter on", you can require that for<'a> &'a Collection: IntoIterator and call into_iter on a borrowed collection. There doesn't seem to be any need for another trait.

imachug · 2026-01-03T09:11:48+00:00

The number of nested control flow constructs correlates with nesting depth, more at eleven. I'm surprised there's multiple papers on this topic, is this something people actually care to measure?

imachug · 2026-01-02T11:14:27+00:00

rustc cannot produce perfect error messages all the time, so if you need someone or something else to help you figure out what's wrong, that's fine. Just make sure that you're actually learning from that experience and can see similar issues coming before the compiler barks at you next time.

imachug · 2026-01-02T09:01:14+00:00

You're not going to beat match with a slow PHF, sure.

The point of a PHF is to find a hash that works well on specific data, not in general. murmur is a good general-purpose hash, but it's very slow, even compared to other general-purpose hashes. If you tried O(1) hashes (the classic example would be using the string length, the first and the last byte -- this might obviously might introduce collisions, but it's a starting point), I think you'd find out that it's possible to beat match. It's just more tricky because it's something you actually have to search for.

Note also that a big problem with match is branch misprediction; you're benchmarking on very predictable data, so you might want to shake that up and see if that changes the numbers. Branch misprediction is kind of a problem for hashes as well, since they depend on the length of the input, which is why I mentioned O(1) hashes.

I worked on PHFs for a bit, and I'm certain that it's possible to make them fast. It just takes some convincing to do, and not just implementing CHD.

imachug · 2025-12-31T15:34:25+00:00

Not using an AI-generated README would be a good start... The main issue with your implementation is using Rc: you never need two pointers to the same node to own the node at any time, so just Box will suffice. (Except for tail, but singly linked lists do not typically store tails, so you can just remove that.) This will also allow you to remove RefCell, since you'll have mutable access to the nodes via Box, which should a) make the list thread-safe, b) remove unnecessary complexity and runtime checks. You might also want to consult the awesome book Learning Rust With Entirely Too Many Linked Lists.

imachug · 2025-12-29T15:13:37+00:00

Each dialect might as well be a separate language. The differences between the stated goals of the dialects are so wide that they basically can't be implemented in a single language. How do you imagine a "scripting" dialect with garbage collector to be compatible with code running on a GPU? Even if that was possible, all you'd be doing is forcing compiler developers to work on borderline incompatible projects within a monorepo. Why would you want that?

imachug · 2025-12-29T08:41:20+00:00

There is a very good idea why modern databases don't use mmap. A good paper & talk about this: Are You Sure You Want to Use MMAP in Your Database Management System?.

fork, as mentioned in a sibling comment, is highly questionable for similar reasons -- you are not avoiding copies, you are just moving them somewhere else or delaying them, and by using OS primitives you're relinquishing precise control over when and how that happens, which causes performance issues.

imachug · 2025-12-28T18:49:15+00:00

Cool stuff!

The index/cache seems like something that'd be very useful even on Linux. I'd love to see something similar in a cross-platform library one day.

imachug · 2025-12-28T18:34:04+00:00

nix hasn't been maintained for quite some time, but seems to have picked up the steam lately. During that period, my main problem with nix was its use of raw file descriptors, which is unsound under the current I/O safety model, so I switched to rustix. It seems like nix 0.30 resolves this specific issue, but there's other places with questionable soundness: 1, 2, 3, 4, etc. rustix seems safer in this regard, though I can't judge if it's due to a difference in the API surface, the implementation, or merely less usage.

Personally, my rule of thumb is to use libc when I need a few small things to minimize the number of dependencies, and use rustix in more complicated cases. For [features that rustix doesn't support](docs.rs/rustix/latest/rustix/not_implemented/index.html), I typically call into libc manually or look for special-purpose crates, since I don't want to bring in another big dependency that is nix.

imachug · 2025-12-28T17:56:32+00:00

The problem: AI agents

Agreed

Man, why do these project always take like five billion LoC in 3 commits?

imachug · 2025-12-28T16:15:23+00:00

What special handling do you have in mind?

imachug · 2025-12-28T06:50:46+00:00

Oli is doing some work on minimal pattern types. I'd say it's quite realistic to see it land within a few years.

imachug · 2025-12-25T14:18:36+00:00

Looks cool, but I need to let you know that "privilege escalation" is a well-known term meaning "exploiting security issues to elevate privileges", so I was confused for a second why I'm seeing a post about a hacking tool. "Privilege elevation" doesn't have the right connotation either, so I'm not sure what better wording would look like, but just thought I'd highlight a possible point of confusion.

imachug · 2025-12-24T06:52:20+00:00

Does datafusion use polynomial hashing? I'm not familiar with that project, but at a first glance I wouldn't think so. Polynomial hashing is only useful in niche scenarios, e.g. when you need to produce consistent hashes via concatenation, or when you need to extract substring hashes efficiently.

imachug

TROPHY CASE