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?
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.
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.
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.
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.
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 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
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.
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.
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.
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.
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.
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.
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 [...]
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.
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.
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.
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
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.