11–20 of 40 posts
Which is why Zig's top feature on its webpage is "No hidden control flow."
https://bun.sh/blog/bun-in-rust
So sometimes hidden control flow is needed.
Which is why Zig's top feature on its webpage is "No hidden control flow."
Ironically, the 'no hidden control flow' was one of the arguments against Zig in the recent Bun rewrite to Rust. https://bun.sh/blog/bun-in-rust So sometimes hidden control flow is needed.
Which is why Zig's top feature on its webpage is "No hidden control flow."
Ironically, the 'no hidden control flow' was one of the arguments against Zig in the recent Bun rewrite to Rust. https://bun.sh/blog/bun-in-rust So sometimes hidden control flow is needed.
Yeah, but that makes sense: if you want "hidden everything", which they appear to want due to now having a code base that has never been read by a human, then a subset of "want everything hidden" is "want control flow hidden".
Earlier quoted context omitted.
Ironically, the 'no hidden control flow' was one of the arguments against Zig in the recent Bun rewrite to Rust. https://bun.sh/blog/bun-in-rust So sometimes hidden control flow is needed.
> Ironically, the 'no hidden control flow' was one of the arguments against Zig in the recent Bun rewrite to Rust. Yeah, but that makes sense: if you want "hidden everything", which they appear to want due to now having a code base that has never been read by a human, then a subset of "want everything hidden" is "want control flow hidden".
Every time I want to interact with zig code I just have the AI do it since I honestly can't be asked to change 3 lines and around 3 to 5 characters when it's a single keybind in every other language which in turn has lead me to experiment quite a lot 'writing' in zig. It's rather pleasant to look at, however, I wouldn't want to write code myself.
Rust is by far the most enjoyable dx experience since everything usually 'just works' across machines and even architectures while having a strong sense of assurance that compiled applications will work as expected before ever running them once. node/bun/whatever is probably the worst here since compilation means nothing for runtime as undefined symbols will happily 'compile' (transpile?).
The biggest performance bomb you can have in your code is a loop that does something like for (...) { el.style.height = `${something}px`; whatever.value = el.style.offsetHeight; } This forces the browser to recalculate layout multiple times in a single frame. Separating layout changing code from measurement code will help a lot here (most frameworks out there have solved this so we don't have to be too concerned abou…
Earlier quoted context omitted.
Ironically, the 'no hidden control flow' was one of the arguments against Zig in the recent Bun rewrite to Rust. https://bun.sh/blog/bun-in-rust So sometimes hidden control flow is needed.
That tells you more about the people writing Bun than it does Zig or what's "needed" for people actually writing and reading code. Bun dev is not just hiding the control flow, their goal is to hide all of the code so that no human reads it, ever.
Even without this performance hit, an often used way for implementing 'auto scroll to top/bottom' is to first check if there's no other stuff coming in before starting to actually scroll. This goes unnoticed by the user but drastically reduces the number of updates (and in this case, number of calls to scrollHeight) needed when a lot of data is coming in in batches. Principle is like: receive message, add to buffer a…
Even without this performance hit, an often used way for implementing 'auto scroll to top/bottom' is to first check if there's no other stuff coming in before starting to actually scroll. This goes unnoticed by the user but drastically reduces the number of updates (and in this case, number of calls to scrollHeight) needed when a lot of data is coming in in batches. Principle is like: receive message, add to buffer a…
[0] https://developer.mozilla.org/en-US/docs/Glossary/Debounce
Um, what readonly property?