Peaker plants gamble that there are going to be peaks (sure financially plan for but they are not guaranteed to make their profits).

In the peaker plant categories the storage options are different from the spin options because the incentives are slightly different. Specifically battery storage is not just a peak plant exercise it is a grid connection optimization exercise. Grid connections limit how much power one can sell from a generator. A battery system can be placed on the grid or between the grid and the generator. In the case of between grid and generator, it allows a generator to run at it's optimal speeds more often than not, and sell more because one can guarantee a wider range of output for a longer amount of time.

Some of the first battery storage systems were sold to gas peaker plants because it allowed them more time to react. i.e. idle at a more efficient level their gas turbines or even shut them off and start them on demand.

If it is just to query one single dataset that is already in one tool it is less compelling.

It is just that trains and bikes are much more efficient in terms of land use.

The 3 lane road in front of my house is "good" for 16,000 cars a day. The 2 lane train line a 5 minutes walk from my house is "good" for 120,000 passengers a day. A train line can carry about 10x the traffic of a car lane (in practice) with similar ground usage.

So when a train system has more demand/use than expected (e.g. leman express in the geneva region) there are more options to increase throughput (in the leman express case double level trains) that require less new infrastructure to be build.

When new infrastructure is required, limitations of space mean that a 15 year period from plan to implementation is normal. Which means infrastructure which has more head-room is preferred over quickly saturated ones.

To add the adding of one lane to the A1 for 18KM costs half the total of the leman express infrastructure. But has significantly less benefits in total transit capacity.

Both seem to have arrived at the stage of transitioning from research to production code.

Very exiting for those of us providing our data in RDF and exposing Sparql.

AWs Neptune analytics is also very interesting, allowing Cypher on RDF graphs. Even the Oracle inbuilt RDF+Sparql seems to have improved greatly in 23ai.

GO has a non moving GC and I understand, that the cost of introducing safe moving GC is considered high. If one has a moving GC which the serious java one's are read/write barriers are already required, especially if they are concurrent like ZGC, C4 or Shenadoah. ZGc, C4 and Shenadoah all started out as non generational GC implementations, which gained them later, because in most cases they do increase performance/reduce overhead.

Valhalla makes objects denser, and reduces overhead of identity which is great. Reducing the difference in memory layout between java objects and nested go structs.

Go with arena's reduce the GC de-allocation costs. Something that the ZGC team is looking at in relation to loom/virtual threads. (but I can't find the reference for that right now)