I happen to work on a product that is built for accountants. You would not believe how slow these apps are and all they do is display forms!

I believe customers do care about performance even in these B2B industries.

But it feels like they sink into some form of learned helplessness. We were interviewing our customers to learn how to build a better PDF viewer for them. Their biggest complaint had about Adobe Acrobat? Too slow!

https://diffshub.com/oven-sh/bun/pull/30412

Compare that to this:

https://github.com/oven-sh/bun/pull/30412/changes

I agree there are limitations bc of physics, but I don't think it explains this particular difference.

I think my point still stands that, if MSFT cared, it would be fast. The issue is not the technology choice in this case.

For example, look at their demo here: https://diffshub.com/oven-sh/bun/pull/30412

It's way faster than GitHub and you check the network tab.

Even if they were to write for two platforms, they'd likely want to have a whole bunch of business & state management logic that would be shared between the two with the native part being a thin platform layer.

It seems like a mostly shared codebase (reglardless of specific tech choice) would let them get precisely the end user UX they care about. Both for performance and capability.

Not saying they should use React Native but maintaining two large apps and using LLMs to keep them in sync seems far worse than many other options.

For example https://diffs.com/ is built in React and it's basically instant.

Tailwind saved me time and the pain of writing CSS so I paid for it.

The history of Elixir has its roots in Jose learning Erlang, loving the properties BEAM, but wanting a different language.

All of the principles of the BEAM still exist in Elixir. And a lot of the Elixir semantics come from Erlang, precisely because Jose studied Erlang and the BEAM.

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