Short answer is that it is (imo) by far the best language for writing generic and fast math. Multiple dispatch allows you to write math using normal notation and not have to jump through hoops to do so.
Can't you get countable choice with zf? Countable means there is a bijection to the naturals, so you can always pick the element that corresponds with 0.
There's a lot of physics you can do in single precision. In fact, current gen climate models are mostly in single precision, and some of the next gen models are trying to do a lot of the work in half precision (float16).
One thing to consider is that you save a lot of weight on noise insulation. The wavy edges on the back of many new jet engines make the engines about 2% less efficient, but they let the plane save on enough weight to more than make up for it. Electric engines are probably about 20db quieter than equivalent power jet engines, so that can claw back some of the lost range.
In general, anti-viral treatments don't work very well. Antibiotics have worked great, but it's much harder to effectively target viruses with medicine (probably because they reproduce inside the cells of their hosts)
Covid (original version) took several months to spread around the world without something public health measures to slow it down. The Delta variant took about the same time despite the fact that significant portions have a degree of immunity from the vaccines or previous exposure, and much less international travel.
Some semantics are inherently slow though. If you are allowed to add fields to a class at runtime, you have to box all your objects. If you can eval in local scopes, you need to check to make sure you're running the right code. There are many types of semantic decisions with inevitable performance impact.
Note that there is an effort to fix this. A group of Julia developers have written a proposal to give Unicode proper subscript and superscript modifiers.
The main cause of Texas's blackouts were the grid losing about 70% of their natural gas power (and not having good inter-connects with the rest of the US). Also, it is a great example of where the ability to pre-heat a ton of water would have been really useful. If they had the ability to do so, it would have greatly reduced the demands on the grid when the storm hit, which would have prevented the problem in the first place.
One thing that I think this will mean is the end of blas. Blas served us well for about 50 years, but one of the big problems it has is that it leads to code that takes multiple passes over memory. I think the future lies in systems that do code generation to better fuse loops of arbitrary code together. LoopVectorization.jl for example is able to generate blas level code for arbitrary computation, and as such can often be faster than blas since you don't have to use one of the specific hand optimized kernels.
Sorry for the confusion. I meant reproducibility in the sense that I can have a git repo to share code between a laptop running windows and a cluster running Linux, and if I run the program on both I'll be running the same program (same libraries, same versions, equivalent binary blobs, etc). I don't mean that it can give you a cryptographic proof that your code hasn't been tampered with maliciously, just that you can debug your code locally, then deploy it to whatever you want and be pretty sure that it will still work even if you deploy to a different OS an/or cpu architecture.
The problem is that no warrant is needed if the phone company complies without asking for one.
Basically the government says "hey can we see this users data? (And if you say no, we'll get a warrant that requires you to do extra work)", and then the phone company turns over your data without requiring the warrant because they don't care about you.
Note that those issues are about deterministic performance, not results. Also guix and nix appear to be Unix only, which severely limit their use for Windows users. One of the places Julia really excels with reproducibility is inter OS, yes there are probably some bugs, but the ability to manage versions cross OS this easily is something I'm not aware of a good alternative for.
One reason to consider Julia for workflows like this is that it's been designed to improve reproducibility. Julia makes it really easy to distribute package state (through manifest.toml files), that make it easy to get exact copies of the package versions that the original author used.
You aren't accounting for purchasing power. In most countries, medicine costs half as much (or less), education is much cheaper, and the cost of food and housing is much lower.
Out of order execution requires a ton of logic (you're basically adding a small optimizing compiler in silicon). This takes a bunch of area and leads to more complicated data paths. The reason high performance cores use it is that it greatly reduces pipeline stalls, and as such can make your cpu several times faster.
If you are interested in datasets that fit in memory, Dataframes.jl is really good now. For interfacing with SQL, there still isn't anything much better than jdbc.
Currently Julia will probably lose to C++ here due to some GC quirks and less well optimized strings. That said, both of these issues are being worked on, and I would expect fairly major progress by 1.8. (some of this work is already done. Specifically, as of 2 days ago memory alignment of strings has changed to save 8 bytes for most strings). Future improvements will likely include some form of small string optimization to prevent them from being heap allocated, and making julia's GC more efficient for highly threaded code.
I don't think these are contradictory. More people have read the Bible, but many of the details they know about the story are from paradise lost, not the bible.
I think a lot of it is that modern languages (python to some extent, rust Julia etc) implimented many more of their features themselves. Julia, for example, has some basic stuff defined in C, but 70% of the code is just Julia. Since most of the changes between releases are in the language, they don't introduce new syntax or make the language feel messier. They just slightly expand what the language can do easily.
But since Turing machines can emulate multiple Turing machines, any problem that can be completed by multiple machines communicating can be solved by 1 Turing machine. As such, the computational power is exactly the same.
I'm not sure about this. There are a bunch of "rural" states that still have large populations in pretty urban areas (eg Nevada, Vermont). It seems totally plausible that the urban parts of enough rural states are more than happy to give up their electoral power to shift the political balance.