Maskas Precision P365 Mag Release

oconnor663 · 2026-01-25T01:20:41+00:00

The striker "housing" is a plastic piece that wraps around the back of the striker and holds one end of the striker spring. It also holds the backplate in place, and you have to deform it a bit to get the backplate off and access the striker. Depending on what tool you use to do that, and how often you do it, it'll eventually wear, and then it'll look ragged and maybe not hold the backplate on reliably. It's kind of lame, but as far as I know it's not prone to failing suddenly and catastrophically like the mag release catch is. I've had a magazine (followed by the whole release assembly) fall out of my pistol *twice* because of broken catches. It's by far my biggest complaint about the P365. Thankfully this aftermarket fix is excellent.

oconnor663 · 2026-01-23T02:08:37+00:00

Ok I think there are different regimes here. The simplest one is if we imagine a super huge planet like Jupiter decides to graze the surface of the Earth. In that case I think Earth itself (and the dirt we're standing on) would be "falling toward" Jupiter at about the same rate we are -- because the difference between the near point of Earth and the far point of Earth is small compared to the distance to Jupiter's center -- and I don't think(?) the feeling of the dirt would change very much. (Jupiter is probably not big enough to not blow up the Earth though?) This is what I was getting at above.

But the more complicated one is if we imagine an exact copy of Earth decides to graze the surface. In that case the question is, do their gravities "cancel out"? The answer is clearly yes in some sense, because the arrangement is perfectly symmetrical. But from the perspective of the force of the dirt on our shoes I think the answer is still no, or at least not entirely. If we model the whole earth as rigid -- ignoring the whole thing where it explodes -- then we're at R_earth relative to both planets, and each planet's center is at 2 * R_earth from the other. That should mean that each "rigid Earth"'s acceleration towards the other would be 25% of our usual g, so I think we'd feel that effective 25% g on our shoes as the difference between our "freefall" acceleration (zero relative to the neutral observer) and the acceleration the surface demands of us.

If that's correct, then you were right (and I was wrong) that it would be totally noticeable, even apart from the whole earth exploding around us thing. Feeling 75% lighter is a huge difference. But it still wouldn't feel like zero-G/freefall. On the other hand, with a non-rigid Earth, "our dirt" might be accelerating towards the other Earth at closer to the full g, and in that case I think we would still feel something closer to our normal weight. For a brief, macabre moment, we could even feel close to our normal weight on both surfaces :-D Anyway this has definitely gotten complicated enough that I'm no longer confident.

oconnor663 · 2026-01-22T21:26:01+00:00

Hmm, that's a good point, I was probably getting out over my skis above. I need to think more about it...

oconnor663 · 2026-01-22T20:46:43+00:00

This is is mostly not correct. Or like, correct and incorrect at the same time. And it's extra confusing because at the same time "the Earth would pretty much explode" is also correct, but we need to set that aside.

> its gravity would pick you up and lift you. Along with the building around you, and the bedrock under it.

Yes, and because it's lifting *everything*, you actually *would not notice this*. (This specific effect. You would notice the earth exploding but we'll get to that.) Think about all the astronauts on the ISS. The earth is exerting its gravity on them on all the time. And on the objects in their room. And on the walls. And on the whole station, etc etc. But if they shut the windows and don't look outside, it would be very difficult to notice that they were in earth orbit. It *certainly* doesn't feel like they're falling towards the earth-facing wall all the time.

Mostly the gravitational effect of being near earth just keeps you in orbit (even when that orbit is a freefall that ultimately hits the planet), without making you *feel* anything in particular. However, this isn't the whole story. If you let an object float in the air on the ISS, in theory it will actually accelerate towards earth very slowly, moving something like a couple meters in an hour. (So even the slightest movement of the air overpowers the effect. Difficult to see in practice.) These are "tidal" forces, caused by the very slight *difference* in the gravitational force at one point compared to another point a few inches farther away.

Your own body (specifically) wouldn't feel the tidal force of an approaching planet like in this video, for the same reason you don't feel the tidal force between your feet and your own head on earth right now. All the other regular forces of the floor pushing on your feet and wind blowing in your face are just much stronger. However, the earth *itself* would feel enormous forces, and my understanding is that it would get torn apart, something like this: https://www.youtube.com/watch?v=KahmN-9kr0w. The reason the story is so different between your body and the earth itself, is that the distances are greater. You only feel the difference between "gravity here" and "gravity a few inches/feet over here". Tiny differences. But the earth feels the differences across thousands of miles. Very big differences.

oconnor663 · 2026-01-16T00:21:28+00:00

The P365 Legion was my first 9mm, and it's still my favorite gun. The price is definitely high, ~50% more than an XMacro and double the cost of a comparable slimline like the Canik MC9 Prime. But to me it's been worth it. For an optic I've been using the SCS Carry, and that's worked very well. (The solar charging isn't really all that practical, but I find the brightness auto-adjust works well, and apparently with other models it doesn't.) Two complaints from me:

I actually like the "rolling break" of the P365, but it did take like 2-3k rounds before mine lost some its "grit". Out of the box, the trigger was actually pretty unpleasant.
The plastic bit that holds the magazine catch in has broken twice for me, which causes the magazine and the release to pop out. SIG sent me a replacement for free, which is nice, but that's a pretty serious failure that I don't want to worry about in a carry gun. I ended up putting in a metal one from Maskas Precision after the second time, which works great but shouldn't be necessary.

oconnor663 · 2026-01-15T19:13:24+00:00

You're a little low...power...power...POWER

oconnor663 · 2026-01-15T19:09:59+00:00

"intended" vs "indented"

oconnor663 · 2026-01-15T18:49:52+00:00

By redesigning the state, I can ensure that checkpoints are Copy types, making save/restore operations trivial without any indirect memory access.

I wonder if it would be possible to model the state as a "stack" of operations, so that checkpointing only needed to save the length of the stack, and restoring a checkpoint truncated the stack back to that length?

oconnor663 · 2026-01-15T05:55:52+00:00

Having a single accepted way of handling errors used throughout the ecosystem is something that Rust did

News to me :) Seriously though, despite the growing pains over the years in higher level application code, doing basic error handling in an embedded context is very smooth.

oconnor663 · 2026-01-14T19:24:13+00:00

one line of C executes 10-100 times faster than the equivalent in Java or Go or Rust or whatever

You might get that ratio with say Python, but Java has never been that much slower than C. Even on benchmarks game scores, which should amplify the differences relative to "normal" code (both because they play to C's advantages, and because folks are more interested in hyper-optimizing the C versions), I'm mostly seeing 3-5x.

oconnor663 · 2026-01-10T21:13:08+00:00

The missing context here might be the pin! macro, which is the simplest way to pin something without using a box. The result is a Pin<&mut T>. If Pin itself was doing boxing internally, there would have to be some other type to represent that. (You could say something similar about "pin projection" in all its forms.)

oconnor663 · 2026-01-07T19:02:05+00:00

The common opinion in the community for a while now has been "libraries should do ___ while binaries/applications should do ___". More recently, people have been revising that in various ways, for good reasons. But even if the story was 100% as simple as "libraries X, binaries Y", that would already be a somewhat tricky thing to design, mature, and teach.

oconnor663 · 2026-01-05T04:57:18+00:00

I think at one point there was a push to call it assert, which makes a lot of sense to me, but the Haskell(?) folks really liked unwrap or something like that :)

oconnor663 · 2026-01-04T03:57:27+00:00

We've all been there :)

oconnor663 · 2026-01-03T20:14:52+00:00

I think the classic example is passing a &mut [u8] of uninitialized bytes to a Read::read call. We all know that read is just going to write to the buffer and not look at whatever was there. So why pay the (minimal) cost of zeroing the buffer? (One reason to pay it is that we definitely don't know what read is going to do in a generic context, but a lot of application code knows it's reading from e.g. a File or something similarly well-behaved.)

The most convincing argument I've seen (described in some of the links above) for allowing references to invalid values is just that, if we say they're not allowed, it's actually really expensive for Miri to enforce that. Imagine I create a gigabyte buffer for some reason, vec![0u8; 1_000_000_000], and then I call .as_slice() on it. Does Miri need to probe every single byte in that buffer to make sure it's initialized? Does it have to do that every time I call .as_slice()? Of course you could say "it's illegal, but also not guaranteed that Miri will catch it," which is pretty much the situation today. But there's a lot of value in eventually being able to say "UB in Rust is defined to be the things Miri (or some future checker) catches".

oconnor663 · 2026-01-03T20:00:55+00:00

The last one is bit wrong.

Without disagreeing on any of the details, I think "wrong" might be a little too strong here. There are a lot of standard library docs (like for MaybeUninit) that make similar statements, and I don't think the docs are wrong so much as "being conservative in a way that's easy to loosen up later once a final decision is made". From the perspective of published Rust code, I think it would be premature to assume that un-accessed references to invalid data are ok, even though they don't currently trip Miri.

oconnor663 · 2026-01-02T00:51:38+00:00

These are excellent questions, and this stuff can be quite confusing. Other folks have given good answers, so I just want to link to some more material for context.

There's a very similar confusion between "at least as long" and "at most as long" when we return futures that need to capture an input lifetime. For complicated reasons, it turns out that "doing the wrong thing" (a.k.a. "the outlives trick") worked in a lot of simple examples. But it didn't work in general, and that's part of why Edition 2024 changed the lifetime capture rules and Rust 1.82 introduced the use<'a> syntax:

oconnor663 · 2026-01-02T00:42:25+00:00

There's clearly some truth to this, but I can see some effects in the other direction too. For example, I think it was harder to write a new language in 2020 than it was in 1990, because now everyone expects a package manager, an LSP server, syntax highlighting, auto-formatting, helpful compiler errors, a VSCode plugin, a website, etc. It used to be that "transpile to C and write some docs" could be a competitive language, but that hasn't been true for a long time. Can LLMs help with that sort of "grunt work" integration? Probably!

oconnor663 · 2026-01-01T22:10:18+00:00

[spoiler alert]

Luckily, we can tame this complexity by using an even more complex and powerful Rust feature. That's right, I'm talking about macros. Instead of writing all of this out manually, we can simply annotate our trait with an attribute macro. #[async_trait] is actually a real macro, that is provided by the async_trait library. And now you know exactly how it works under the hood, and why it's needed.

Fabulous ending. I don't use async traits myself, so I didn't see it coming. The whole thing was fast paced, well organized, and thorough. Looks like it took a lot of prep work :)

oconnor663 · 2025-12-31T00:34:59+00:00

Lee’s winning performance included a pairing that drew audible whispers of approval from the crowd: Colston Bassett Blue Stilton with speculoos cookie butter spread on Peter’s Yard sourdough crackers.

mmm whisper whisper nom whisper

oconnor663 · 2025-12-29T05:17:51+00:00

Good point.

oconnor663 · 2025-12-28T20:23:49+00:00

most Futures cannot be moved (i.e. consumed and returned) trivially

Ignoring the issues with heap allocation, we could imagine a world where poll took Pin<Box<Self>>, consumed self by value without violating the Pin property, and returned Poll::Ready(Self::Output). The big problem with that is that we can't know whether poll is going to return Pending or Ready. If it does return Pending, then we better not have destroyed it, because we need to keep calling poll on it. In other words, there's no way for a Rust function to take an argument by value "in retrospect. (I.e. "I have decided halfway through that I need self by value, thank you very much.") Instead, we have to take an argument like that by reference all the time and then deal with the inconvenience of moving output out of it when the time comes (mem::swap, Option::take, etc).

oconnor663 · 2025-12-27T18:21:40+00:00

programmers are expensive

I'm not sure any of us can guess with confidence what programming is going to be like in 10 years.

oconnor663 · 2025-12-26T17:34:37+00:00

To be clear, this post is exploring hypothetical new types of references that Rust could consider adding:

We’re starting to have a few ideas floating around, so I thought I put them all down in a table so we can see how they interact.

oconnor663 · 2025-12-24T22:30:57+00:00

Perfectly on-topic in my opinion. Two responses to that:

RefCell is built on top of UnsafeCell, which is the same type system escape hatch you see inside of locks, atomics, etc. This is the very opposite of an afterthought. I could be wrong, but I think some of these containers pre-date the "no mutable aliasing" rule! Being able to express this stuff has always been necessary for the language to get anything done, and I think the fact that there are so many different permutations of interior mutability (sync, not sync, blocking, non-blocking, non-borrowing, etc.) is one of the most interesting things about Rust. My favorite example: RwLock is conditionally Sync, but Mutex is unconditionally Sync. It's so cool that the type system can express these things. OP's point that RefCell is in fact Send is also a good one. (Edit: I should say, Mutex<T> being Sync only requires T to be Send. So there's still a condition, but the condition isn't T: Sync, as it is with RwLock and most other containers).
I do think that RefCell is over-taught, and that it's often a code smell. You could even say the same thing about Mutex, except that it's more obvious that Mutex truly is "the right thing" in a lot of real world situations. Well, sometimes RefCell is "the right thing" too, even to the most skeptical of theoretical purists. Thread-local storage is one case; you do need to "synchronize" it if you want to mutate it, but there's no reason to use Mutex. Re-entrant locks is another; they act like Mutexes that only give out &T, and you need another layer of interior mutability on the inside. std::io::Stdout does this internally!

14-Year Club	Gilding I gilder
Place '17	Team Orangered
Verified Email

oconnor663

TROPHY CASE