kikimora

This does not match my observation. Over my life I’ve seen many gifted individuals. None exhibit high sensitivity to criticism. Most were open to feedback, even not confirming their choices and actions.

How on earth I never came across this before? ChatGPD does not know about this project either. Looks very, very promising!

IDK how trustworthy it is: Xiaomi SU7 finished dead last in the 2025 Q1 quality rating among large BEV sedans

https://carnewschina.com/2025/05/13/xiaomi-su7-finished-dead...

I really like how the car looks. But this and famous crash on track due to brakes issue…

It is the same Xiaomi which announced 300 000 SU7 vehicles sold in a day and 6 months later reported they are struggling to hit their sales targets? Just don’t believe anything a Chinese company say, divide it by at least 2. I have nothing against China, this is a cultural thing which you should be aware reading anything coming from the country.

Prompts plus code called literate programming, have been around over 30 years.

Twitter content is trash

You can say it this way. Other way to put is optimal policy makes optimal decisions on every step as if it knows the future. If you looking for shortest distance in a graph then at every vertex it picks the right step, even if the edge is longer than other available in the vertex, as if it knows the future. This is why you cannot just build an algo implementing the policy, you have to find it with dynamic programming.

There was research showing how AI performance degrades as you go from green field into support. My guess ERP in question will break after some time as agent will add more bugs than new features. Plus recovering data will be extremely difficult.

You have n decisions to make - this is your policy. After you make one, if your remaining n-1 decisions also optimal, then you have optimal policy.

I like drag&drop way more than .pkg. just easier to deal with. If you do a CLI tool then maybe `brew install CLI` is the way to go instead of a pkg file?

>The coalescing is two-level: first, simple duplicates are weeded out. Second, if the update queue gets very full, it becomes coarser-grained, and weeds out duplicates based on that coarser grain

This is not about duplicates. For example, sync updates 100 items in a list changing their titles. Items are bound to a list in the UI. Thus, 100 unique title update events triggered.

>Events are only used in the M→V communication

I don’t understand. Button clicked -> model change -> view update -> new event triggered -> model or view updated again … This is not something one would code on purpose, but often an attempt to create relationships between view. Like a custom layout code. Might not include model at all, just views being updated in an event handler trigger more events and more updates to views.

MVC is not bad, but it is not a silver bullet. Calling MVC an ultimate solution to UI is oversimplification. Just looking at the steps you listed I can ask:

How do you collect all notifications on step 2 to fire them on step 3 such that UI does not re-render itself too much? E.g. updating a title of each item in a list of 100 items should not trigger 100 renders. Or 100 layout calculations (which I think is harder to avoid).

How do you deal with situations where on step 4 UI triggers an event that your model happens to listen and the cycle repeats while killing performance?

Because you rely on events how do you avoid “event hell”? That is, a situation when an event handler triggers a change that triggers another event handler that triggers a change and so on. Sometimes it is scrolling or typing, sometimes it is parts of the model subscribed to each other bubbling events to UI.

Famous UI = f(Model) is oversimplification that was sold in slides. Real “functional UI” frameworks implement UI = f(Model, UIState) where UIState is scroll and cursor positions, view pool for virtualization, rendering caches, etc. USState is mutable and managed by the framework and the rendering engine (e.g. React + DOM, SwiftUI + UIKit + CoreAnimation). I don’t see a problem with functional approach as in React. I do see a problem with understanding of how UIState being managed between framework, ui library and rendering engine.

No, but the project does not meet its goals around memory safety. It is usage Rust all the way down with same memory safety issues.

Yes, bonds, sometimes corporate debts, often money market participation.

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.

This is from PR: v1 collects synchronous and stop-the-world

Go build performant web app that has stop-the-world all the time.

Except there is often no background thread but async IO.

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.

If the goal of this change is to:

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

While being widely criticized I don’t get it > Physical controls for temperature and fan speed.

I have set temperature to 21 C in Tesla when I bought it and never changed since. Why would anyone frequently change a thermostat set temperature?

I think this is the glimpse of what to come - https://github.com/oven-sh/bun/issues/31463

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.

I’m genuine curious how this will unfold.