Likely the issue is between most user systems not configuring huge tables and developers not keen on using things they can't test locally. Though huge tables are prominent in single-app servers and game consoles spaces.

- [0] https://docs.kernel.org/arch/arm64/hugetlbpage.html - [1] https://developer.arm.com/documentation/ddi0487/latest (section D8.7.1 at the time of writing)

I understand the wish for a magic bullet to just verify already existing code, but I recon the answer to this is to verify code before it's even written.

WebAssembly is working on adding support for 64 bit address space though.

- [1] https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...

Also, few weeks ago I found a use for them when trying to pass configuration from Java/Kotlin to C++ library to be used during static constructors (invoked during dlopen) on Android, because at that phase native code cannot call back to JVM.

Control software is much more involved topic, let me illustrate it with a scenario: one family member is non-techy but has an insulin pump, another family member is techy and likes to hack around, they made a change to the insulin pump software to "improve it", but by accident the change triggered insulin overdose at night during sleep and family member died. We have rules and regulations not just to have rules and regulations, we have rules and regulations because they are written in blood.

While advocating for ability to freely modifying any life dependant control software is a noble goal, in my opinion it's the wrong end to approach it, instead it would be more constructive if we as computer science industry figure out ways how to make software such as we don't kill people, how to "certify" it in self service fashion (validation passed == no-one will die), etc, it's no trivial and it feels this particular part of our industry is not as developed/main stream as compared to something like civil engineering. If we have easy ways to ensure that modifying software will not lead to death then it will be easier to change the legislation to enforce this freedom.

WASI is probably doomed to fail, so far it was proven to be challenging to make "write once run everywhere" API, for example it's difficult to abstract over epoll vs IOCP vs io_uring without reinventing libuv, but making a standard out of libuv API will make adopting any platform changes too slow, because of losing control over the implementation of the API. Having a single standard implementation where the industry is collaborating might be a better way, similar to how .NET is an abstraction over platform API.

- [1] https://en.wikipedia.org/wiki/HarfBuzz - [2] https://www.phoronix.com/news/HarfBuzz-8.0

- [1] https://learn.microsoft.com/en-us/typography/truetype/hintin...

Sure one can say input is coming from a network stream then what? For practical issues then we can limit input size to N bits ... For theoretical issues we can discuss if there is a difference between halting or waiting for more input :)

So it's definitely possible to decide halt problem for a bounded computer (any physical computer), it's just not practical in most cases, e.g. amount of memory needed to store graph of all states be bigger than amount of matter in the universe, etc.

- [1] https://www.hodinkee.com/articles/richard-hoptroffs-atomic-w...

So math of getting to destination starts to work, then you get to destination charging and that is more tricky. The car wants 16KWh per 100km, and charging from power socket you can realistically pull 1.6-2KWh, so overnight you can expect to be able to charge 100km of range without much of infrastructure (without level 2 chargers I mean).

So my conclusion is that it's not plug-and-play just yet, but it nearly works, and benefits of electrics starts to outweigh the disadvantage of looking for a power socket.

- Current abstractions are mostly based on POSIX threads and C++/Java memory models. I think they are poorly representing what is actually happening in hardware. For example Acquire barrier in C++ makes it really hard to understand that in hardware it equals to a flush of invalidation queue of the core, to sanity check your understanding try answering the question "do you need memory barriers if you have multithreaded application (2+ threads) running a lock-free algorithm on a single core?", correct answer is no, because same core always sees it's own writes as they would happen in program order, even if OOO pipeline would reorder them. Or threads, they seem to be an entity that can either run or stop, but in hardware there are no threads, CPU just jumps to a different point in memory (albeit through rings 3->0->3). Heck even whole memory allocation story, we have generations of developers thinking about memory allocation and it's safety, yet hardware doesn't have that concept at all, memory range mapping concept would be the closest to what MMU actually does. Hence the impedance mismatch between hardware and current low level abstractions created a lot of developers who "know" how all of this works but doesn't actually know, and a bit afraid to crush through layers. I want more engineers to not be afraid and be comfortable with all low level bits even if they would never touch them, because one day you will find a bug like broken compare-exchange implementation in LLVM or similar.

- Tooling is way off, the main problem with multithreading is that it's all "in runtime" and dynamic, for example if I'm making a lockfree hashmap, the only way for me to get into the edgecases of my algorithm (like two threads trying to acquire same token or something) is to run a bruteforce test between multiple threads and wait until it actually happens. Bruteforce-test-development scales very poorly, and testing something like consensus algorithms for hundreds of threads is just a nightmare of complexity of test fixtures involved. Then you get into ok, so how much testing is enough? How do you measure coverage? Lines of code? Branches? Threads-per-line? When are you sure that your algorithm is correct? Don't get me wrong, I've seen it multiple times, simple 100 lines of code passing tons of reviews only for me to find a race condition (algorithmical one) half a year later, and now it's deployed everywhere and very costly to fix. Another way would be to skip all of that and start modeling your algorithms first, TLA+ is one of the better tools for that out there, prove that your model is correct, and then implement it. Using something like TLA+ can make your multithreading coding a breeze in any language.

And probably absence of transactional memory also contributes greatly, passing 8 or 16 bytes around atomically is easy, but try 24 or 32? Now you need to build out an insanely complicated algorithm that involves a lot of mathematics just to prove that it's correct.

Any game or game engine (like Unity or Unreal) which wants to run on Xbox natively is required to use GDK. But the details are only available to licensed developers.