vendiddy

For me, I start reading and realize I have no idea what they're talking about.

I'm on your side regarding this sentiment.

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!

But this is way faster than GitHub isn't it:

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.

Ok I stand corrected. Some have mentioned the React layer is very thin it's mostly vanilla JS!

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.

I agree with you. I don't think LLMs magically solve the problem that comes with writing twice.

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.

I would attribute that more to culture.

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

Maybe you're overthinking this?

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

We're talking about MSFT here. I think they can afford whatever Cursor can. They're just not taking reliability seriously.

Dang... I use zig at work to write single binary apps and I know what a floppy is. I feel personally attacked.

This seems like a good idea to me. I wonder what the hold up is.

I don't think this is true.

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.

I've come to expect that, every time I update and OS or app to a newer version, it's going to be slower and more bloated.

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

I feel like they are a workaround to GUIs being slow and bloated Electron apps.

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

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.

Giving the AI an actual programming language (functions + objects) genuinely does seem like a good alternative to the MCP mess we have right now.

Demented AIs running amock is just what we need in this day and age.

We've recently adopted Zig at a few systems at our company but I think maybe "cool" or "new" is the wrong metric?

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

It is not yet ready but the master branch has an initial draft.

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.

Just seeing this now.

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.

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!

Not an answer, but I do wish there was a low level primitive and a corresponding high level language construct to pass around secrets.

Something like: my_secret = create_secret(value)

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

I think this is spot on. A document metaphor would have made a Wave a lot easier to understand.

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?

I think it's a valid question, but it's better to assume they had their reasons and try to understand why before drawing conclusions.

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.

how about "NotExpert"

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 find if I read the source code of a dependency I might add,

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

Please keep preaching.

And if you really do? Print the percentage to stdout.

I generally love AI.

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.