Comment by paxys | Hacker News Reader

Comment by paxys | Hacker News Reader

On one hand, these machines are clearly superior, and it's a no brainer for companies to purchase them for development. On the other, this is just another one in the long line of examples of bad software practices being overcome by throwing more money and hardware at the problem. Is there any reason for an iOS app build to take 8+ minutes to begin with? And does anyone realistically believe that once all developers have these shiny new computers build time won't creep up again till everyone starts demanding M2 and M3?

This problem extends to the consumer side as well. Developers use expensive MacBooks and fiber internet connections and the end user has a laggy experience running the hundreds of megabytes of JavaScript on an average site. The user has no choice but to upgrade their computer, and then companies see the new spare CPU cycles and fill them up as well. The end result is that while hardware keeps getting ridiculously faster and more efficient, user experience doesn't noticeably improve.

It is just Writh's Law (https://en.wikipedia.org/wiki/Wirth%27s_law) in action.

Yeah that's about it.

What I find really offensive, which my Mac likes to remind me of regularly on the energy usage side of things, is the siloed vats of excrement that JavaScript, Browsers and Electron have enabled. These are absolutely horrible to use compared to native applications and each one has its own ozone hole above it. If I don't open a browser or Electron app my battery lasts 2x as long.

I do the occasional bit of Swift with XCode just for fun and to concentrate on that case really does disservice to the real elephant in the room above because at least Swift is not burning the universe to the ground and recompiling bits of it every time you click something. When you're done it's native.

Edit: personal wastage shitlit: Lens, Discord, Teams, Slack, VScode. VScode gets a pass as it doesn't annoy me as much as the others.

Teams is the worst offender: it will single-handedly cycle my battery on a medium-long video call.

That’s just battery usage, not even touching on general performance, how buggy the app is in general.

It's not that bad on my M1 MacBook Air to be fair. I had to do a training session which was 3h long on Teams and it ate 20% of the MBA's battery.

It was horrible on the previous Intel i5 MBP though.

I refused to install it on my M1Pro MBP!

Honestly the worst performing app ive ever used in my life. It makes any machine running it slow as shit.

When someone is sharing video / screen share its even worse.

I absoutely cannot fathom how it passes any form of QA.

100% This is the new Flash that Steve Jobs successfully railed against ruining the battery life and performance of Macs back in the day - https://youtu.be/EMXwa9EtehE. And things got soo much better for awhile when that went away.

I feel with JavaScript and especially everything being Electron (I shudder to think how many copies of Chromium I am running at the moment) we've backtracked back to those days - but worse.

Look at the bright side: bad/lazy software helps the world develop faster computers that can be used efficiently for "real" projects (i.e scientific research). If the computers would be "fast" enough there would be no incentive to make them faster and we would never reach singularity

It's also probably just the most efficient use of time and resources. "The market" could chose to optimize the last drop of speed out of millions of bits of software, or improve the speed of a handful of chips which benefits those million bits of software.

Your argument is more or less a critique of Swift itself, which is a far more full-featured and "safe" language than Objective-C, at the expense substantially higher compilation times given otherwise like-for-like programs.

You're not necessarily wrong, but that ship has sailed for iOS development long ago and isn't necessarily the fault of teams like Doordash who have probably (like others) already squeezed as much build-time performance out of their given app size and feature set.

Mobile apps are inherently monoliths, and there is unfortunately no real way around some code changes triggering full rebuilds of millions of LoC.

Definitely will echo this. The app I work on is probably a lot of bloat which the op is complaining about but compared to the last app I worked on it's quite a bit less and compiles at least 5 times more slowly due to using swift where as the last project was 100% obj-c. Even if we could somehow manage to convince management to let us clean up the app we'd still be at the mercy of however long the swift compiler takes.

Don't use type inference, and modularize the codebase into separate static libraries. That should reduce the amount of full rebuilds, and should make builds faster. (ETA: also try to avoid generics.)

Ofc, probably a lot harder to go back and redo a huge legacy codebase where you still have new deadlines to meet, but for folks just starting out, these should be guiding principles in a Swift codebase if you care about compilation time.

This reminds me of the same phenomenon that occurs in traffic planning[0]

[0]: https://www.vtpi.org/tdm/tdm64.htm

Briefly, as impediments to congestion are introduced (bike lanes, tolls), individual cars either join or leave the traffic system until the delay for cars reaches a rough equilibrium based on what people will tolerate.

Seems the same is true for computing capacity.

This may be true of 50-in-one megaprojects such as those from the likes of Uber and Google, but these machines are also beneficial to developers of more lean, focused, and optimized apps too. The few seconds my M1 Pro shaves off of incremental builds and the general improvements in IDE responsiveness compared to an upper-spec Intel mac pile up and become worth it quickly, not even mentioning quality of life improvements like far better battery life and being able to use the laptop in my lap comfortably.

For the projects I work on, compile time has been declining with each hardware gen despite app complexity increasing significantly. I’m sure there are other devs who this is true for too. We’re not all 5 abstractions deep and nonchalant about heavy resource usage and bad engineering.

> far better battery life and being able to use the laptop in my lap comfortably

These are the mains reasons I sold my 2015 MBP to get the M1 Air. I was not doing anything computationally heavy, so I don't notice any performance improvement. But the Air never get hot. And the battery usage is so light that I don't worry over its charge status.

> Is there any reason for an iOS app build to take 8+ minutes to begin with?

The speedup isn't limited to iOS app builds. For instance, at Reddit:

>We recently found that the new 2021 M1 MacBooks cut our Android build times in half.

https://twitter.com/softwarejameson/status/14559711620606976...

I guess Wirth was still not cynical enough because even he couldn't foresee that developers would deliberately break and degrade a working, fast application (namely, the website experience) just so they can go and write two separate, bloated applications that do somewhat the same but not really. Only to then complain about build times of applications that didn't need to exist in the first place.

Developers dont make those choices.

The user does have a choice: do not use crappy slow services. For example I stopped using Instacart because there was a long lag each time I typed a single character is the search box. Amazon and Peapod did not have this problem.

that is such a rookie mistake if they are doing searching immediately on inputs! debounce it ffs! i hope that was it and not general ui slowness

Yep agree, having spent some time digging into why Xcode builds are slow it looks like low investment is a major reason. The tooling and optimizations are fairly primitive compared to other ecosystems and harder to get right where they do exist. It’s just not a priority it seems, likely because new features win out.. and selling new hardware “solves the problem”.

Reply on news.ycombinator.com