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.

Well the fastest C# entry for n-body looks like a translation of the C/C++ versions. It is a meaningful result that the primitives of the language allow for it to hang in that company. The absence of a Java version using numerics is unfortunate, that'd be a nice addition.

A lot of the coding style seems optimized around copy-pasting the C code, e.g. trying to alias the Vector methods (Vector256.Create) to their instruction name (_mm256_set1_pd). That makes the code non-idiomatic, but it also doesn't really help performance, just makes the porting easier.

The F# example is on the same runtime and a better view of using the numerics directly. As a trade-off of performance, memory, and code complexity it is actually a pretty solid balance, which I wouldn't have expected.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

You're looking at pretty old results, round 18 was in 2019. I also don't think that boutique web frameworks say much about the strength of the underlying language or runtime (e.g. look at just.js).

What in the Java world is in the same maturity tier as ASP.NET is open to opinion, but at least local Java devs seem to consider Spring or Micronaut as sane defaults, and of course modern ASP.NET runs circles around those.

https://www.techempower.com/benchmarks/#section=test&runid=9...