That's only true in theory. In practice, you'll be rate-limited first. Even if you aren't, the database won't be the bottleneck because SQLite is so fast. Their Ruby on Rails stack will suffer thread starvation way before the WAL grows. Rapid requests still leave microsecond gaps between context switches for SQLite to run an automatic checkpoint. To actually make SQLite stall, you'd need an endpoint that lets you hold a massive write transaction open indefinitely, which lobste.rs doesn't expose anyway (I hope).
> Just search "segfault" on the Zig issue tracker and you'll see why people are starting to be skeptical of the future utility of such a language in the face of something like Rust.
Zig has 110 open "segfault" issues [1] versus Rust's 175 open "segfault" issues [2]. So, by your logic, Rust is also bad.
edit: I was just trying to point out that the parent's "just search segfault" argument is lazy. Also, Zig is still in beta.
I don't use typing for correctness. I use it for documentation. That's why I prefer JSDoc these days. I only type top-level variables/functions to get hints from my editor. Everything inside a function body remains untyped unless necessary. It’s the benefit of using Typescript without being forced to write dumb code just to satisfy the compiler.
Agreed. It's not just a placebo effect, it really is slower. People often don't notice this because they use relatively high-end machines. If you're skeptical, try running it on a low-end laptop or a Raspberry Pi. The difference is like night and day.