JIT compiling Ruby or Python in a way that speeds up code using existing libraries and frameworks is harder. We built up decades of code that does stuff that it would be a lot easier for JIT performance if we didn't do, like using C extensions instead of defined FFI.
If it works for you it’s great but the RDS EBS limitations are real enough… AWS built Aurora and for RDS a new 3 node topology using local SSDs for writes and EBS only for the data directly.
> hybrid OLAP+OLTP .... in Postgres this pattern requires careful planning to avoid falling afoul of max_standby_streaming_delay for example
This is a really gnarly problem at scale I've rarely seen anyone else bring up. Either you use max_standby_streaming_delay and queries that conflict with replication cause replication to lag or you use hot_standby_feedback and long running queries on the OLAP replica cause problems on the primary.
Logical Decoding on a replica in also needs hot standby feedback which is a giant PITA for your ETL replica.
One of the things I’ve said I would do and never did is create a set of test suites for as many facts about a language as I know and then run it for every new release to see what I need to unlearn.
Most but not all of these were performance related. If it took a few days to run that’s fine. Major versions don’t come out that often.
Hallucinations are now plausibly wrong which is in some ways harder to deal with. GPT4.1 still generates Rust with imaginary crates and says “your tests passed, we can now move on” to a completely failed test run.
https://arxiv.org/html/2609.01502v1
reply