Comment by Aurornis

> If you want to make something that starts instantly you can't use electron or java. You can't use bloated libraries. Because users do notice.

Most users do not care at all.

If someone is sitting down for an hour-long gaming session with their friends, it doesn't matter if Discord takes 1 second or 20 seconds to launch.

If someone is sitting down to do hours of work for the day, it doesn't matter if their JetBrains IDE or Photoshop or Solidworks launches instantly or takes 30 seconds. It's an entirely negligible amount.

What they do care about is that the app works, gives them the features they want, and gets the job done.

We shouldn't carelessly let startup times grow and binaries become bloated for no reason, but it's also not a good idea to avoid helpful libraries and productivity-enhancing frameworks to optimize for startup time and binary size. Those are two dimensions of the product that matter the least.

> All else equal users will absolutely choose the zippiest products.

"All else equal" is doing a lot of work there. In real world situations, the products with more features and functionality tend to be a little heavier and maybe a little slower.

Dealing with a couple seconds of app startup time is nothing in the grand scheme of people's work. Entirely negligible. It makes sense to prioritize features and functionality over hyper-optimizing a couple seconds out of a person's day.

> As somebody on Twitter pointed out, a debug build of "hello world!" in Rust clocks in at 3.7mb.

Okay. Comparing a debug build to a released app is a blatantly dishonest argument tactic.

I have multiple deployed Rust services with binary sizes in the 1-2MB range. I do not care at all how large a "Hello World" app is because I'm not picking Rust to write Hello World apps.