14 ms·

Yeah, all this concern with scalability, portability and clean code, has created quite a dystopian software world. A world where software can barely fit in a s

Yeah, all this concern with scalability, portability and clean code, has created quite a dystopian software world. A world where software can barely fit in a single machine and can only scale up. In many cases, this software doesn't even do anything that is functionally different from 10 or 20 years ago, but it still consumes many more resources. A world where some websites still don't work properly across web browsers. Electron apps which should enable easier cross platform applications, don't (e.g. Microsoft Teams doesn't have feature or even UI parity in windows and linux). A world where clean code destroys performance, because the time of developers must be paid for by the company, but the costs of resource wastage are externalized. And there isn't even any evidence that these practices actually help to do what they are supposed to do!

kortex 5y ago
So what do we do about it? Even if Electron doesn't give feature parity across OSes, it still has some other huge wins. It allows you to use "webdev" talent to build guis, which are (I presume) easier to hire. They can use their favorite frameworks. It seems like SPA-esque-apps have some agility in development over other native approaches. It makes updates, CI/CD, and testing easier. Even if not prioritizing cross-platform, Electron has some serious appeal. What are my alternatives? Qt? Gtk? Native libraries?
- Wowfunhappy 5y ago
  > What are my alternatives? Qt? Gtk? Native libraries? I don't know what the development side is like, but as a user I do find Qt apps to be fairly nice. I also think Java (Swing) apps are basically fine. Java was "bloated" back in the day, but not relative to what else is in use today.
  - kortex 5y ago
    Hm, Jvm also gives access to Kotlin and Scala, I'll definitely have to look into it. Qt development can be excellent or nightmarish, sometimes both. I don't know enough to know why the disparity but I've been adjacent to teams that love qt and ones that loathe it. I'm guessing a big aspect is state management; qt predates the reactive revolution, and IIRC is prone (as is any gui) to callback hell.
    - ensiferum 5y ago
      Overall Qt is quite nice and works portably across platforms. You're right about callback hell but there's a fox for it. Personally I prefer to create a bunch of overloaded utility functions for different widgets and data types and in each utility function i use QSignalBlocker to make sure I'm not accidentally invoking any callbacks. I condiser any "raw" Qt "setXYZ" call to be a bug.
      - kortex 5y ago
        Huh, neat. What's a "fox" in this context? I tried searching "qt fox" and got some, ahem, less than salient results.
        deleted 5y ago
        [deleted]
        krylon 5y ago
        Typo for "fix" would be my guess.
  - danmur 5y ago
    Just as a fun test a while ago I made a small desktop app with scala and scalafx/javafx. It's not bad, gives you some of the nice things you get from js guis (reactive rather than loads of callbacks etc).
- danmur 5y ago
  It's a shame that cross-platform GUI toolkits seem to have fallen out of favour somewhat (as in, native toolkits like Qt or GTK). I wish it were not so. I can see why the electron route is so tempting, I just really hate them as a user. I wrote a bunch of GTK desktop apps with Python like 15 years ago and they were snappy and you'd never even know it was Python behind it, but I wouldn't do that now. Too hard to distribute, bindings a bit clunky, lots more cross-platform testing, it's hard to look at the relative levels of effort and not take the faster path.
  - beowulfey 5y ago
    I’m not one with much experience, but I rewrote my Qt based code for a small python app into C++ and the results were amazingly better. I would bet GTK might be similar!
  - api 5y ago
    Qt is pretty good, but honestly since React came out I can't code a GUI in any other way. Reactive is the way to do (application) GUIs, period, and anything else feels like clunky bug-prone spaghetti. I put application in parentheses because other paradigms may make sense for high performance rendering pipes like games. Honestly I don't think HTML5/CSS/JS is that bad as a pure presentation layer. It has warts as they all do, but it can be made to look decent and is fairly productive. The bloat is mostly the fault of Electron specifically. Tauri and Sciter are much leaner, in some cases leaner than Qt depending on the app.
  - jschwartzi 5y ago
    A Qt install with all the bells and whistles is about 500 megabytes, so it’s very comparable in size to Electron. Qml is a lot easier to develop in than Node+browser though.
    - thereddaikon 5y ago
      Size on disk isn't, or shouldn't be a problem today. In an ecosystem where there are games that take up over 100 gigabytes of storage, few apps should be large enough to make a user double take. CPU and Memory usage on the other hand can be serious concerns and one where Electron apps have a serious problem compared to traditional approaches.
- the__alchemist 5y ago
  > What are my alternatives? Qt? Gtk? Native libraries? Yes. You are not a Javascript Programmer, or a Frontend Programmer; Choose the right tool for each job.
heurisko 5y ago
> A world where some websites still don't work properly across web browsers. The situation today is vastly better than in the days of IE6. > A world where clean code destroys performance Clean code does not mean code that is not performant. In my mind, "clean code" is foremost small methods that do one thing, and are well-described. These small methods will often be optimised away, in the unlikely situation where they were the bottleneck in the first place. In my experience messy code "for performance" reasons was usually code that had claims to being "fast", but was often incorrect and hard to fix.
- elvischidera 5y ago
  It could be OP is referring to multiple layers of (unnecessary) abstraction. In Android land for example, there is a popular "clean" 3 layer architecture, where model classes are blindly mapped multiple times (even in cases where this is suboptimal). I have lost count of people building "clean" inefficient caching mechanism instead of just using an HTTP cache. Side note: I believe these things are useful in some situations. Maybe the solution is to have a smart compiler that compiles out these inefficiencies? Some (most?) apps are just skins around a database. Amazing what Facebook did with Messenger rewrite [0] Is there an incentive problem? Generally, people get bonuses/accolades for making a slow system fast, not for keeping a system consistently fast. I admit the former is easier to measure. 0 - https://engineering.fb.com/2020/03/02/data-infrastructure/messenger/ https://engineering.fb.com/2020/03/02/data-infrastructure/me...
  - handrous 5y ago
    Maybe it's my bias but I took "clean code" not in the traditional sense, but to mean insisting on patterns perceived to be "pure" or "clean" even when their application harms performance or isn't a great fit for the host language (ahem, JavaScript and functional + immutable-datastructure programming) and makes it even easier for devs to footgun into bad performance while staying "pure".
    - inamiyar 5y ago
      I don't think that's what they meant but it's a good point! I've seen embedded developers write some...truly terrifying code though.
thrwaeasddsaf 5y ago
> Yeah, all this concern with scalability, portability and clean code, has created quite a dystopian software world. I don't see it having anything to do with scalability, portability, or clean code. It's just cheap and (for the developers) convenient. Developers think that their software is a gift to the world, and simply getting it made (not matter how cheaply and craply and user-hostilely) is a net positive. (I wonder how many people use all these bloated things only because they pretty much have to, due to peer pressure, company requirements, etc.) It is possible to make software that scales, is clean, portable, and doesn't rely on massive bloat.
ajconway 5y ago
> In many cases, this software doesn't even do anything that is functionally different from 10 or 20 years ago, but it still consumes many more resources I would argue that in most cases the choice is not between fast, optimized and slow, unoptimized software. The choice is between having a functioning program (using a universal, "reasonably" efficient stack) and not having one at all (because the amount of resources it takes to develop a customized, low-level implementation is prohibitively high). A good example: https://www.youtube.com/watch?v=tInaI3pU19Y https://www.youtube.com/watch?v=tInaI3pU19Y A custom 3D engine performs immensely better than a comparable Unity project, but it took the author 3 to 4 times the effort.
thereddaikon 5y ago
I think scalability, portability and cleanliness is mostly talk. The reality is that browser based frameworks like Electron are popular because developers who only know js are cheaper and the first half of the lifecycle is cheaper and faster while the second half is often either dropped entirely or someone else's problem. Of course a JIT compiler will never be as performant as precompiled binaries, especially when its running in a full featured web browser that is packing functions that the developer neither needs nor is using.
- postalrat 5y ago
  The reason electron took off if because it was the first to offer an easy way to build cross platform apps. Something the systems guys have failed to deliver for many years.
  - handrous 5y ago
    There are tons of easy ways to build cross-platform apps, and have been for a long time. Extreme, very free-form customization of GUI elements so it looks & behaves exactly the way your marketing, branding, & web-design folks want down to the pixel on every platform, is what was hard before Electron. If you just wanted to deliver a GUI applications cross-platform, full stop, that's not something you couldn't do before, fairly easily, especially if Electron's performance and integration with its host platform is considered acceptable for what you're doing.
    - postalrat 5y ago
      What alternatives? How many of them include the web as a platform?
      - handrous 5y ago
        Java and its various GUI toolkits (again, especially if Electron's performance isn't bad enough that it's off the table). QT. TK. Wx. Delphi and some others if you didn't mind paying. Obviously none of them include the Web as a platform (unless you count Java applets, which you shouldn't since they're basically dead, even if they'd seem high-performance and quite nice compared to what we've replaced them with).
slumdev 5y ago
> Yeah, all this concern with scalability, portability and clean code, has created quite a dystopian software world. I don't think scalability, portability, and clean code are the enemy. C/C++ are as portable as they ever were, and Java/.NET provide higher-level abstractions that work across both Windows and *nix systems. Even Electron doesn't have to suck, in theory. The reason performance is bad these days is because developers are just bad. The number of developers doubles every five years. Ergo, half of all developers have less than five years of experience. The vast majority of them don't have a CS, CE, or EE degree. A large number of them went through bootcamps (which are an expensive version of the old "Learn VB in 21 Days!" books.) And they're all writing the Electron apps we love to hate.
- ensiferum 5y ago
  I think it's the growth in data that when combined with accidentally bad algos suddenly start to drag down the perf.
- staticassertion 5y ago
  As a college drop out I'm pretty sure I know more about writing efficient code than most CS grads - I've seen what gets taught, it's not impressive. I've also seen bootcamps (haven't attended, but friends have) and while they don't teach about efficiency, they're far more rigorous than college was. Anyway, I don't want to get into this really, but I found this part of your post to be annoyingly off-base, and I resent it. That said, I'm in agreement that most devs don't know much at all about performance. Frankly, we're told not to... it's a sad state. Performance is explicitly referred to as a last priority, the "optimization is the root of all evil" quote is completely taken out of context and parroted everywhere (go look up Knuth/Hoare's context if you haven't), etc. All that is to say, the issue is not specific to education but is an unfortunate part of engineering culture. We, as a large group, explicitly neglect performance and treat it as a dirty word. IMO we need a sort of performance revolution the way testing got one. I've written lots of software in a 'benchmark driven' way, and the results are extremely fast programs - I've gotten programs down from just under 1ms to a few dozen nanoseconds like that.
dahart 5y ago
> In many cases, this software doesn't even do anything that is functionally different from 10 or 20 years ago, but it still consumes many more resources. Which software exactly is functionally the same yet consumes more resources? Can you give some specific examples? Nah, having lived and written code through the last 20 years, I think this often repeated argument just isn’t true at all. I can see why it’s easy to jump to this conclusion and easy to believe, if you don’t know or don’t pay attention what’s under the covers. It’s easy to forget about all the conveniences you’ve gotten used to along the way. You wouldn’t agree the functionality is the same if you tried using software from 20 years ago. One easy to overlook difference is displays. It’s easy to forget that 20 years ago we had 800x600 screens, 24 bit color was not ubiquitous, and 60hz monitors were practically non-existent. Today 4K is normal, and combined with refresh rates and colors, we’re pushing upwards of 2 orders of magnitude more data to our screens. We have much better compositing, much better text and graphic rendering, better antialiasing, all around higher quality and faster rendering. YouTube and Netflix didn’t exist 20 years ago. Browsers were incredibly slow and couldn’t support streaming video or anything but the smallest of applications written in JavaScript. Localization didn’t exist, web analytics wasn’t really a thing, browsers didn’t run background tasks. > A world where some websites still don’t work properly across web browsers This specious framing might have you believe that web portability hasn’t improved that much, while in reality the difference in support for web standards has changed dramatically in the last 10 years. Supporting IE6 was a real and widespread problem for businesses compared to the few minor corner cases that are left.
- mirker 5y ago
  > Which software exactly is functionally the same yet consumes more resources? Can you give some specific examples? Operating systems, particularly Windows. Given fixed hardware, you cannot expect an operating system to continue working indefinitely.
  - moonbug 5y ago
    Whyever not.
    - 5y ago
supernovae 5y ago
This isn't a problem of clean code and software, its a problem of walled gardens.
einpoklum 5y ago
> Yeah, all this concern with scalability, portability and clean code, has created quite a dystopian software world. All of these three - when interpreted reasonably - coincide and even constitute performance improvements: * You make less assumptions, including regarding the speed of things, when you make your code portable. * When your code is clean, it's easier to generalize speed benefits rather than when you need to apply some ugly spaghetti hand-written optimization in 20 places. * Scalability means scaling up, out but also _down_ from the machine you're currently using. How else would you run your, say, distributed search web app on, say, a cluster of RPi 0's? ... Of course, if your approach to scalability and portability is to stick things in a container or vm, and manage a fleet of those, then yeah, that's kind of a problem.

kortex 5y ago

So what do we do about it? Even if Electron doesn't give feature parity across OSes, it still has some other huge wins. It allows you to use "webdev" talent to build guis, which are (I presume) easier to hire. They can use their favorite frameworks. It seems like SPA-esque-apps have some agility in development over other native approaches. It makes updates, CI/CD, and testing easier. Even if not prioritizing cross-platform, Electron has some serious appeal. What are my alternatives? Qt? Gtk? Native libraries?

Wowfunhappy 5y ago
> What are my alternatives? Qt? Gtk? Native libraries? I don't know what the development side is like, but as a user I do find Qt apps to be fairly nice. I also think Java (Swing) apps are basically fine. Java was "bloated" back in the day, but not relative to what else is in use today.
- kortex 5y ago
  Hm, Jvm also gives access to Kotlin and Scala, I'll definitely have to look into it. Qt development can be excellent or nightmarish, sometimes both. I don't know enough to know why the disparity but I've been adjacent to teams that love qt and ones that loathe it. I'm guessing a big aspect is state management; qt predates the reactive revolution, and IIRC is prone (as is any gui) to callback hell.
  - ensiferum 5y ago
    Overall Qt is quite nice and works portably across platforms. You're right about callback hell but there's a fox for it. Personally I prefer to create a bunch of overloaded utility functions for different widgets and data types and in each utility function i use QSignalBlocker to make sure I'm not accidentally invoking any callbacks. I condiser any "raw" Qt "setXYZ" call to be a bug.
    - kortex 5y ago
      Huh, neat. What's a "fox" in this context? I tried searching "qt fox" and got some, ahem, less than salient results.
      - deleted 5y ago
        [deleted]
      - krylon 5y ago
        Typo for "fix" would be my guess.
- danmur 5y ago
  Just as a fun test a while ago I made a small desktop app with scala and scalafx/javafx. It's not bad, gives you some of the nice things you get from js guis (reactive rather than loads of callbacks etc).
danmur 5y ago
It's a shame that cross-platform GUI toolkits seem to have fallen out of favour somewhat (as in, native toolkits like Qt or GTK). I wish it were not so. I can see why the electron route is so tempting, I just really hate them as a user. I wrote a bunch of GTK desktop apps with Python like 15 years ago and they were snappy and you'd never even know it was Python behind it, but I wouldn't do that now. Too hard to distribute, bindings a bit clunky, lots more cross-platform testing, it's hard to look at the relative levels of effort and not take the faster path.
- beowulfey 5y ago
  I’m not one with much experience, but I rewrote my Qt based code for a small python app into C++ and the results were amazingly better. I would bet GTK might be similar!
- api 5y ago
  Qt is pretty good, but honestly since React came out I can't code a GUI in any other way. Reactive is the way to do (application) GUIs, period, and anything else feels like clunky bug-prone spaghetti. I put application in parentheses because other paradigms may make sense for high performance rendering pipes like games. Honestly I don't think HTML5/CSS/JS is that bad as a pure presentation layer. It has warts as they all do, but it can be made to look decent and is fairly productive. The bloat is mostly the fault of Electron specifically. Tauri and Sciter are much leaner, in some cases leaner than Qt depending on the app.
- jschwartzi 5y ago
  A Qt install with all the bells and whistles is about 500 megabytes, so it’s very comparable in size to Electron. Qml is a lot easier to develop in than Node+browser though.
  - thereddaikon 5y ago
    Size on disk isn't, or shouldn't be a problem today. In an ecosystem where there are games that take up over 100 gigabytes of storage, few apps should be large enough to make a user double take. CPU and Memory usage on the other hand can be serious concerns and one where Electron apps have a serious problem compared to traditional approaches.
the__alchemist 5y ago
> What are my alternatives? Qt? Gtk? Native libraries? Yes. You are not a Javascript Programmer, or a Frontend Programmer; Choose the right tool for each job.

heurisko 5y ago

> A world where some websites still don't work properly across web browsers. The situation today is vastly better than in the days of IE6. > A world where clean code destroys performance Clean code does not mean code that is not performant. In my mind, "clean code" is foremost small methods that do one thing, and are well-described. These small methods will often be optimised away, in the unlikely situation where they were the bottleneck in the first place. In my experience messy code "for performance" reasons was usually code that had claims to being "fast", but was often incorrect and hard to fix.

elvischidera 5y ago
It could be OP is referring to multiple layers of (unnecessary) abstraction. In Android land for example, there is a popular "clean" 3 layer architecture, where model classes are blindly mapped multiple times (even in cases where this is suboptimal). I have lost count of people building "clean" inefficient caching mechanism instead of just using an HTTP cache. Side note: I believe these things are useful in some situations. Maybe the solution is to have a smart compiler that compiles out these inefficiencies? Some (most?) apps are just skins around a database. Amazing what Facebook did with Messenger rewrite [0] Is there an incentive problem? Generally, people get bonuses/accolades for making a slow system fast, not for keeping a system consistently fast. I admit the former is easier to measure. 0 - https://engineering.fb.com/2020/03/02/data-infrastructure/messenger/ https://engineering.fb.com/2020/03/02/data-infrastructure/me...
- handrous 5y ago
  Maybe it's my bias but I took "clean code" not in the traditional sense, but to mean insisting on patterns perceived to be "pure" or "clean" even when their application harms performance or isn't a great fit for the host language (ahem, JavaScript and functional + immutable-datastructure programming) and makes it even easier for devs to footgun into bad performance while staying "pure".
  - inamiyar 5y ago
    I don't think that's what they meant but it's a good point! I've seen embedded developers write some...truly terrifying code though.

thrwaeasddsaf 5y ago

> Yeah, all this concern with scalability, portability and clean code, has created quite a dystopian software world. I don't see it having anything to do with scalability, portability, or clean code. It's just cheap and (for the developers) convenient. Developers think that their software is a gift to the world, and simply getting it made (not matter how cheaply and craply and user-hostilely) is a net positive. (I wonder how many people use all these bloated things only because they pretty much have to, due to peer pressure, company requirements, etc.) It is possible to make software that scales, is clean, portable, and doesn't rely on massive bloat.

ajconway 5y ago

> In many cases, this software doesn't even do anything that is functionally different from 10 or 20 years ago, but it still consumes many more resources I would argue that in most cases the choice is not between fast, optimized and slow, unoptimized software. The choice is between having a functioning program (using a universal, "reasonably" efficient stack) and not having one at all (because the amount of resources it takes to develop a customized, low-level implementation is prohibitively high). A good example: https://www.youtube.com/watch?v=tInaI3pU19Y https://www.youtube.com/watch?v=tInaI3pU19Y A custom 3D engine performs immensely better than a comparable Unity project, but it took the author 3 to 4 times the effort.

thereddaikon 5y ago

I think scalability, portability and cleanliness is mostly talk. The reality is that browser based frameworks like Electron are popular because developers who only know js are cheaper and the first half of the lifecycle is cheaper and faster while the second half is often either dropped entirely or someone else's problem. Of course a JIT compiler will never be as performant as precompiled binaries, especially when its running in a full featured web browser that is packing functions that the developer neither needs nor is using.

postalrat 5y ago
The reason electron took off if because it was the first to offer an easy way to build cross platform apps. Something the systems guys have failed to deliver for many years.
- handrous 5y ago
  There are tons of easy ways to build cross-platform apps, and have been for a long time. Extreme, very free-form customization of GUI elements so it looks & behaves exactly the way your marketing, branding, & web-design folks want down to the pixel on every platform, is what was hard before Electron. If you just wanted to deliver a GUI applications cross-platform, full stop, that's not something you couldn't do before, fairly easily, especially if Electron's performance and integration with its host platform is considered acceptable for what you're doing.
  - postalrat 5y ago
    What alternatives? How many of them include the web as a platform?
    - handrous 5y ago
      Java and its various GUI toolkits (again, especially if Electron's performance isn't bad enough that it's off the table). QT. TK. Wx. Delphi and some others if you didn't mind paying. Obviously none of them include the Web as a platform (unless you count Java applets, which you shouldn't since they're basically dead, even if they'd seem high-performance and quite nice compared to what we've replaced them with).

slumdev 5y ago

> Yeah, all this concern with scalability, portability and clean code, has created quite a dystopian software world. I don't think scalability, portability, and clean code are the enemy. C/C++ are as portable as they ever were, and Java/.NET provide higher-level abstractions that work across both Windows and *nix systems. Even Electron doesn't have to suck, in theory. The reason performance is bad these days is because developers are just bad. The number of developers doubles every five years. Ergo, half of all developers have less than five years of experience. The vast majority of them don't have a CS, CE, or EE degree. A large number of them went through bootcamps (which are an expensive version of the old "Learn VB in 21 Days!" books.) And they're all writing the Electron apps we love to hate.

ensiferum 5y ago
I think it's the growth in data that when combined with accidentally bad algos suddenly start to drag down the perf.
staticassertion 5y ago
As a college drop out I'm pretty sure I know more about writing efficient code than most CS grads - I've seen what gets taught, it's not impressive. I've also seen bootcamps (haven't attended, but friends have) and while they don't teach about efficiency, they're far more rigorous than college was. Anyway, I don't want to get into this really, but I found this part of your post to be annoyingly off-base, and I resent it. That said, I'm in agreement that most devs don't know much at all about performance. Frankly, we're told not to... it's a sad state. Performance is explicitly referred to as a last priority, the "optimization is the root of all evil" quote is completely taken out of context and parroted everywhere (go look up Knuth/Hoare's context if you haven't), etc. All that is to say, the issue is not specific to education but is an unfortunate part of engineering culture. We, as a large group, explicitly neglect performance and treat it as a dirty word. IMO we need a sort of performance revolution the way testing got one. I've written lots of software in a 'benchmark driven' way, and the results are extremely fast programs - I've gotten programs down from just under 1ms to a few dozen nanoseconds like that.

dahart 5y ago

> In many cases, this software doesn't even do anything that is functionally different from 10 or 20 years ago, but it still consumes many more resources. Which software exactly is functionally the same yet consumes more resources? Can you give some specific examples? Nah, having lived and written code through the last 20 years, I think this often repeated argument just isn’t true at all. I can see why it’s easy to jump to this conclusion and easy to believe, if you don’t know or don’t pay attention what’s under the covers. It’s easy to forget about all the conveniences you’ve gotten used to along the way. You wouldn’t agree the functionality is the same if you tried using software from 20 years ago. One easy to overlook difference is displays. It’s easy to forget that 20 years ago we had 800x600 screens, 24 bit color was not ubiquitous, and 60hz monitors were practically non-existent. Today 4K is normal, and combined with refresh rates and colors, we’re pushing upwards of 2 orders of magnitude more data to our screens. We have much better compositing, much better text and graphic rendering, better antialiasing, all around higher quality and faster rendering. YouTube and Netflix didn’t exist 20 years ago. Browsers were incredibly slow and couldn’t support streaming video or anything but the smallest of applications written in JavaScript. Localization didn’t exist, web analytics wasn’t really a thing, browsers didn’t run background tasks. > A world where some websites still don’t work properly across web browsers This specious framing might have you believe that web portability hasn’t improved that much, while in reality the difference in support for web standards has changed dramatically in the last 10 years. Supporting IE6 was a real and widespread problem for businesses compared to the few minor corner cases that are left.

mirker 5y ago
> Which software exactly is functionally the same yet consumes more resources? Can you give some specific examples? Operating systems, particularly Windows. Given fixed hardware, you cannot expect an operating system to continue working indefinitely.
- moonbug 5y ago
  Whyever not.
  - 5y ago

supernovae 5y ago

This isn't a problem of clean code and software, its a problem of walled gardens.

einpoklum 5y ago

> Yeah, all this concern with scalability, portability and clean code, has created quite a dystopian software world. All of these three - when interpreted reasonably - coincide and even constitute performance improvements: * You make less assumptions, including regarding the speed of things, when you make your code portable. * When your code is clean, it's easier to generalize speed benefits rather than when you need to apply some ugly spaghetti hand-written optimization in 20 places. * Scalability means scaling up, out but also _down_ from the machine you're currently using. How else would you run your, say, distributed search web app on, say, a cluster of RPi 0's? ... Of course, if your approach to scalability and portability is to stick things in a container or vm, and manage a fleet of those, then yeah, that's kind of a problem.