So you add threads to allow a shared objects graph with a side effect of more frequent stop the world. Then you fight stop the world by resorting to low level memory management. But if you go level why not allocate a shared array buffer and share it across workers? Something you can do today without threads.
I don’t think it is extreme. Imagine this is added to WebKit. Now I have a new question to answer - can I use library X across multiple threads? How do I know it does not have a little cache inside which breaks if I call it from multiple threads?
Another issue is lack of memory model (sorry if ai missed it) which means memory updates will be published to threads differently on different architectures.
And then an obvious problem of mixing async with locks - never ends good.
>mostly share read-heavy graphs and coordinate through a few hot objects, which is what Lock/Atomics are for.
Then it is a clear overkill to me. I’d rather built an in-memory DB on top of shared array buffer. Would work almost as good as an object graph but does not require a full system overhaul.
To me being able to query over psql is secondary. I’m fine with any SQL. What is very important is being able to transform the data to better suite analytical queries. That is, define custom transformations, define how data sectioned and what indices available.
I don’t disagree, just placing emphasis on a different aspect.
In an ideal world there is a tool that moves your schema into an analytical store “as is”
with a single click. Then the same tool lets you add arbitrary transformations of the data. Surprisingly I have not come across such a tool. It is earthier “one click to move your data” or “any transformation you want” but only after a significant upfront investment :(
IDK, AWS Zero ETL from Autora into Redshift really helped us at some point. You right that data transformation is very limited if not possible. But having data in an analytical store, being able to experiment with queries, understand what is wrong with your OLTP schema and then build ETL is way better than doing an upfront design.
Is this a theory or your personal experience? I lived in Russia for most of my life. Had 21 C set in the car even in -20 C. If the coat is too hot then you just put it off.
One reason why you want warm air in the car is defrosting your windows.
In other words you can use time as your TX id, add MVCC and now you can transactionally read data from multiple partitions/shards. In a traditional distributed DBMS it would require a global tx manager creating a bottleneck. Did I get it right?
Why people say they have big test coverage while other say it segfaults a lot? I saw lot of JS test that this is just API surface test. Edge cases happens inside API implementation, things like memory leaks or data corruption that shows up after a while cannot be catched reliably with these tests.
>The only assumption you need to make is how the process went about, which was described by Jarred
This is not how the process went. This is how Jarred thinks it went, a huge difference.
>my guess is that the LLM wrote a transpiler to do the job
My guess is different. I think one agent translated code, another compiled it, feeding errors back into translator to fix. Then last agent modifies code to fix tests. All governed by a set of md files.
You suggest there is only JS tests that do not need a rewrite? This is crazier than I thought…
I took tests as an example. There are so many other things that can go wrong. Rust and Zig standard libraries may have different semantics not picked up by AI. Like one guarantees insertion order of a dictionary and other does not. Differences in how runtimes react to Linux signals, how they do file IO, etc.
If I were a Bun user I would be moving off from bun unless it has excellent test coverage (which I think it does not). During a normal release cycle I offered a small increment of functionality with small number of issues. Here I’ve been offered a complete rewrite, potentially having thousands of issues. I don’t want to be a guinea pig in this experiment.
Nobody reviewed resulting code. Maybe all tests are empty and this is why they pass. Maybe tests were modified to pass because this is the only thing LLM could do to make them pass. Maybe it hallucinated something in the process. We have no idea.
Because of borrow checker you would build data structures differently in Rust compared to Zig. Automated translation simply maps Zig constructs onto unsafe Rust code. I have no idea how feasible it is to go from totally unique way of using Rust to mimic Zig to idiomatic Rust.