I switched to Windows 10 as my main development machine few years ago after 25 years of continuously crashing Linux with an enormous pleasure. FreeBSD, well, there's nothing to crash there, that's the problem with it. Nothing. I didn't know almost anything about this Windows OS so I just started playing some sort of whac-a-mole game with it. I don't know what I did but right now I'm a happy (windows 11) user. I use Hyper-V with great success for driving my Linux and FreeBSD development. I like powershell and the dotnet platform and storage spaces and ntfs and many other. Good technologies, it feels good using. Windows terminal is almost OK. I stay away from crap like WSL and Code. I still use mutt for mail, not Office. And I can just play a game without any problems.

There's no Microsoft creep anywhere inside my daily flow. Actually, as of late, I feel more creep in Linux and FreeBSD than in Windows. Everything just works. Sometimes it tells me it has some updates for me. I let it install them and that's it. I'm back to my game, no weird stuff.

No account problem, no copilots, just my shit and myself and no Irene.

When I read about other users having trouble with it I get pretty sad. I wish I could say "do this and that" but I have no idea how my whac-a-mole game drove me to this happy situation. I must have (de)activated some (attack) vectors by mistake. But I whacamoled it head to end, from bios to wallpaper. I kept hitting and hitting, backuping, restoring, backuping,restoring, until i won. I'm on Windows 11 Pro in testing mode right now. Getting back to a linux desktop as my main? Nah, not right now. I have my i3wm running on a gpu partition inside hyper-v and sometimes I drop to it... I can't do all my arcane linux stuff in windows yet but i'm getting there. For now, I'm enjoying it. Been a while now. I just hope they don't notice me...

> I like powershell and the dotnet platform and [...] Windows terminal [...] There's no Microsoft creep anywhere inside my daily flow [...] I just hope they don't notice me...

Did you make sure to disable telemetry in .NET, and also separately in PowerShell, and also separately in Windows Terminal, and also of course in Windows itself? Otherwise your machine is sending your data to Microsoft by default.

Of course, even if you do disable all of those, there are likely to be other Microsoft programs with their own telemetry enabled by default. And even if you disable those, they could at any moment add more telemetry that you don't know about.

I am actually sending some optional telemetry data as well, consciously. Telemetry I don't care about or smells it's disabled. I was referring more to some other type of creeping. I don't mind telemetry for a good cause.

I agree and I have the evidence needed to back up your claims. Stable home life? checked. Parent-enforced discipline? checked. High parental expectations? checked. Through some involvement though, to some degree: we as parents always show real and positive interest on what our children are doing and learning without really interfering unless they explicitly ask for it, and I believe this helps dearly. I learned by doing, trying at first to get involved too much - proved to be a mistake which he corrected it by himself, jumping from an IT career to chemistry in notime and shortly hitting silver at international chemistry olympics. I never try to interfere anymore but just be there, always ready to talk about it and offer the emotional grounding they so much need. Kids will flourish. My elder is on his way to what seems to be a strong, well built medical career and my 6yr old oh boy, she's ready set.

I just finished tapping 381 times, disabling (hopefully most of?) Apple Intelligence incursions in my life on a machine I don't really use. Was wondering what will I do next. Oh, look. More crap. That will keep me busy for a while.

[laughs in Gates]

So happy to see Andrei Alexandrescu was included in this documentary. His book on modern C++ design was a mind opener at the time I read it. Maybe still is today. Anybody else read it?

His talks are some of my favorites; he's a great speaker. Very engaging and has a great sense of humor, which he uses to great effect.

It still amuses me, but Andrei's books were the "last straw" that pushed me away from C++ for many years. Great books, truly, and they helped cement the notion that I wanted to move on to a different language. (Go, at the time.)

I seriously hated the book, too. The title should have been "Cute template tricks to make you feel smart and increase compile time, when to use: approximately never". I think about two things from the book caught on, one of them how to deal with lists of template arguments pre C++11. It's kind of horrible, but was sometimes (more or less) necessary.

Yes, I feel the same way. I met Andrei once on a Meetup in Munich, basically telling him that he taught me how to think which led to a somewhat awkward conversion. Fun times nonetheless :-)

1. Find your hero

2. Meet your hero

3. Start an awkward conversation with your hero.

It always goes like this no matter what you try.

I read it recently. I liked a few of the chapters especially how policy classes fix some issues with OO design. I do recommend asking an AI chatbot to summarize each chapter and say what the modern equivalent is since some of the idioms have improved. I think one whole section was obsoleted through the use of std::variant and std::visit.

It also caused developers to produce template-heavy code that took minutes to compile. We used to joke that these developers were "bitten by Alexandrescu".

But it was indeed a nice book that really made stataic polymorphism popular. Before that, most books focused on building object hierarchies with virtual functions, etc.

Agreed, _Modern C++ Design_ is probably the programming book I've gotten the most out of in my career.

hmm, yes it's interesting but honestly - not much of the stuff is usable IRL

the only thing i was regularly using (Loki library) for was the assoc_vector

Of course, all his books are a must read.

funny, I think the same about rust.

(Safe) Rust is a lot better about the "Pit of Success" design than C++

There are fundamental technical choices to deliver that, but also ergonomic things like notice Rust's []::sort is a stable sort, whereas C++ std::sort is an unstable sort. If you don't know about sort stability in Rust what you wrote works and in C++ you get a nasty surprise.

C++ has std::sort() and std::stable_sort(). You should write what you mean, and you should know and understand your tools. Blaming the tool for your ignorance marks you as significantly less than an artisan.

Sort specifically is kind of a weird example, but C++ is full of awful naming.

std::map (which is not a hash map, which is what most people would expect), std::move (which doesn't move), std::vector (which is not a vector), and std::vector<bool> (which is not even a std::vector).

> Sure, both languages offer both generic comparison sorts†. But the defaults matter and as always in C++ the defaults are wrong, here it's reflected in naming.

Why, exactly, is the c++ std::sort "wrong"? There are tradeoffs both ways. You happen to prefer stable sorting to speed, but that is a preference not an objective fact.

> Why, exactly, is the c++ std::sort "wrong"?

It's silently an unstable sort, which is surprising, and then to add insult to injury it's also slower. Yeah, I know, the C++ unstable sort is so slow it's slower than Rust's stable sort.

YMMV for input types, sizes etc but generally that's what the numbers look like and though it's not universal it's actually quite common. "I bet the C++ is faster" is the wrong instinct, sometimes by a large margin.

And stable sorting typically allocates large amounts of memory, which is also an unpleasant surprise.

I prefer the C++ naming convention, because it matches my expectations. When I studied CS, quicksort was considered the default sorting algorithm, and stable sorting was therefore a special case.

My pet peeve is that standard library sorting algorithms are still mostly single-threaded. Multicore CPUs have been the norm for ~20 years, but standard libraries still don't offer reasonable algorithms for sorting large arrays.

So C++ is "wrong" because it doesn't work like something that came along 40 years later and you used first?

The problem does not appear to be in C++.

No? One of the giveaways of how unserious such responses are is that I spent many years getting paid to write C. The home where I'm writing this was bought† with money made writing C years ago. Rust wasn't even a twinkle in Graydon's eye when I started that job, let alone when I first wrote C last century.

The choice to provide the unstable sort and then add a stable sort as an afterthought smells of the New Jersey approach to me. It was easier to do this, and too bad for the users, they weren't the priority.

It's the wrong choice because if you don't know about sort stability this outcome is surprising, so this means that although a beginner probably thinks they know what "sorting" means they actually mustn't use the sorting APIs in such a language until they've learned extra material.

† For cash, I don't like to owe people money, including having a mortgage

It's not so simple that you can just declare what is surprising. Surprise depends on context, and not everyone will have the same context as you. You say you would expect the term 'sort' to mean a stable sort, and I would expect it to always mean in-place sorting, others may expect it to use the absolute fastest way to get something sorted... Different users will have different priorities and therefore expectations.

Sort stability does not matter when the sorting key is the only thing in your data being sorted. E.g. When I sort my M&Ms by color, I never keep them in the same order, because it doesn't matter. A red M&M is a red M&M. Nobody expects their red M&Ms to remain in the same order after sorting. I do tend to expect my M&M sorting to happen in-place. I expect to not need to provide additional candy holding bowls to later clean up that were used for temporary storage while my M&Ms were getting sorted. But I'll optionally grab additional bowls when I'm in a time crunch it if it speeds things up...

Now, if we're sorting all the cars on a parking lot by color, it may be more important to keep all the red cars in the same order where they started, for example if they were previously already sorted by brand, it /can/ be useful if that is preserved. But it's not guaranteed to be important or useful. Maybe the rich owner just want to torch all their red cars all together. I typically won't have access to additional temporary parking lots only used during sorting, or maybe the owner is coming with a flame thrower at 1PM and it has to be done as fast as possible whatever the cost. There is a tradeoff, rent additional parking lots during sorting, or take more time and do in-place stable sorting, or jumble up the car brands.

So what I want is control. That's all. Whether or not the ambiguous term 'sort' is stable or unstable, or in-place or not is just semantics. The only way to get clarity is to either use prior agreement, or to not use ambiguous names. Maybe a language should ban 'sort', and only allow 'foo_sort_bar' names with stability of memory usage postfixes or prefixes to 'inform' the developer. Neither choice is ideal and will satisfy everyone. It's like being a DJ at a high school party.

I'm not saying that the STL is great in practice, since it appears to optimize for usage flexibility with defined algorithmic and memory complexity at the big-O level, and mostly disregards actual real-life metrics. Arguing, however, that a language or library is better because an objectively ambiguous choice was made differently than your expectations is like arguing for fundamental superiority of either endianness over the other.

> It's not so simple that you can just declare what is surprising.

On the contrary, of course I can tell you that I was surprised and I'm far from alone. The fact you immediately grasped for "real world" comparisons ought to tell you that you're not thinking about this correctly because these are software sorts and so have very different affordances than the real world.

The claim that you wanted control doesn't make sense in the context of C++. There are in place stable sorts - the bubble sort you may have seen in class years ago is one, but C++ doesn't promise one in its standard library. However it does provide an unstable sort, which it just names "sort" and that's what I'm pointing at as a problem.

As to the "absolute fastest" you're in the wrong place if you've used a generic comparison sort expecting the "absolute fastest". For the machine integers it's usually not even the correct category of sort for "absolute fastest". But the C++ standard library is the wrong place to look even if you did need a generic comparison sort, because so much crap C++ exists and maintainers are scared to change anything for fear of what may happen.

Did you know libc++ didn't even have a guaranteed O(N log N) sort until the Joe Biden presidency? The introsort paper was written last century and the C++ standard itself did finally incorporate this basic requirement in 2011, but it took another decade for the Clang team to fix this.

Ok, I'll keep it short: I'm far from alone being surprised that a sort allocates temporary memory...

C++ is used by a lot of different people with a lot of different background, and... expectations...

My point is that "sort" is ambiguous and having expectations on ambiguity and arguing that a certain one is better is like arguing little endian being better or worse than bit endian.

> Ok, I'll keep it short: I'm far from alone being surprised that a sort allocates temporary memory...

In a sense I'm sure this is true. C++ programmers routinely report being astonished about all sorts of properties of the language they have previously insisted they know well and who could blame them (for the former, at least).

Again, this is not symmetrical. LE and BE are symmetrical, if you have to pick one there isn't a "safe default" that isn't surprising to people who expected the other one†. In contrast sort stability isn't like that, all stable sorts also meet the criteria for an unstable sort. Likewise all the in-place sorts meet the criteria for an allocating sort.

C++ chooses to offer an unstable sort just named "sort". It doesn't offer a stable in place sort at all, but it does offer a stable allocating sort and names that stable_sort

† But what you can do is where it matters you explicitly offer the LE and BE options and silently whichever is native on your target is fast. Users can write whichever they meant and their program works rather than "Oops, by default on this platform it's the opposite byte order, there's a special conversion function to run". Needless to say C++ doesn't do this either.

You are failing to make an argument for why stable sorting is objectively the correct choice. Just because something doesn't match your expectations doesn't make it wrong.

There isn't a symmetry here. If you know about sort stability then you can seek out the unstable sort if you know that works for your purpose, if you do not know about sort stability then the unstable sort's behaviour would be astonishing, so stability by default is the right choice.

I don't know Calbee snacks. We grew up with different chemicals in this area.

BUT. I must say, the packaging looks so much better in black and white.

It makes me think it's an honest product, whatever that means. Good feeling. Put your name on it, black on white. Sell it.

that’s not an error