Thanks so much for great work! I hope to finally see VisionFive 2 with enabled GPU acceleration soon.

...and it does not work. I tried it on ~10 random pdfs, including very simple ones (e.g. a hello world from typst), it segfaults on every single one.

   ~/c/t/s/zpdf (main)> zig version
   0.15.2

Sky is blue, water is wet, slop does not work.

+1, SREs can spend months during their onboarding basically reading design docs and getting to know about services in their vicinity.

Short of publicly releasing all internal documentation, there's not much that can make the AWS infrastructure reasonably clear to an outsider. Reading and understanding all of this also would be rather futile without actual access to source code and observability.

Considering that D in "ACID" stands for "durable", it's a pretty sloppy joke.

What's great about its type system? I find it severely limited and not actually useful for conveying and checking invariants.

> pass around the allocator to every function that allocates to the heap.

what prevents a library from taking an allocator, saving it hidden somewhere and using it silently?

Nothing, but it would be bad design (unless there is a legitimate documented reason for it). Then it's up to you as the developer to exercise your judgment and choose what third-party libraries you choose to depend on.

authors of the library

So far, most of Zig enthusiasts look to me like people who get sugar rush from writing fast native code and are ignorant (i.e. newcomers to system programming) or arrogant (e.g. long time C programmers stubbornly stuck in their ways) enough to think that memory safety is just a question of not writing stupid bugs. Or luddites that think that programs must always be simple enough to get memory safety right.

Fits perfectly on my understand as well.

Actually, the strong type system is often why people like to write Rust. Because encoding logic invariants in it also helps to prevent logic bugs!

There is a significant crowd of people who don't necessarily love borrow checker, but traits/proper generic types/enums win them over Go/Python. But yes, it takes significant maturity to recognize and know how to use types properly.

To the extent that one of the most common things rust users wish for is Rust, but without the borrow checker.

Humans still have to state the goal and write a proof of it, but the proof is computer-verified. It's not irrelevant, except in the sense that any two different ways to prove the same statement are equivalently valid proofs.

Show us the way!

Form a design team to reduce the amount of primitives in html such that I can do everything that html + css does but with the minimum amount of primitives.

Something tells me with that approach you'd get emergent complexity that different people handle in a different manner, eventually leading to strong incentive to add new, higher level primitives. That's one of driving forces behind current state of HTML and JS and why JQuery and TABLE layouts went out of fashion. Sounds like a people thing, not a technical one.

There will always be stronger incentive to create higher level entities.

It’s just you need to create an initial set of primitives such that those higher level entities can be formed as a composition of the initial set of primitives.

So maybe not even start with html. Create the set of primitives such that I can create custom tags that does exactly what html does.

Like react is the sort of a framework that allows for composition of tags. But the problem is we have too many primitives.