> 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.

The serial GC is a limitation of the community (OSS) edition. The enterprise proprietary version has G1 support.

I hope Oracle will let it drip it down to the CE, but it's their project, their monetization strategy.

With the new GFTC license, we hope G1 is much more accessible now.

Source is not easily licensable.

> 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.

In fairness, Java 17 has just been released; it's possible new custom patches will be introduced in future Corretto patch releases.

Still, the fact that Corretto 11 had so few backports is encouraging.

> 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.

This is a classic troll text.

Lightweight threads like in Go or Erlang are not happening anytime soon as a C++ standard because they require much more complex runtimes to be decently implemented (whereas traditional threads can just delegate straight to whatever OS threading is available).

There are coroutines though, that can fill some of the same needs covered by lightweight threads: https://en.cppreference.com/w/cpp/language/coroutines