My biggest complaint about ChatGPT is how slow their interface is when the conversations get log. This is surprising to me given that it's just rendering chats.
It's not enough to turn me off using it, but I do wish they prioritized improving their interface.
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.
It's not C but we have sponsored a Zig target for Kaitai. If anyone reading this knows Zig well, please comment because would love to get a code review of the generated code!
If you are breaking something up for "long" and "short" you're optimizing for the wrong thing. You don't care about code being short for its own sake or long for its own sake right?
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?
And even if you fall under the first category, I find it hard to believe that the performance bottleneck is solved by using Vercel and SSR.
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.
Yes we have. I don't know why you got so much pushback.
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.
I can't remember who I read this from (it might have been Alan Kay) but they basically said the web browser should have been an address bar with the ability to run any sandboxed applications in the screen below. They said the internet well designed but the browser was a disaster.
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.
Why can't it be the opposite? Why can't I expect an update to run faster than the previous version?