Java checked exceptions suffer from a lack of generic exception types ("throws T", where T can be e.g. "Exception", "Exception1|Exception2", or "never") This would also require union types and a bottom type.
Without generics, higher order functions are very hard to use.
> Breaking off pieces of the code into microservices ...
I was with you until "into". Then continue with "Maven modules" (or Gradle modules, or some other kind of modules) and solve some real issues instead of imaginary deployment structure issues.
1. The article states "In 2023, the UK produced no commercial ships at all." It does not consider military ship building, which still exists in the UK.
2. Given the scale of problems described in the article, it is probably easier to restart a civilian ship building industry from scratch than to expand it from the previously existing.
The conclusions of the FT article are completely wrong. With fewer rich people around, chances are that legislation would be less frequently bought to benefit them at the cost of the country's overall prosperity.
I don't know about CS, but in mathematics the vast majority of researchers would not have enough funding to pay for a good quality full review of their articles. The peer review system mostly runs on good will.
You cannot "point" JSpecify to anything. It is a standard like PEP 484, but much smaller, because everything else is already part of the language standard.
This sounds even worse than Modular/Mojo. They made their language look terrible by trying to make it look like Python, only to effectively admit that source compatibility will not really work any time soon. Is there any reason to believe that a different take on the same problem with stricter source compatibility will work out better?
Yes, type checkers are very good at tracking refactoring progress. If it turns out that you can proceed to test some subset, then congratulations, you found a new submodule.
I believe that LLMs are detrimental to government efficiency, because they distract from solving the underlying problems (such as porkishly complex laws or a lack of unique identifiers).
In a well-designed city, you don't get onto the subway with a stroller during peak hour, because all amenities that your young children need are reachable in 15 minutes on foot (or <5 minutes by bike).
No cryptographic verification is required for content blocking. Make it easy to set up a slightly locked down "child" account (e.g. one behind a MITM proxy that only lets through HTTP(S) and blocks some domains) by requiring it from every OS vendor. Label existing devices/software without it "18+".
If you need to test for null checks and function parameter types, then your dismissal of "half-assed" type systems is severely misplaced. Everyone [1] agrees that testing null checks is a huge waste of time.
"renegotiate at market rates" is extremely tenant-punishing, because the cost of moving for the tenant is much higher than the cost of finding a new tenant for a landlord. It becomes better if you remove the "renegotiate" part and couple the allowed rent increase to some index.
Even a rail line such as RER A only has a capacity of at most 40k people/h/direction. It cannot solve all, or even most, transportation problems of a large city. For that, you'd need tens of lines, as in China or Madrid.