qouteall

It's probably due to server side rendering and rehydration. The rehydration use server side component state to override DOM state.

With modern IDE and AI there is no need to save letters in identifier (unless too long). It should be "sizeInBytes" instead of "size". It should be "byteOffset" "elementOffset" instead of "offset".

Normally the database and message queue is decoupled from the backend service. This decoupling makes managing simpler and make cross-language things easier.

But if the type system need to cover all these components, then they start coupling again.

Coupling is not necessarily a bad thing as long as it gives good developer UX. If the database is tightly coupled with programming language, then it looks like ORM but better. And it probably can also reduce CRUD biolerplate or N+1 issue etc.

Related, there is SpacetimeDB that make backend run within database, and the backend code is highly coupled with SpacetimeDB's own API

WebAssembly standard design has considered binary size optimization. The format itself is quite compact. But porting native code to Wasm often brings many large existing libraries which contain a lot of code which makes the binary large.

The native ecosystem never payed attention to binary size optimization, but the JS ecosystem payed attention to code size in the very beginning.

They originally used JS realm polyfill, which is not real JS realm. The polyfill has some security holes. Now they switched to Js interpreter in Wasm.

https://www.figma.com/blog/an-update-on-plugin-security/

I've written about limitations of WebAssembly https://qouteall.fun/qouteall-blog/2025/WebAsembly%20Limitat...

WebAssembly still doesn't provide a way to release memory back to browser (unless using Wasm GC). The linear memory can only grow.

The Wasm GC limits memory layout and doesn't yet support multi-threading.

Wasm multithreading has many limitations. Such as cannot block on main thread, cannot share function table, etc. And web worker has "impedance mismatch" between native threads.

And tooling is also immature (debugging requires print debugging)

One limitation of Rust macro is that it can only access code token, not actual type information.

When macro sees a type `X` macro can never be sure whether it's `&str` as Rust allows type alias. If `X` is not `&str` it may also be a struct that contains `&str`, still macro cannot know.

Wasm-bindgen workarounds this issue by generating "fake functions" then read and remove them in CLI:

https://wasm-bindgen.github.io/wasm-bindgen/contributing/des...

Zig comptime allows getting full type information. This is one advantage of Zig.

The optimistic concurrency control that reads multiple shards cannot use simple CAS. It probably needs to do something like two-phase committing

Thanks for reply.

So in my understanding:

- The transactions that only touch one shard is simple

- The transactions that read multiple shards but only write shard can use simple optimistic concurrency control

- The transactions that writes (and reads) multiple shards stay complex. Can be avoided by designing a smart sharding key. (hard to do if business requirement is complex)

In real-world business requirements it often need to read some data then touch other data based on previous read result.

It violates the "every transaction can only be in one shard" constraint.

For a specific business requirement it's possible to design clever sharding to make transaction fit into one shard. However new business requirements can emerge and invalidate it.

"Every transaction can only be in one shard" only works for simple business logics.

This video criticizes Rust using perfect solution fallacy. Critizing a useful thing just because it's imperfect.

https://en.wikipedia.org/wiki/Nirvana_fallacy

We are in the down season.

There are two kinds of slowness. One is trying hard while getting no visible result. Another is procrastination. The article refers to the first

The better phrase is that "if it compiles, then many possible Heisenbugs vanish"

https://qouteall.fun/qouteall-blog/2025/How%20to%20Avoid%20F...

I want to add Contagious Borrow Issue https://qouteall.fun/qouteall-blog/2025/How%20to%20Avoid%20F...

Contagious borrow issue is a common problem for beginners.

Lecture video https://www.youtube.com/watch?v=orDKvo8h71o

Goodhart's law: When a measure becomes a target, it ceases to be a good measure.

AI companies have high incentive to make score go up. They may employ human to write similar-to-benchmark training data to hack benchmark (while not directly train on test).

Throwing your hard problem at work to LLM is a better metric than benchmarks.

It's (at least) the second time Couldflage gets bitten by React. Last time an useEffect caused an incident.

https://blog.cloudflare.com/deep-dive-into-cloudflares-sept-...

Configuration complexity clock

https://mikehadlow.blogspot.com/2012/05/configuration-comple...

Can you provide the source of "(eg Android definitely has sanitizers running on every commit and yet it wasn’t until they switched to Rust that exploits started disappearing)"?

You can use Obsidian to edit markdown. Obsidian allows easy paste of images.

AI is really great at creating superficial signals. And most people just judge things by superficial signal.

There is borgo https://github.com/borgo-lang/borgo but it's not yet mature and not being actively developed

For example , if error data contains string, if it directly point to input string it won't require allocation, but will have memory safety issue if error is passed to outer scope where input string is deallocated. Many errors copy string to make it usable in outer scope.

I agree that building a special diagnostic system is better than just using language's builtin error system. However that takes efforts.

Library developers tend to choose the path of least resistance, which is to not pass diagnostic information.

The most convenient diagonistic system is the good old logging. Logging is easy.

Maybe logging will be the de facto solution of passing error data in Zig ecosystem, due to psychological reasons.

If the error rarely happens then passing error data shouldn't affect performance in visible way. If the error occurs in common path then it's designed wrongly.

I agree that in special states like OOM passing error data with allocation is not ok.

Changed to "valid reasons"

I know that Zig doesn't allow attaching data to error for valid reasons. If error data contains interior pointer then it can easily cause memory safety problem. Zig doesn't have a borrow cheker or ownership system to prevent that.

https://github.com/ziglang/zig/issues/2647#issuecomment-2670...

In my opinion the biggest issue of Zig is that it doesn't allow attaching data to error. The error can only be passed via side channel, which is inconvenient and ENOURAGES TOOL DEVELOPERS TO NOT PASS ERROR DATA, which greatly increase debugging difficulty.

Somethings there are 100 things that possibly go wrong. With error data you can easily know which exact thing is wrong. But with error code you just know "something is wrong, don't know which exactly".

See: https://github.com/ziglang/zig/issues/2647#issuecomment-1444...

> I just spent way longer than I should have to debugging an issue of my project's build not working on Windows given that all I had to work with from the zig compiler was an error: AccessDenied and the build command that failed. When I finally gave up and switched to rewriting and then debugging things through Node the error that it returned was EBUSY and the specific path in question that Windows considered to be busy, which made the problem actually tractable ... I think the fact that even the compiler can't consistently implement this pattern points to it perhaps being too manual/tedious/unergonomic/difficult to expect the Zig ecosystem at large to do the same

Simplify: tokio::select! will discard other futures when one future progress.

The discarded futures will never be run again.

Normally when a future is discarded it's dropped. When a future holding lock is dropped, lock is released, but it's passing future borrow to select so the discarded future is not dropped while holding lock.

So it leaves a future that holds a lock that will never run again.