symbol-mason

You're deeply concerned about US war crimes, but you support a peace deal which specifically gives amnesty for Russian war crimes?

Whataboutism leads to such odd rhetorical distractions. This isn't a deal about Gaza, Afghanistan, or Iraq, and the only reason to discuss them is to distract from Russia's military aggression.

The Iraq and Afghanistan wars ended with the US famously achieving few to none of its long-term war goals and a huge public and international sentiment against further regime change adventures. If those resisting the US occupation had given up earlier, would the US neocon warmongers have been so thoroughly driven from power? Or would they have been emboldened by the victory and more likely to continue with their promised invasion of Iran?

Russia is a nuclear state, and will in no rational scenario ever "come under attack by the entire world" due to the inevitable consequences. On the other hand, manufacturing casus belli again and invading Ukraine in a few years is an obvious outcome.

The general answer is "represent it in the type system". That's typically via discriminated unions like Rust's Result, or something which emulates it (such as OneOf or Dunet for C#, although it will be a native part of the language soon).

Pattern matching, nullable types, and the Try* method conventions are also ways of representing the potential for failure explicitly.

The examples in that article (CreditCardExpiredException, SuspiciousActivityException, CardTypeNotSupportedException) show why no other languages follow Java's concept of checked exceptions. Those are examples of business logic or control flow being done by exceptions, which has been, in my experience, considered an anti-pattern for a very long time.

Other languages use union types, enums, or other type system constructs to represent operations which may have multiple possible outcomes. You're correct that these languages don't support business logic exceptions, but that also isn't an acceptable practice outside of Java.

Inline C/ASM is literally a different language. System.Runtime.Intrinsics is a library. Just because this one benchmark used the library in a C-like style doesn't mean that's required.

There are many simpler implementations in all languages. I actually like that there are multiple implementations, as this lets us estimate the benefit and complexity of adopting various optimizations. Limiting the benchmark to naive implementations would penalize languages with more broad capabilities for optimization.

I'd personally prefer a benchmark limited to memory-safe implementations, though.