trws

We recently had some real discussions about this. It’s worth remembering that designing, building and testing a custom chip runs, for a relatively old density, order 100 million dollars. Add to that the fact it would only be useful for a small subset of the problems your users want to use the machine for and it becomes pretty clear why supercomputer centers go generic as much as feasible. Also bitcoin is a bit of a poor example because the memory requirement for each unit is incredibly small. That’s rarely the case for any kind of meaningful simulation.

Another author here (Tom Scogland). We seriously talked about it, and are exploring some other loading models as part of subsequent work. The real trick is that this has all been neglected and effectively set for so many decades that if we do manage to find something better, it will take convincing some of the most conservative open source maintainers and code owners in existence to update the loader and c standard library to roll it out in a way most users would be able to leverage. We’re trying, and think we’ve found some really preferable alternatives and options, so here’s hoping.

I never worked with the XT3, but I’ve worked with others with similar limitations. Many of our projects prefer static linking, but at any given time they tend to have to run on several platforms. As of today, they have to run on at least two where one won’t load gpu components in libraries correctly if they are statically linked, and one where it won’t if they’re dynamically linked. Forcing projects into one model or the other makes the smaller requirements on other platforms much harder to deal with, even if the requirement aligns with the project’s preference.

I’m guessing the OP meant “where glibc is really horrible”, since bsd libc is rather more abi stable, largely because that’s where FreeBSD provides compatibility instead of the syscall layer. This is not to say you can’t use an old libc and fix up the loader paths or use a container and make it work, but it’s a different set of challenges.

Haskell and OCaml (reason too of course) are the only ones that come to mind as a 100% match

I would argue that Rust and Swift also qualify though, since their lifetime management and reference counting respectively are valid forms of garbage collection.

Crystal fits except for the promoting OO part.

If we ignore the bonus then Scala and elixir might also qualify.