Arcterus's comments

I'm talking about the overhead post-translation for Rosetta. Translating optimized code from one architecture to another is difficult, which is why there is a performance hit.

There is more substantial overhead translating to a different instruction set than in converting API calls to another API. Looking at basic benchmarks should be enough to demonstrate this. IIRC it's like 80% of the performance or something when using Rosetta as compared to native.

Also, Rosetta is more like a transpiler, since it basically recompiles the binary, whereas the others are literally layers that basically take calls in one API and translate them to another. They're pretty much the same thing as ANGLE.

DXVK, VKD3D, D3DMetal, etc. are translation layers. You're implying they're far more heavyweight than they actually are. The real reason Windows games don't run as well on Macs is that they're usually built for x86_64 instead of ARM.

As someone who has used both Windows and Linux to game on the same x86_64 device, the performance hit with Proton is pretty much negligible (and sometimes games actually run faster on Linux).

> Standard libraries should include everything needed to interact with modern systems.

This is great when the stdlib is well-designed and kept current when new standards and so on become available, but often "batteries included" approaches fail to cover all needs adequately, are slow to adopt new standards or introduce poorly designed modules that then cannot be easily changed, and/or fail to keep up-to-date with the evolution of the language.

I think the best approach is to have a stdlib of a size that can be adequately maintained/improved, then bless a number of externally developed libraries (maybe even making them available in some official "community" module or something with weaker stability guarantees than the stdlib).

I find it a bit funny that you specifically say HTTP handling and JSON are the elements required when that's only a small subset of things needed for modern systems. For instance, cryptography is something that's frequently required, and built-in modules for it often suck and are just ignored in favor of external libraries.

EDIT: actually, I think my biggest issue with what you've said is that you're comparing Python, Go, and Rust. These languages all have vastly different design considerations. In a language like Python, you basically want to be able to just bash together some code quickly that can get things working. While I might dislike it, a "batteries included" approach makes sense here. Go is somewhat similar since it's designed to take someone from no knowledge of the language to productive quickly. Including a lot in the stdlib makes sense here since it's easier to find stuff that way. While Rust can be used like Python and Go, that's not really its main purpose. It's really meant as an alternative to C++ and the various niches C/C++ have dominated for years. In a language like that, where performance is often key, I'd rather have a higher quality external library than just something shoved into the stdlib.

Saying he isn't even that rich and then saying that he has 1/30th of the total assets managed by BlackRock is completely absurd. I frankly don't understand how you can think one person controlling 1/30th the value of all of BlackRock's managed assets is totally fine and normal. Additionally, as mentioned by others, BlackRock invests on behalf of clients, so unlike Musk, they can't just throw around their money willy-nilly, so the comparison is just disingenuous.

To put this in perspective, the net assets of Google are around $300 billion, and their total assets are around $450 billion. Musk's net worth is roughly $400 billion.

I believe I actually had a proof of concept of this functionality in a PR at some point. This would basically have to work like mesabox, where each utility takes some generic input and output and then runs based on them rather than using stdout and friends directly (e.g. to avoid blowing through all your memory by stuffing many gigabytes of output into a Vec on certain commands).