A sidenote is that Wii actually ran a separate operating system (nicknamed IOS by the community) in a dedicated ARM processor (Starlet), that was responsible for performing the majority of device input/output, including disk access, internal and external storage, and notably in this case, networking - the TCP/IP stack was implemented entirely there.
Besides running on a weaker CPU, IOS can access (for exclusive use) some of the main system memory, but it was usually about 12-16MB to not starve the actual games running on the main CPU (https://wiibrew.org/wiki/Memory_map), which can help explain why everything except for the actual games was so slow.
Originally, code running on the main PPC CPU could not access directly most of the IO related hardware at all (only GPU/display output and wired controllers - the bluetooth stack was also on IOS AFAIK, but the Wiimote drivers themselves were userspace), so even the Linux ports had to "proxy" some hardware access through the IOS, but later after reverse-engineering the full boot process, people were able to create a replacement IOS that could enable full access through a special register: https://wiibrew.org/wiki/MINI, enabling full-speed Linux ports, and since that functionality is about a decade old now, I would guess that the NetBSD port also takes advantage of that.
Just as an side note, not relevant to anything in particular, Foundation DB itself is open-source (https://www.foundationdb.org/), but the integration layer used by Deno to make it the backend for Deno KV is not.
Although, from reading the Foundation DB docs and checking the Deno KV API, I honestly suspect it is a thin layer.
Self-hosting FDB is somewhat inscrutable though, so their value add is in not having to handle infrastructure while being backed by FDB.
> Go actually ships with a quite forward thinking SQL interface
SQL is low hanging fruit in this regard, because you just need to standardize the lowest common denominator flavors of SQL types for deserialization and then it's just juggling SQL queries around.
JDBC for Java does the same as database/sql and it's from 1997. ODBC is from 1992.
I don't think GP is saying that this is forward thinking, revolutionary level stuff, but rather that it's generally speaking a better thing to do than ship specific implementations that wall people into your solutions.
> run games in almost native performance in windows guest vm?
No, vfio is still the most recommended option.
This is essentially something like VirtualBox or VMWare 3D acceleration - the host is still the "owner" of the GPU, and has to juggle receiving OpenGL commands from the guest and sending the render results back to it, with lots of overhead. But easier for users than setting up passthrough or using proprietary GPU virtualization solutions.
People pointed out that there is a similar project for Vulkan, already being used in production for ChromeOS, called Venus. Should be the one to watch nowadays.
As far as I understood this is very much intended to be used in multi-threaded code as well. If you are sure that your object won't be called in multiple threads you can just do the simple "if(ref == null)" without locking and it should be reasonably fast - just not constant-foldable by the JVM.
The ComputedConstant indeed has to be threadsafe, but the proposal reads as its initializer would be executed on the thread of the caller of get(), and other callers would have to wait until initialization has completed. Indeed very useful for multithreaded programs as well.
There isn't a daemon to speak off, they are shared libraries that you load and call functions on.
I don't know much about R, but if it considers the whole memory space of the R process, it probably counted the memory consumption of the libraries themselves as well.
The memory profiling only measures allocations on the R heap (i.e. objects managed by R's GC). It doesn't measure allocations by other libraries running in the the same process, unless they use R's allocation machinery.
> Kotlin data classes can be used with the JPA contrary to Java records.
Arguably this is more of an issue of JPA than an strict advantage of Kotlin: JPA was designed at a time where the general consensus was to primarily use mutable data, and was heavily influenced not only by existing Java ORM APIs, but by their implementations.
Kotlin itself supports JPA by the use of a compiler plugin, which is a good enough solution, but nevertheless, not one native to the language. Data classes mostly work by accident, but pretty much any documentation you will find points it to _not_ use them with JPA.
Besides running on a weaker CPU, IOS can access (for exclusive use) some of the main system memory, but it was usually about 12-16MB to not starve the actual games running on the main CPU (https://wiibrew.org/wiki/Memory_map), which can help explain why everything except for the actual games was so slow.
Originally, code running on the main PPC CPU could not access directly most of the IO related hardware at all (only GPU/display output and wired controllers - the bluetooth stack was also on IOS AFAIK, but the Wiimote drivers themselves were userspace), so even the Linux ports had to "proxy" some hardware access through the IOS, but later after reverse-engineering the full boot process, people were able to create a replacement IOS that could enable full access through a special register: https://wiibrew.org/wiki/MINI, enabling full-speed Linux ports, and since that functionality is about a decade old now, I would guess that the NetBSD port also takes advantage of that.