Seems like you didn't do any basic research or read the article. There have been continuous optimizations in Ruby. Version 3.2 is quite fast and even has a JIT. Most of the rumors and misapprehensions of bad performance date to 1.9 era.

For my money, and I've been programming since the 90s and software engineering professionally since 2008, Ruby on Rails is a great solution for a company to build a form-driven web application. In many cases the performance is quite good and you can get something built that works well with a short development time. The community can't be beat and the libraries have a lot of rich functionality. Most of the myths and canards about Ruby and Rails are no longer true, if they even ever were. The main problem with Ruby is that it doesn't have a Google or a Microsoft behind it, although Github uses tons of Ruby. As does Shopify. As does Apple.

Indeed, C++ can generate a move constructor that calls the move/copy constructors of your component types but that doesn't change the fact that a C++ "move" is fundamentally different from a "rust" move.

A rust "move" is an operation that is intrinsic to the language, the content of the memory representing the object is transferred and the old location is treated as no longer containing a valid object.

This has a number of implications.

1. Since the operation is intrinsic to the language and does not involve calling any library code the caller can "move" the object into a register and the callee can "move" it back out. That means that if the type is sufficiently small, it can be passed in registers rather than being forced to live on the stack.
2. It's generally safe to assume that a move is "cheap"
3. "smart pointers" don't need to have a null state.
4. Moves cannot panic (the rust equivilent of throwing an exception)

I'd disagree strongly with that, the restrictions on safe rust to make analysis tractable are far stricter than the restrictions most C++ codebases self-impose. Indeed i would say this is one of the issues rust has gaining traction.

Indeed, and that line of thinking works fine as long as your variables are agreegates of dumb values and unmanaged pointers. Indeed for "trivially copyable" types even rust is copy by default.

Once you introduced managed pointers though you have a problem. If you make a copy of a type containing managed pointers and then run the destructor on both copies then you have a double free bug. Similarly if you overwrite the contents of such a type without freeing the old content first you have a memory leak.

And it is for such "Managed" types that rust and C++ differ. In C++ a simple assignment can turn into a call to an arbitarily complex copy constructor. In the case of collection types containing a managed type that copy constructor will in turn call the copy constructors for all the types contained with in.

C++11 introduced the concept of "moves" but asside from not being the default, they are also required to leave the type in a "valid but otherwise unspecified" state. This means that each type needs it's own custom move constructor which practically means the types cannot be passed in registers but must be passed on the stack. It also practically means that your smart pointer types have to support a "null" state.

Rust take a different approach, the compiler keeps track of whether a given address contains a "valid" object or not. At an instruction level a move is just a copy but the key difference is that after the move the compiler no longer treats the source as containing a valid object. So drop (rust's equivilent of a destructor) will only be called once.

The problem is even "modern C++" is still very much an "unsafe by default" programming environment.

1. you can use your fancy smart pointers to track memory ownership, but to actually do anything with the objects they point at you have to convert them, explicitly or implicitly (usually through the operator-> overload) to raw pointers or references. Once you do so there is nothing to gaurantee that the that the smart pointer is not modified during the lifetime of the raw pointer or reference.
2. With the standard collection types the pleasent to use access methods are the ones that do not have bounds checks.
3. There is nothing to prevent inadvertant passing of a non-threadsafe type across a thread boundary.

There are different revisions of the USB power delivery spec, AFAIK revisions 1 was for USB A/B connectors, revision 2 supports both the legacy A/B and the new C while revisions 3.0 and 3.1 are for USB C connectors. To make things even more confusing each of the revisions seems to have versions, USB-IF are awful at naming things.

USB IF seem to put both revision 2.0 and revision 3.1 in the same zipfile https://www.usb.org/sites/defa... I have skimmed the specs at various times but not read them in detail.

My understanding is that PD on USB A/B was implemented using comminication superimposed on VBUS. To protect against damage caused by non-compliant cables the plugs on PD compliant cables were required to be "marked", this marking was mechanical for the standard A/B plugs and electronic for the micro A/B plugs.

In practice though I don't think USB PD on A/B connectors was ever widely implemented. I suspect the requirement for special cables and connectors put manufacturers off.

I disagree.

C is just painful to work in. I don't want to have to worry about memory management and buffer overflows every time I manipulate a bloody string. Those better things in the C++ standard library compared to the C standard library are possible *because* of the extra language features C++ has.

Most of the newer languages that compile to native code have no shared library story to speak of, you are expected to build everything into your binaries statically and/or rebuild everything on a new compiler release. The C++ shared library story is far from perfect, but at least it has one.

C++ has many problems, but I don't think the question of whether those are bigger or smaller problems than other languages have is an easy one to answer.

The 4GB address space limit pops up in various places.

* It's a limitation of CPUs without PAE (or with PAE disabled). In practice CPU support is a non-issue as the CPUs have supported PAE for years.
* It's a limitation of 32-bit Desktop windows since XP SP2 even with PAE enabled. In XP SP2 this limit was hardcoded into the kernel and infeasible to disable. In Vista and Win7 this was implemented through the licensing system and can be bypassed. I ave no idea wat the situation is in win10
* It's a limitation of some chipsets, IIRC intel lifted the limit in their laptop chipsets one generation after the one in my 15 year old macbook. I presume mainstream desktop chipsets lifted it a bit earlier and workstation/server/highend desktop chipsets much earlier.

How exactly the 4GB address space limit translates into usable ram was a bit variable, Sometimes it could be as high as 3.75GB, I heard of some systems where it was as low as 2.5GB.

That is certainly true in the high end workstation/server space, intel introduced PAE as far back as 1995.

I can't comment on elsewhere but here in the UK the problem is that at least in the UK the banking industry doesn't seem to have properly grasped the distinction between identification and authorisation. I believe the situation is even worse in the USA, I don't know about elsewhere.

So by giving someone the information they need to send me money, I risk them fucking with me by setting up fraudulant direct debits. A possible workaround is to use a "savings" account that doesn't support direct debits, but I've seen some reports that even this isn't a totally watertight soloution.

The fundamental problem with a stablecoin is that it has a centralised entity reponsible for exchanging between stablecoins and regular currency. That centralised entity runs a heavy risk of being treated like a payment processor by regulators but it's basically impossible for a stablecoin to comply with the regulations for a payment processor while retaining the other things that cryptocurrency users want.

IME 10 year old hardware is much more usable than 15 year old hardware at this time.

I own a core 2 duo based macbook, which spent most of it's life runing linux (it's set up as a triple boot with windows XP and some version of macos, but it spent nearly all of it's time in Linux). I think it's the 2.16 GHz "mid 2007" model. I retired it for a few reasons.

1. Ram the model in question only supported 3GB of usable ram. Afaict it was very common with machines of that vintage for the chipset to only support 4GB of address space (even though the CPU was 64 bit) with some systems being better than others about maximising usable ram within that space.
2. The keyboard was developing issues.
3. The CPU was stuggling to keep up with video playback.

It got replaced with a refurb thinkpad T430 which I maxed out the ram on to 16GB (twice what lenovo say can be fitted) and am still using to this day.

Problematic as C++ can be in this department, rust is even worse. Or to put it a different way rust is where C++ was decades ago. Rust has no ABI stability for "repr rust" types, each version of the rust compiler just does what it's developers believe will give the best performance. Rust libraries also don't tend to care at all for ABI stability. This is why you will find that rust programs are nearly always statically linked agaist rust libraries (they may be dynamically linked against C libaries of course).

gcc also used to do this for C++, but sometime in the early 2000s* the developers adopted a stable ABI. Clang also adopted this ABI. MSVC still does it's own thing but that is hardly relavent in a Linux discussion.

Now this is still far from perfect, seemingly minor changes to a libraries code can easily cause ABI breaks in C++ and changes to the C++ standard can be a problem too (the C++11 string/list changes were a particular pain point) but with some care C++ ABIs can be kept stable enough to make shared libraries practical without rebuliding the world on every compiler update.

The Linux kernel cares very little about compatibility of it's internal ABIs. The default assumption of the modules system is that each kernel version, even a "micro" version will require modules to be rebuilt.

The ABI used between kernel and userspace is another matter, that does have long term stability promises but it also has relatively little relation to the language used. Structures passed across the kernel/userspace boundary need to have a stable layout but that is easilly achived in any of the languages under consideration.

* It happened sometime between Debian woody and Debian sarge, I could trawl through upstream changelogs to figure out exactly when but meh.

Given the context I suspect it's an abbreviation for it's "Men who have sex with Men". A term I've seen come up in public health messaging on monkeypox.

AIUI it refers to people who are physically male and have sex with other people who are physically male. So mostly gay men, but also some trans, bisexual, nonbinary etc people.

Generally people cheat by getting external help. Someone outside uses a computer to analyse the game and then feeds hints back to the player through a clandestine channel.

There are various countermeasures that can be taken to make such cheating harder, but they tend to have the side effect of making the tournament more expensive to run and/or less attractive for players and spectators.

Samsung announced a 30TB drive in the 2.5 inch server form factor (same footprint as a laptop drive, but thicker) a few years ago, I can't seem to find anywhere with it in stock new anymore but I did find one used on ebay, so presumablly some were made/sold.