But many of the listed hypotheticals are not dependent (on top) on others, and since there are multiple that actually increases probability of an undesirable outcome.
I personally am thinking that developing more programming languages has stopped making sense a long time ago because all of them ignore this untapped market that would help more languages.
C based FFI uniquely privileges C the same way the dollar being a global reserve currency privileges the US, but in the case of currencies the differences in how they work are very small, but with programming languages the differences are substantial.
Half the people working on new programming languages should have been working on GObject competitors instead.
One of the things that is difficult to grasp is that the best FFI is not native to a specific programming language, meaning it does not privilege any specific programming language. Of course this doesn't mean that it cannot be heavily inspired by a particular programming language, it just means that the implementation must be common to all programming languages.
What I mean by the latter is that the features need to be implementable in all programming languages and the easiest way to do it is to define common data types.
The big fallacy that the C FFI advocates present is that it is somehow fine to require full C compiler infrastructure and the C standard library to parse C headers and produce the ABI, but somehow it is the height of evil to define a fat pointer as a C struct consisting of a data pointer and a function pointer and mandating every language to use it, because it is not a C native datatype and only the mythical programming language C is allowed to be used for FFI. I'm pretty sure half the battle could have been won by C having defined common datatypes for the sole purpose of ffi in its standard library.
There have been enormous strides here. We have developed WebAssembly and WIT, with Extism as a chrome over then providing tower of babel between most programming language pairs. We have GraalVM and Truffle to unify languages under one compiler. We have LLVM bitcode to combine languages targeting native machine code for many architectures directly. Swift, Zig, Jai all implement C interop on their own terms. AI agents allow us to re-target algorithms between languages with no compiler interoperability. There are countless pretty darn good ways for programs to communicate through message passing - MachO XPC, Dbus, COM, gRPC, HTTP3 (+ , ZeroMQ, Fuchsia Zircon+FIDL, unix domain sockets. There are more programmers now than at any time in history.
Yes these can be used as alternatives sometimes, but they are not really the same thing. We need a streamlined way for reusable libraries (written in different languages) to be consumed by different languages while not being limited to a specific runtime or platform. When code from different languages needs to be able to run inside the same process, with low calling overhead and avoiding copying when possible.
Your answer just throws in anything that enables programs to communicate somehow, ignoring all the differences and tradeoffs to what is being discussed here. Many of your solutions lock you in to a specific platform, a language or add a non-trivial overhead like message serialization or add an unnecessary complexity to a program. Also, IR does not solve the same problem as ABI.
im just pointing out (a) a ton of work has gone into this, (b) yielding many options for different use-cases, (c) without dependency on c-abi/c-header.
> In the 2025 report, we showed that nearly 70% of credentials confirmed as valid in 2022 were still valid as of January 2025, meaning they have not been rotated or otherwise remediated. When we retested the same dataset in January 2026, the validity rate remained over 64%. That persistence is not a rounding error. It is an operational signal that remediation, not detection, is still the industry’s limiting factor.
> In the end there is always some long lived secret. What changes is just where and how it is stored, secured and used.
Obviously. The point here is to reduce the number of them
Agreed, the OP said that the r in rxjs stands for reactivity, so my point was the the names have little bearing on the actual design patterns achieved with the libs
> It roughly compares with GPT-4.1 (!!), released 14 months ago
I think the mayor win for coding was reasoning. That's why such a small model can match GPT-4.1 in coding, but I suspect that GPT-4.1 still wins in general world knowledge due to bigger size.
> I suspect ... still wins in general world knowledge due to bigger size
Encyclopedic knowledge matters relatively little in perspective, given the expectable future developments: even the more knowledgeable of us will use that knowledge for reasoning and intuition (and we will have absorbed the intellectual keys during our training), but under our professional hat we should in theory be ready to go "I stand corrected" and "more precisely" with the actual data at hand.
I.e.: for the encyclopedic knowledge needed, the /understander/ will have a RAG subsystem and a corpus of knowledge to inquire upon processing queries.
(Corroboration: we can't delirate, and neither can the machine...)
Don't LLMs work on attention though? The closer in their hyperdimensional space you can land your problem to their inherent understand the better they are at understanding your problem domain. RAG loops can be very slow and agents may simply lack the knowledge to use them correctly.
But, in short, the ability to manage information, to process it properly, is more important in this regard than just having the information. "Having" more knowledge is not a guarantee to "using" it better.
And to improve reliability, if the machine can check, it will have to check. "Costly" cannot be an excuse.
Your suggestion is not clear: yes we reason and define relevant details (maybe through further information retrieval) to better construct queries - that is what Analytical school of thought taught and insisted on -, and even more crucial is that the subsequent delegated steps, of constructing replies, imply reasoning and information retrieval.
Said abilities - intellectual strength - are immensely more important than notions. The relation between network size and intellectual strength, vs network size and notions (original topic in this branch), is presumably not yet that clear. Intelligent models may not necessarily be embedded with explicit information of everything, though they will have to have ways to reach that upon contingent necessity (to solve specific problems). Like us.
I agree with what you said. I just wanted to add that intelligent models probably need to have some notion embedded (but not everything), as some information retrieval is not trivial. Too few embedded notions will hurt it's ability to solve problems but from some point onward you'll get diminishing returns (where it starts to make sense to rely just on information retrieval).
For example, you if you instruct a model to create decoder for some data type users will upload to your website. The intelligent model without notions will retrieve information about that data type and build a working decoder, but it might miss from context that users uploading to a website means untrusted input and thus won't even try to gather information about what it needs to be done to securely handle such uploaded data.
Or if you give it a task to translate text to a language it didn't encounter during training. You can provide it with grammar rules and a dictionary for information retrieval, but I guess it won't perform as well as inteligent model that already has some fundamental notions of that language and only needs a dictionary to expand its vocabulary.
Gpt-4.1 only knows a lot of patterns, but doesn't have reasoning intelligence that would help it properly use that knowledge. So, a small reasoning model can easily beat it in a lot of tasks. The question is how will, 14 months from now, new small reasoning models compare to current big reasoning models.
How much information needs to be embedded is not yet clear, but currently, bigger reasoning models are still better at complex tasks than small reasoning models. Either sweet spot of embedded notions is higher that what current small models have or information retrieval ability needs to improve.
I agree with you in general, but depending on the task I also find that a certain level of encyclopedic knowledge can be very valuable. For example, if you use it for coding, the model will likely not resort to search or RAGs when deciding whether to use a particular package or stack.
It's not arguing that predictive power is bad. Just that people often mistakenly believe some phenomenon is understood more deeply than it really is, because a model can fit data and generate accurate predictions.
> The out-of-the-box Shotwell manages photos quite well without any intelligence.
This piqued my interest on how it does it and after briefly checking the project it seems it only has two features for automatic photo categorization. 1) it can group photos by date and 2) It has face detection and recognition that uses trained weights (so ML "intelligence").
One interesting thing about Barman is that it just uses PG's own backup utilities. It doesn't implement custom parsers and things like that. So, there's less maintenance work needed for Barman when PostgreSQL changes data-file internals. Tradeoff is that there's less custom optimization than pgBackRest/pg_probackup/WAL-G-local.
Databasus seems to be taking somewhat similar approach to Barman, but (at this time) does not appear to use pg_receivewal, which makes it less efficient than Barman.
For PG v17+, Barman seems to be the most efficient backup solution based on PG native tools, that is able to do low-RPO or even zero-RPO (if configured as a synchronous receiver).
