Why can't it be the opposite? Why can't I expect an update to run faster than the previous version?

But I wish we'd just make fast GUIs instead of giving up and building TUIs instead.

It's not enough to turn me off using it, but I do wish they prioritized improving their interface.

I view Zig as a better C, though that might be subjective.

https://github.com/kaitai-io/kaitai_struct_compiler/commits/...

It would be premature to review now because there are some missing features and stuff that has to be cleaned up.

But I am interested in finding someone experienced in Zig to help the maintainer with a sanity check to make best practices are being followed. (Would be willing to pay for their time.)

If comptime is used, it would be minimal. This is because code-generation is being done anyway so that can be an explicit alternative to comptime. But we have considered using it in a few places to simplify the code-generation.

The thinking was to minimize the the places where a secret could leak. So with an HTTP client, I would think at the lowest layer possible.

I don't think of it as a way to eliminate secrets leaking. More-so reducing the surface area of accidental leaks.

Something like: my_secret = create_secret(value)

Then ideally it's an opaque value from that point on

Ultimately, you're going to revisit this code to make the change after some time passes. Is it easy to follow the code and make the change without making mistakes? Is it easy for someone else on the team to do the same?

Sometimes optimizing for "easy to understand and change" means breaking something apart. Sometimes it means combining things. I've read that John Carmack would frequently inline functions because it was too hard to follow.

So, rather than whether something is big or too small, I would ask whether it would be easy to understand/change when coming back to it after a few months.

Put another way: why not optimize for the actual thing you care about rather than an intermediate metric like LOC?

With all the other crazy shit people are doing (multi-megabyte bundle sizes, slow API calls with dozens of round-trips to the DB, etc) doing the basics of profiling, optimizing, simplifying seems like it'd get you much further than changing to a more complex architecture.

Right now innovation moves at a slow pace the web nobody seems to realize the what-if. The W3C announces some incremental improvement to JS feature and everyone gets excited. It just reminds me that all we realistically have is JS.

There are so many hacks on top of hacks. Typescript compiles to JS because, well, you only have JS. So many attempts at compile-to-JS languages. There are dozens of problems that should not exist.

Meanwhile in the native world, you have huge a diversity of programming languages and tooling. No committee is needed for each language to experiment with new features.

The unfortunate part is that the envisioned browser would have been far simpler to implement and more extensible than the mess we have now.

it's common that the part that I actually need is like 100 LOC rather than 1500 LOC.

Please keep preaching.

But I lament these blurred lines of reality. Is this photo real? Was this reply ChatGPT or did they actually write it?

It makes me feel uneasy.

So hyperlinks were good but the rest was a bad design. An HTML viewer and Javascript interpreter would have just been one possible app to run in the browser.

It is a shame that, to this day, the browser can't easily handle running arbitrary applications. You're still effectively locked into JS/HTML.