Littlest stars (red dwarfs) live longer. A lot longer. A fuck-ton longer. So long in fact that we have never seen one that has used up all of its nuclear fuel. Not even close.

You honestly believe that existing C++ code out in the wild today would most likely pass a borrow checker with just some extra ownership info tacked on?

Nope. Nope. LOL! Nope.

If you can get away with just a major refactor, you'd be lucky. All other cases, the entire architecture would likely need to be vetted, resulting effectively in a rewrite. The only things preserved would be auxiliary modules and perhaps the project name.

That might work if Firefox still had 30% market share. Truth be damned, folks will simply say the site works in Chrome, so Firefox will be blamed. And even if they recognize that Firefox isn't at fault, it's easier to tell people to use Chrome than to get all those broken web sites to patch.

Rock. Hard place. Pragmatism.

On a related note, "feo" means ugly (and other negative connotations) in Spanish. It would not go unnoticed.

Mostly desert? Don't know where you got that from. The biggest desert in India, the Thar Desert, is less than 5% of the total land area of India. Monsoons regularly douse the majority of the country with some parts of the country receiving the highest rates of rainfall in the entire world.

What you've been describing, I call "lifelong geek syndrome". You've known it for so long, you've forgotten what it's like not to know it. You've invested so much time learning the specific tools of your trade, you lean toward disdain for those reluctant to follow the same path.

I started learning C three decades ago. C++ about 7 or 8 years later. And frankly, compared to today they were a mess. Still are a mess, but Stockholm Syndrome and experience make it somewhat manageable. Most of computing is like this. You and I have spent a great deal of time learning how to avoid use after free, to avoid memory leaks, adopted unique_ptr instead of bare pointers whenever possible, honing our craft, debugging obscure race conditions in production, finding tools to shore up the gaping holes in C and C++'s memory safety model, etc.

But to claim that everyone of any experience level should know to adopt, configure, and use the baroque array of disparate tools to help C and C++ be less of a collective dumpster fire is nonsense. If software engineers built bridges and airplanes, death would abound.

That's like a great writer claiming that English is an elegant language with no possibility of substantial improvement.

There are several sorely missed features in C++ that everyone agrees would be great ideas and simply things were it not for breaking ABI compatibility and 30+ years of legacy.

Rust is not perfect (and not even necessarily the best replacement for C when looking at alternatives like Zig), but it is by far the closest I have seen to a C++ with unique_ptr/shared_ptr effectively being mandatory and enforced by the compiler, sane and consistent module support, typesafe macros (c'mon, the preprocessor is a dumpster fire all on its own), a simpler template metaprogramming model, comprehensive dependency management, forbidding diamond inheritance patterns, cleaner functional programming options, etc.

You are an expert in the C and C++ tool domain, but that's not an industry goal. C and C++ are not and have never been the goal. No language is. The goal is getting good software released, fewer security problems, and faster release times. That's it.

If someone starting out their career today by following your advice that C, C++, a pile of different add-on tools, and years of experience learning to avoid 30-40 years of legacy cruft, they are doing themselves and the industry a gross disservice.

Go should displace Java to improve the state of things precisely because it doesn't consume RAM like it's going out of style and is a much better fit for smaller, composable functions in the cloud. Rust should replace C++ for new systems level development whenever possible precisely because most folks with less than 30-40 years of experience in the industry will produce safer, more secure, and more maintainable code by virtue of learning from and adapting the lessons of those 30-40 years of mistakes.

But by all means, try to defend #define, #ifndef, and null-terminated character strings as some sort of natural virtue or how things like the iostream were paragons of modern design rather than poorly conceived and byzantine minefields.

Most major relational databases today have an indexable JSON data type. You don't need a thousand tables with hundreds of foreign keys.

MongoDB is a one-hit wonder whose fifteen minutes were up quite a while ago. (I also find it difficult to forgive MongoDB for the numerous data integrity bugs they've had over the years.)

There's definitely use cases for NoSQL. That doesn't necessarily mean that all NoSQL offerings are worthwhile. I for one like DynamoDB and Redis for certain specific use cases. MongoDB on the other hand can kick rocks. I'd rather use Postgres with indexed jsonb columns over MongoDB every day of the week and twice on Sundays.

Because one day, you're gonna need something beyond JSON, and the MongoDB dev will not be happy on that day. They'll make excuses, wrap their data in makeshift JSON, tie their code in spaghetti knots, and deny to their last breath that anything has indeed gone horribly wrong.

And all because they simply refused to properly learn SQL and use the various highly tuned engines that implement it.

You say that like relational and transactional (aka OLTP) are synonymous. They are not.

Redshift: column-oriented analytic RELATIONAL database (OLAP)

TimescaleDB: time series RELATIONAL database

YugabyteDB: distributed multi-master with horizontal scaling

And those are just some of the PostgreSQL-compatible offerings, hardly an exhaustive list of all SQL-compatible offerings out there from multiple vendors.

Abortion makes up ~3% of PP's services, it is not in any way an outsized profit center for PP, and no government funding goes toward abortion since their budget is specifically bifurcated to avoid it by federal law.

But none of the right wing news sources you follow reported those inconvenient facts, have they? Nor do they discuss where the other 97% of womens care will come from if PP is shut down. It's partisan political theater, and you fell for it.

So by late 2023, they'll release a chip matching the one released in early 2021. Meanwhile, Apple will have released the M3.

It's 280 characters now and was originally 140 characters, because that was the maximum number of characters allowed over a single SMS message.

Cloud vendors absolutely (and even pathologically) work toward optimizing their compute capacity to cost ratio with regard to hardware procurement and electricity/cooling requirements.

Any costs incurred by the provider are passed down to you. They all charge by compute capacity. (Also storage, but that's a different set of metrics.) If your program can do the task with smaller CPU capacity and less RAM, it costs less. Period.

AWS Lambda is charged by the number of requests (static between implementations) and milliseconds of duration to complete the task (absolutely dependent on differences between implementations). If your implementation in Python takes 30ms and your implementation in Rust takes 2ms, your bill will be substantially lower after ten million invocations. (Which also makes the curve more shallow, pushing strongly to the right in the graph where costs intersect between the cost curves of Lambda, containers, EC2 virtual instances, and dedicated hardware.)

You want an energy dashboard? Just check your monthly cloud bill. It's close enough that a dedicated energy graph would appear redundant.

Yes, the act of civil disobedience can be useful to highlight flaws in process or organization. I just can't believe the folks that think the harm mitigation put forth by GitHub and npm were unreasonable and infringing on the dev's "rights".

Both could be good things. The first is arguable, but the second is akin to self defense and unambiguously good. If the code change were actually malicious, I sure as hell want anyone to put the brakes on as soon as it's detected on their networks/storage devices.

Can you imagine if someone in ANY other field of engineering decided to willfully sabotage a part and folks got upset because he was giving the parts out for free? I'm actually all for civil disobedience when something is broken, but to question harm mitigation by folks who detected the harm because the guy had a "right" to ship broken/faulty parts?

Like making friction brakes on elevators and saying, "I just made the current batch not automatically arrest on free fall to prove a point."

This right here is why a lot of folks should not be called "software engineers". Far too many of you have no idea what "ethics" in the field entail.