Live data from Hacker News

Ode to the M1

fabiensanglard.net

61–70 of 286 posts

Re: Ode to the M1

#61

Still running a M1 Air 13“, now into my third job since, and refusing to bother with company provided computers. Still feeling as great as 3 years ago… will only upgrade if the next gen is substantially better (read: not just %faster somewhere). Can comfortably develop on my lap for a full day if needed, only MS Teams draws power like crazy, but apart from that 8 hours+. Best computer I ever had I think.

I'm a bit confused by the "still". How often would you expect to upgrade hardware? Keeping a computer for three years is completely normal for most people.

I upgrade every 2-3 years. Although current device is first macbook so maybe i'll break that (+ an M1)

Re: Ode to the M1

#62
post #17

> Software "engineers" > For every extra cycle an hardware engineer can squeeze out of silicon, you will find a programmer adding one hundred cycles to their program[6]. In other terms, I fear that once devs figure out how powerful the M1 is, they will throw more "features" at it. Can we please stop replicating the "growth" fallacy into software ecosystems? Haven't we learnt enough about how unsustainable and damagin…

> I hope Electron/CEF die soon, and people get back to building applications that don't consume hundreds of megabytes of RAM to render a hello world. Web technologies are fine, but what we really need is some kind of lightweight browser which allows you to use HTML/CSS/JS, but with far lower memory usage. I found https://ultralig.ht/ which seems to be exactly what I am looking for, but the license is a major turn off…

What I'd really like to see with CEF et al, is JS being dropped, in favor of directly controlling the DOM from the host language. Then we could, for example, write a Rust (or Kotlin, Zig, Haskell, etc) desktop application that simply directly manipulated the DOM, and had it rendered by a HTML+CSS layout engine. Folks could then write a React-like framework for that language (to help render & re-render the DOM in an elegant way).

Ultralight (https://ultralig.ht/) looks pretty cool. I think another possible option is Servo (https://github.com/servo/servo) – it was abandoned by Mozilla along with Rust during their layoffs a while back (but the project still seems to have a decent bit of activity). It would be great if some group of devs could revive the project, or a company could fund such a revival.

Eventually, we'll need to reflect on, and explore whether HTML+CSS is really the best way to do layout, and we could maybe perhaps consider porting the Android/iOS layout approach over to desktop. Maybe WPF/GTk/Qt/etc even got things right, and HTML+CSS isn't the best way to do layout.

Re: Ode to the M1

#63
post #39

Earlier quoted context omitted.

Decenter developers can do that with a magnetized needle and a steady hand

I wonder if there is a name for the idea that the more you earn the lazier you get. Sysadmins used to know a lot but earn pittance compared to “devops” or “SRE”; then those more expensive folks outsourced the majority of their hard work to cloud vendors who charge 5-11x the cost for compute. Developers earn 5-10x more than 15 years ago, yet continue to choose solutions for their own convenience and time saving. Stati…

Because they -are- providing value, and because dev resources are limited. If you're a dev, do you think your company would want you to spend 2 weeks on building a new feature, or on "considering the entire ecosystem"?

And more than that - if you have a team that only/mostly has web experience, they're going to use Electron, and... what kind of company would want them to stop and go learn native app development, or hire extra people just to get a native app?

Note: I fully agree with you, I do feel that as a profession we really have descended into a weird "ship the MVP, ship new features non-stop, forget quality" reality, and I dislike it. I'd love it if everything was resource-thrifty native apps, and dev teams could stop chasing new and shiny things and work on improving their existing apps until they were shiny polished diamonds. I'd love to point to an app and say "see? this is 20 years of development, look at how nice it is, how perfectly thought out everything is, how everything just works flawlessly".

But the fact that that's not happening is not because devs are lazy, or not worth their money. It just doesn't make business sense.

Re: Ode to the M1

#64

I like UTM too. I must be doing something wrong though. I created both X86 Ubuntu and Debian 10 VMs. They are usable, but not quick. I have been blown away how fast Rosetta 2 x86 programs run my m1. The arm embedded gcc too chain compile code 4x faster than the native x86 MBPro from a year or so ago. But the UTM VMs run about 3x slower.

You can't run x86 Linux quickly on macOS. What you can do is to run ARM Linux quickly on macOS and run x86 programs inside of that Linux with Rosetta quickly.

Am I missing something? Is this quicker just because you are emulating only the program and not the OS?

Re: Ode to the M1

#65

Still running a M1 Air 13“, now into my third job since, and refusing to bother with company provided computers. Still feeling as great as 3 years ago… will only upgrade if the next gen is substantially better (read: not just %faster somewhere). Can comfortably develop on my lap for a full day if needed, only MS Teams draws power like crazy, but apart from that 8 hours+. Best computer I ever had I think.

What do you mean still? They’re only a few years old at this point. It shouldn’t be impressive that a basically new computer still does everything that one would want to do.

It’s not a great thing, but most companies supply employees new laptops every 3 years if they want to keep those employees.

Re: Ode to the M1

#66
post #30

Earlier quoted context omitted.

The majority of users who own an M1 are never going to push it to 100% utilisation. So whether their productivity app is written in Electron or hand-crafted assembler isn't going to make much of a difference to the end user experience. Electron and similar apps serve a legitimate purpose in the marketplace which is to allow developers to deliver a cross-platform app for the same cost as a single platform one.

Decent developers can do that in C++

Sure, if they're calling into an Electron front-end. Otherwise, each front-end is different so no amount of C++ and dev exeperience is going to take your Android UI calls and transform them into iOS UI calls. So, you'll have to build your own wrappers over each native UI framework to interact with, costing more money.

Re: Ode to the M1

#67
post #30

Earlier quoted context omitted.

The majority of users who own an M1 are never going to push it to 100% utilisation. So whether their productivity app is written in Electron or hand-crafted assembler isn't going to make much of a difference to the end user experience. Electron and similar apps serve a legitimate purpose in the marketplace which is to allow developers to deliver a cross-platform app for the same cost as a single platform one.

Decent developers can do that in C++

Decent developers don’t leave comments like this about other developers.

Re: Ode to the M1

#68
post #59
post #50

Earlier quoted context omitted.

True… here I’m going wondering if it’s time to upgrade my 2017 MacBook Pro because a couple of keys started to fail and I’m having a hard time…

I am using my Dell XPS 13 now for almost ten years. Still works perfectly.

I have a 10 year old MacBook Pro that works perfectly too. Unfortunately, Apple doesn’t allow OS upgrades.

I’ll probably get an M3 and use it for 8-10 years.

Re: Ode to the M1

#69
post #17

> Software "engineers" > For every extra cycle an hardware engineer can squeeze out of silicon, you will find a programmer adding one hundred cycles to their program[6]. In other terms, I fear that once devs figure out how powerful the M1 is, they will throw more "features" at it. Can we please stop replicating the "growth" fallacy into software ecosystems? Haven't we learnt enough about how unsustainable and damagin…

Electron is quite efficient. You get a modern GPU composited UI, and JavaScript is by far the most highly optimized scripting language out there.

The problem with Electron is RAM, disk space, and download size, which is because every app needs to ship its own copy of Blink. This is a solvable problem, but nobody is incentivized to solve it.

Re: Ode to the M1

#70
post #17

> Software "engineers" > For every extra cycle an hardware engineer can squeeze out of silicon, you will find a programmer adding one hundred cycles to their program[6]. In other terms, I fear that once devs figure out how powerful the M1 is, they will throw more "features" at it. Can we please stop replicating the "growth" fallacy into software ecosystems? Haven't we learnt enough about how unsustainable and damagin…

The majority of users who own an M1 are never going to push it to 100% utilisation. So whether their productivity app is written in Electron or hand-crafted assembler isn't going to make much of a difference to the end user experience. Electron and similar apps serve a legitimate purpose in the marketplace which is to allow developers to deliver a cross-platform app for the same cost as a single platform one.

> whether their productivity app is written in Electron or hand-crafted assembler isn't going to make much of a difference to the end user experience

Subjectively, every Electron app I’ve used including the local beloved VSCode has been a painful UX. I can always tell. Nothing makes a fast computer feel slow quite like them, it’s amazing. I would settle for React Native at this point.

Post reply on HN