Ask HN: Why is Google not making a language that runs on low memory devices?
I just used a low cost smartphone in India and honestly it was the worst I have ever used. I was wondering why is Google not making a language for low end mobiles that consume very less memory? We had glorious computer apps running in 512mb of RAM. Now all apps need a gig of memory to run without problems. Is this because of VM on Android? Is dart lang memory sensitive?
39 comments
Part of the problem is Java itself, it's too easy to add a 'binary' dependencies in Java, so applications get bloated.
Part of the problem is that Google remove the interpreter of Android so and AOT codes creates big executables which need to be loaded in memory.
Part of the problem is not Google but the fact that application makers test on flagship phones Pixels, Galaxy etc.
Part of the problem is that Google waits too long before introducing Go edition (available since Oreo) which re-introduce the interpreter and provides a clear target.
Part of the problem is that low cost smartphones is not where the money is, so there is no real insensitive to target low cost smartphones.
Part of the problem is that Google remove the interpreter of Android so and AOT codes creates big executables which need to be loaded in memory.
Part of the problem is not Google but the fact that application makers test on flagship phones Pixels, Galaxy etc.
Part of the problem is that Google waits too long before introducing Go edition (available since Oreo) which re-introduce the interpreter and provides a clear target.
Part of the problem is that low cost smartphones is not where the money is, so there is no real insensitive to target low cost smartphones.
All of those are not a problem if you want to address problem of low memory and design for it.
Sure, but if money is not an issue, why not get them a phone with more memory?
Google's the one dodging taxes and writing bloated crap so why should consumers pick up the tab for bigger hardware? That's subsidizing them for not hiring enough people to do anything but dodge taxes and defraud advertisers, while they hoard over $100b in cash...
I think what we should do is make their carbon footprint tally include their shitty javascript all over the internet and their apps on phones.
I think what we should do is make their carbon footprint tally include their shitty javascript all over the internet and their apps on phones.
forcing software to run under a virtual machine adds one more layer, so no matter how good software can be designed, compared to similarly optimized native software it will always mean more code to be executed, that is, more time needed to execute it and more space needed to contain it.
They used the VM approach for security reasons, which to me is terribly wrong. Mobile terminals should have hardware separation between subsystems, that is, the sensitive stuff (radio) enclosed in black hardware boxes where data goes in and comes out, just to make telcos happy, but everything else -I mean all the OS and apps- should be native and user accessible. This way one gets the best possible performance while maintaining a high degree of separation between kernel+userland and radio chipset which would let allow hacking whilst preventing anyone to tamper with cell connectivity.
They used the VM approach for security reasons, which to me is terribly wrong. Mobile terminals should have hardware separation between subsystems, that is, the sensitive stuff (radio) enclosed in black hardware boxes where data goes in and comes out, just to make telcos happy, but everything else -I mean all the OS and apps- should be native and user accessible. This way one gets the best possible performance while maintaining a high degree of separation between kernel+userland and radio chipset which would let allow hacking whilst preventing anyone to tamper with cell connectivity.
The language itself is not the bottleneck, it's the shitty software everyone writes. Hardware is like an arms-race where it only takes a few months for the shiny new generation phones are as fast as the previous gen, because app developers rapidly can't justify the cost of keeping an app speedy on old hardware. This is why your phone feels slow, not because of the hardware or language.
Wirth's Law: Software get slower more rapidly than hardware becomes faster.
Not using more hardware resources than reasonable has stopped being a thing. A large section of software writers behave as if that the only purpose of the hardware is to run the app they wrote.
Not using more hardware resources than reasonable has stopped being a thing. A large section of software writers behave as if that the only purpose of the hardware is to run the app they wrote.
With tools like containers, the software itself behaves as if the only purpose of the hardware is to run your application. Psychologically, it makes sense for a software developer to believe this.
I don't see how that follows. The context here was applications that run on phones. I think its intellectual laziness to blame it on containers.
I think you'll find that they are. Have you seen the Nokia 1 Android Go edition? It's a phone running an Android OS specifically targeted at low memory devices, along with low memory versions of it's apps suite (Google Go, YouTube Go, etc.). When it comes to programming languages, memory usage is usually more dictated by features (e.g. graphics, video) than by the programming language
Btw these Google go and YouTube go are terrible to use in the cheap devices. So stuttery
Google offer the Go edition of Android, which is designed for entry-level smartphones. It includes a range of first- and third-party applications that are designed to use less storage, RAM and mobile data.
https://www.android.com/versions/oreo-8-0/go-edition/
Software development is always a tradeoff between development time, features and performance optimisation. You can add more features in less time if you aren't too worried about performance. Most mobile developers neglect performance for simple financial reasons - it's an unfortunate fact that developing apps for low-income customers isn't very profitable. A user with a ₹4,000 Micromax phone probably isn't going to pay ₹200 for my app, but a user with a ₹60,000 Samsung phone might. No matter what Google do, a lot of apps are going to perform poorly on low-end devices.
https://www.android.com/versions/oreo-8-0/go-edition/
Software development is always a tradeoff between development time, features and performance optimisation. You can add more features in less time if you aren't too worried about performance. Most mobile developers neglect performance for simple financial reasons - it's an unfortunate fact that developing apps for low-income customers isn't very profitable. A user with a ₹4,000 Micromax phone probably isn't going to pay ₹200 for my app, but a user with a ₹60,000 Samsung phone might. No matter what Google do, a lot of apps are going to perform poorly on low-end devices.
Creating a new language for low memory apps is... probably not the right approach. Google does have an initiative to improve the experience on very limited resource devices though, it's called Android Go.
https://developer.android.com/google-play/guides/android-go-...
https://developer.android.com/google-play/guides/android-go-...
Don't mistake it for golang (unrelated name), but there's a suite of Go Google apps https://www.androidauthority.com/android-go-apps-820153/
They're aimed for lower spec phones with slightly reduced functionality, but still official / good quality.
They're aimed for lower spec phones with slightly reduced functionality, but still official / good quality.
It's not the language, it is the developer. The developer can make trade-offs, optimize, test on different devices, etc...
In reality, this is expensive. Couple that with the fact that people who use low cost smartphones are not going to attract big capital, and thus they are left with average software developer.
In reality, this is expensive. Couple that with the fact that people who use low cost smartphones are not going to attract big capital, and thus they are left with average software developer.
Dart + Flutter compiles down to native ARM code. Don't know what the memory profile is but could be promising.
Yeah. The OS to host this is, at the moment, called Fuschia. Definitely definitely definitely targeting low mem devices.
https://en.wikipedia.org/wiki/Google_Fuchsia
https://en.wikipedia.org/wiki/Google_Fuchsia
Dart + Flutter is for building native iOS and Android apps. Fuchsia will surely be a target in the future, but it is not THE host for Flutter apps.
This is not a language feature. We are talking about Dalvik here.
Low memory optimization means switching from a copying collector to a simple mark & sweep collector. It's entirely up to the vendor to configure that JVM collector. Nokia does so I believe.
SW bloat in apps and bad config tunings for autocompletion and other user configs also lead to bad UI responses on low-powered phones. Google is partially doing the right thing by providing all the frameworks by itself leading to reduced bloat. You just use the default library, in shared memory. But a problem is of course Google removing the interpreter, costing a lot of discspace and memory.
Low memory optimization means switching from a copying collector to a simple mark & sweep collector. It's entirely up to the vendor to configure that JVM collector. Nokia does so I believe.
SW bloat in apps and bad config tunings for autocompletion and other user configs also lead to bad UI responses on low-powered phones. Google is partially doing the right thing by providing all the frameworks by itself leading to reduced bloat. You just use the default library, in shared memory. But a problem is of course Google removing the interpreter, costing a lot of discspace and memory.
But what happens if your memory-optimized phone visits a website running JS and which requires megabytes of memory?
This is a tradeoff: memory gets cheaper http://www.maltiel-consulting.com/ISSCC-2013-Memory-trends-F..., and is much cheaper than time to learn exotic language. Today more important expensive are latency, bandwidth, and programmer time.
Top reason for memory optimization nowadays is to reduce GC delays.
But if you really look for low memory languages, please try Forth https://www.forth.com/forth/ or Joy https://hypercubed.github.io/joy/joy.html. They may provide interactive environment in as little as 2kB https://www.mpeforth.com/xc7.htm#umbilical, and interactive debugging for deep space probes https://www.forth.com/resources/space-applications/
But if you really look for low memory languages, please try Forth https://www.forth.com/forth/ or Joy https://hypercubed.github.io/joy/joy.html. They may provide interactive environment in as little as 2kB https://www.mpeforth.com/xc7.htm#umbilical, and interactive debugging for deep space probes https://www.forth.com/resources/space-applications/
I'm looking for apps that don't try too much and work in a good way in low powered devices. The next billion users are not getting a decent usable application. That's the point.
There are many reasons for this, mostly because we keep getting more hardware that can handle more not many optimize for lower spec hardware which I find sad. I want to be able to run much more apps with better hardware not the same amount of apps I could run 10 years ago (very limited number). With 16GB on my workstation at work I have to worry about opening up too much because as you say software takes up 512MB of RAM. I usually close all apps on my phone.
The only thing I saw Android doing was 'Android Lite' which Nokia plans on supporting only Android Lite. I too wonder where Google is going with Android, but I fear as many have suggested they only care about using it as a means to track people and lock them into their own services... Sadly Android could be so much more and they clearly have the resources to make it so and yet... Nothing.
I would love to see Microsoft take Android OS fork it and make something that isn't a Memory hog and conserves on energy someday.
The only thing I saw Android doing was 'Android Lite' which Nokia plans on supporting only Android Lite. I too wonder where Google is going with Android, but I fear as many have suggested they only care about using it as a means to track people and lock them into their own services... Sadly Android could be so much more and they clearly have the resources to make it so and yet... Nothing.
I would love to see Microsoft take Android OS fork it and make something that isn't a Memory hog and conserves on energy someday.
Microsoft once already failed to promote a mobile OS which was ten times better than Android, why would they be successful with shitty Android fork...
Because they're different approaches. I would expect the "shitty" fork to be able to run Android apps, something that WP wasn't able to do, so developers had to support yet another platform for little gain.
If MS forked Android, made it snappy while keeping it compatible with existing apps, and if they did their marketing correctly I could see this carving a small but profitable (for some value of profitable) niche.
If MS forked Android, made it snappy while keeping it compatible with existing apps, and if they did their marketing correctly I could see this carving a small but profitable (for some value of profitable) niche.
>If MS forked Android, made it snappy while keeping it compatible with existing apps [...]
That's assuming Google has some interest in not making it as snappy as it could be. I don't see what the reason for that might be.
I rather think we're talking about trade-offs here, the prime one being breadth of app selection vs quality of apps.
But any new Android fork would have to prioritise breadth of app selection as that would be the first question buyers would ask. Can I still run all my apps?
That's assuming Google has some interest in not making it as snappy as it could be. I don't see what the reason for that might be.
I rather think we're talking about trade-offs here, the prime one being breadth of app selection vs quality of apps.
But any new Android fork would have to prioritise breadth of app selection as that would be the first question buyers would ask. Can I still run all my apps?
... which would realistically mean including the play store, which would mean having to pass google's requirements, which would mean relatively few modifications, no own store (i think), and including google apps.
doesn't seem like something ms would really like to do (interesting bit: they once shipped a version of android themed to look like windows mobile).
I think Microsoft is one of very few companies (perhaps even the only one) that could actually replace all the google apps and run its own store.
If they cut the revenue share to, say, 10% (or a fixed fee + 5%), then it wouldn't take long until all Android apps are available on the Windows store as well.
If they cut the revenue share to, say, 10% (or a fixed fee + 5%), then it wouldn't take long until all Android apps are available on the Windows store as well.
Simple, their OS didn't have many apps, but a shitty Android fork gets zillions of them.
I mean, just open up any Windows 10 laptop and look at the 'Market' app, it definitely has the bare essentials. The side effect being that I can download movies and shows on Netflix for offline viewing on a Windows Laptop but not on a Mac (yet, looks like they caught on to this approach - sadder when people will claim Apple thought of it first).
I have always wondered about the use of the 32 bit address space version (on an otherwise 64 bit CPU) of Linux and associated tool chain. Address space gets severely limited making threads hard but that specific problem we know how to solve. It would be a problem if your app really needs a lot of physical memory though. So its a trade off.
No serious cash to be earned in that market? If you optimized software for low resources, I'm sure most websites would throw away js ads...
Because low cost smart phones is not their market.
In short, after 5years you will see devices with 8gb ram and 128gb storage at much lower price which can be offered by everyone. We are no longer living in the era of floppy disks where we need to optimise on RAM and storage space. We are moving towards the world where multiple tasks to be done efficiently using all the memory you can use. We are no longer designing for single efficient task.
I'm not so sure.
Electronics works at different economies of scale than websites/web applications/saas, where usually (at least at the beginning) you will probably churn out bloated applications to "go fast and be lean" and say who cares since you can just relatively easily bring in another 64GB VM.
If you need to produce 10 million units spending 0.1$ less on each unit is a godsend, you instantly have 1 million dollars more for R&D (and/or possibly profits).
Electronics works at different economies of scale than websites/web applications/saas, where usually (at least at the beginning) you will probably churn out bloated applications to "go fast and be lean" and say who cares since you can just relatively easily bring in another 64GB VM.
If you need to produce 10 million units spending 0.1$ less on each unit is a godsend, you instantly have 1 million dollars more for R&D (and/or possibly profits).
No, you don't get it. The OS that is outselling android is Kai OS. It's a simple smartphone OS with basic stuff. The next billion users are already half way in and the market is open for capture. Waiting for a couple of years is not wise
Check ou the history of Java (originally Oak), you might be surprised.
By the time Google does it, prices memory /chip will drop drastically. But then Android will develop to use the new resources fully