A a few hundreds of megabytes of flash will soon cost less than the plastic and manufacturing costs of the chip itself. At that point, manufacturers will be putting in 128megabyte flash chips simply because 16 megabyte flash chips cost more.
The only place that argument won't apply is in microcontrollers where the flash is on the same die as the CPU.
I worked on a bit of premium consumer electronics. Retail would be about $80. That allowed an electronics BOM cost of $20. When selecting the processor, the size of the flash was a more dominant effect than RAM, clock speed or chip peripherals, because we're in the $1 vs $1.20 region.
There is a lot of software running in some very cheap electronics, all around you all the time. Everyone just forgets because it's all designed in corporations and not talked about on the internet so much.
I still do not understand why you need hundreds of MBs of RAM for a container orchestrator.
Thirty years ago someone could have said the same when seeing laptop computers and remembering when computer literally used to occupy whole large rooms.
Come on, let's stop doing this kind of jokes, they add nothing to the discussion.
The word 'embedded' is not well defined, but if you use it on things with 1GB of RAM, what do you call a PIC with 1K?
My personal definition of embedded (which is of course still flawed) is anything without an MMU. A Raspberry Pi isn't embedded for instance, it's just a small computer, just like a phone.
There is certainly a lot of technical merit in calling the five-inch thing in my hand a distributed system of multiple computers, but in practice it's not the common definition.
> ...
> My personal definition of embedded (which is of course still flawed) is anything without an MMU
Probably "embedded" would better be defined as an electronic device capable of performing digital computations small enough to be put literally into other stuff, usually everyday things.
If you mean tiny devices, why not say "microcontroller" or something?
_very_ embedded
Yes 1GB is huge, my Windows Phones are capable of so much with a tiny portion of it.
Maybe that point in time is now, maybe it isn't. But it is coming nonetheless, that is one thing we can be sure of.
For at least 50% of developers, the "physical reality" is that of gathering client requirements quickly and accurately and implementing them correctly and on budget.
Not of micro-optimizing CPU cache hits :)
A day will come when CPU speeds and RAM sizes will stop increasing. When that day comes you don't be able to ignore performance, because a lack of performance will mean actual, real-world dollar costs for the client, and so performance will be the #1 requirement of the client.
The client doesn't seem to care, and just sees the 5-20 second webpage load times as totally normal (at my company/industry at least). Our applications are horrifically slow, but we're still the market leaders in our segment
Yes, but will they tolerate 2 minute page load times? 10 minute?
At some point reality kicks in and you start to have to care about the nuts-and-bolts hardware.
LOB applications are made to replace humans and they need to be a multiple of times faster than human operations (+ the extra benefits of automation). And the vast majority of them are. And most programmers are working on those applications.
So there's 0 incentive for what you're saying.
The real heavy lifting will be done, as usual, by a handful of people: OS devs, DB devs, game engine devs, runtime devs, etc.
And it has to run on every node even if the worker nodes are just running workloads.
However unlike Modula-3, Mesa/Ceda or Oberon(-2)/Active/Component Pascal they are load only instead of being possible to unload them, and they require manual binding of symbols.
For this kind of system work a more feature rich dynamism is certaly a big missing feature.
The problem of GO is that all those unused libraries are loaded in RAM instead of staying on disk, and loaded when needed.
An helloworld in GO (around 1.6MB) is still too large for my openwrt router.