Starting in the CompuServe era, and ending in about 2001, I was a voluntary member of the MVPs for Windows programming. You would get swag, including a full MSDN subscription. My reason for joining this and for otherwise posting hopefully helpfully on forums was to lower the barrier to Windows programming.

I was idle vis-à-vis this by about 1999, and was excluded from the benefits as a result.

Then I posted on several threads within rec.autos.bmw and I got an extra year or two of benefits.

I have been happy with the serendipity of YouTube’s algorithm generally. I followed an external link to a YouTube video about an exotic piano, and played a few related videos afterwards. These were videos about other unusual musical instruments, such as very high-pitched and very low-pitched wind instruments. And somehow that was part of a process leading to Japanese metal bands.

Dopamine-driven behavior in ourselves is certainly to be watched for.

That's weird. They keep showing me rage-bait videos with like 100 views. I'd much prefer pianos and Japanese metal bands.

I DO miss the discoverability. I really do. But my self control for watching shorts ends up being incredibly self sabotaging. I truly wish I could permanently disable shorts in some way. I wish I could use my DNS to block shorts, but alas they're not distinct.

I worked with CFG80211/MAC80211 on an old Linux kernel years ago. I don’t think time of day is in any packet.

As an aside, because it would not be germane to automotive safety…

In the Coast Guard Auxiliary “Sailing and Seamanship” class that I attended, targeting would-be sailboat skippers, we were told the USS Ranger nuclear-powered aircraft carrier had the right-of-way.

In Encinitas, California, that sign would have no more than 20 MPH. In adjacent Carlsbad, I believe 25 is normal.

I vividly recall a shot within a commercial, in which a driver was shown in slow motion, chucking his coffee into the passenger foot well in order to have two hands on the wheel for an emergency. I don’t remember what was about to happen to the car or the world around it. I’m pretty sure that a collision occurred.

40 and over is a “protected group” in US employment law. 30 year old people are not protected.

Really? The US only protects age discrimination of some ages not all?

Only older people are deserving of equal protection, because they reliably vote. Young people get screwed over for everything else.

If the right type of mate uses those traits to find their type of mate there’s no downside.

To me it implies abstraction such as a constructor, but with no overhead compared to the same steps done in some other way.

Sure, but languages and the problems we solve with them are both multifaceted, so simply pointing to one tool and saying "this is better than the one you have in your toolbox" is fine, but the plural in "zero cost abstractions" kind of implies that most or all the tools are at parity or better.

It sounds like you're saying that you consider seeing this single instance of someone writing a library with a costly abstraction to be indicative of the entire language ecosystem not fitting the paradigm. This is kind of hard to take seriously; it's not like C++ doesn't have some costly abstractions as well way more embedded into the language itself (e.g. exceptions).

> someone writing a library with a costly abstraction

That's not what happened here.

> it's not like C++ doesn't have some costly abstractions

This is simultaneously both completely orthogonal to my observation that the Rust FFI is borked, and a great example of a problem that wouldn't happen in C++, because in C++ you could completely ignore the costly abstractions if necessary.

> That's not what happened here.

Yes, it's what happened here. The article is about debugging the author's own abstraction types that had some incorrect assumptions.

You do not need these wrapper types to call C functions. If the author had removed the complex extractions and called the extern "C" function directly (as is standard in Rust) there would not be the additional overhead.

> > someone writing a library with a costly abstraction

> That's not what happened here.

Yes it is. Where do you think the `FFISafe` type that they used came from? It's not anything inherent to how Rust does FFI; it's a type someone wrote in an attempt to try to provide an abstraction, and that abstraction happened to have a cost. There's absolutely no reason anyone has to use it in order to do FFI in Rust.

The extra time was being taken up in the identical assembly language function.

Fixing it took wizardry.

The time was taken by the code around the assembly language. It was an abstraction someone wrote in a way that happened not to be efficient. The ability of someone to write a costly abstraction doesn't take away from Rust any more than the possibility of doing that in C++ would from whether C++ has them.

It was caused by the code around it, but the actual CPU cycles stalled out in the assembly language, making it much harder to find the problem.

Is how I understood the post.

Anyway there's noting wrong with rust FFI. The overhead was because this function wanted to support two options and didn't implement that in the best way.

Body modification?