The coming age of people with no understanding of what running code actually means, no idea how hardware/close to hardware systems behave deep down, is going to be fabulous, and full of wasted computing.
> The coming age of people with no understanding of what running code actually means, no idea how hardware/close to hardware systems behave deep down, is going to be fabulous, and full of wasted computing.
Just like now is to people who were programming in the 1990s, or the 1990s to people who were programming in the 1970s.
Partially agreed; on the other hand, Arduinos & PIC helped a lot to get, say, hardware IRQs, something that is quite heavily abstracted away in general computing.
I disagree. If you build a good enough abstraction, you can give developers a lot for free without needing them to understand. Current serverless platforms are wasteful, but the underlying concept is not inherently wasteful, and I think that cloud providers and serverless software platforms will improve over time.
The need to understand is a primary skill for a decent engineer. Was in the 1960‘s and still is today. Lack of Knowledge is what makes an engineer a business risk.
I don't need to understand metallurgy thanks to processors. I don't need to understand instruction set architectures or assembly language thanks to programming languages. When abstractions truly separate concerns, they make it very much possible to not understand, much to the benefit of the programmer, who now needs to keep significantly less in their head. Aren't you glad you don't have to be concerned with making sure your stack stays balanced thanks to scoping in C? Well, I'd like to write an API without having to be concerned about job scheduling, dispatching, logging, monitoring, etc. Understanding these things may make you a better programmer (or they may not,) but not having to understand let's you let go of things you don't need to care about and focus on what you're trying to accomplish instead.
We as programmers love writing solutions to problems that have been solved hundreds of times. How many node.js http frameworks exist? Or JS frameworks for that matter? But the thing is, for the most part, when it comes to API servers, there's a crazy amount of overlap between what they need to do. They handle HTTP requests and spit out a response. Someone has written this better than you can, so you use an HTTP library. You probably want to serve multiple endpoints on one port, so you route with the URL. What do you do, implement a radix tree, or use a mature, well-tested, high performance library? If you are sane, probably the latter.
All serverless is is a realization that most HTTP servers don't need anything special in terms of routing, scheduling, monitoring, etc. By turning an HTTP server inside out, you can allow the developer to focus on exactly one thing and give them a platform that is stable and inherently scalable by virtue of being stateless and making scheduling an implementation detail.
If you have a very efficient engine to execute functions, and a very robust and scalable HTTP server, and you can write your app logic to be stateless (locally, anyway,) there's no reason to believe that the serverless approach would be any technically worse than the old school approach.
I feel likewise similar about static files. I don't need to write and operate yet another static file server. I can use Amazon S3 + Cloudfront, or Firebase, or GCS, or any other solution. It doesn't mean I don't know how. It's an admission that I have no special requirements, and would like to focus on the things I'm writing that are particular to my app.
What's dangerous? Not serverless, for sure. What's dangerous, is programmers implementing everything from scratch because they can, doing their own operations when they don't have the resources to.
The people programming in the 1970s feel the same way about today, when you use such high level abstractions like C. That's why programs today require so much RAM and CPU.
But that is the price of agility. Serverless is just another abstraction on top that increases agility at the price of increased compute.
The coming age? I do software development coaching and most every developer I'm contracted to teach doesn't understand what running code actually means (to use your phrase).
To take it another step, pretty much none of them understand how the JVM or V8 run their code.
I think this has been the case for the case for the past 20 years, probably longer, though I'm optimistic that improvement is possible. E.g., perhaps serverless computing is inefficient today but it could help improve hardware utilization.
> perhaps serverless computing is inefficient today but it could help improve hardware utilization.
This was a big selling point of virtualization, originally. It was certainly true for environments that suffered from poor utilization due to, say, running one app per (often oversized and/or antiquated) physical servers, as I believe was common for enterprise IT shops.
Whether this improvement could have been achieved by other technical means (at least in non-Windows environments) is debatable. It's also unclear what percentage of total hardware utilization enterprise IT accounted for back then, and I suspect it was much higher than today.
For other environments, where virtualization would replace simple Unix time-sharing, it stands to reason that hardware utilization had to go up, if only moderately.
Interestingly, enterprise IT practices are still so extremely expensive today that moving to a cloud provider is obviously cheaper for them.
Just like now is to people who were programming in the 1990s, or the 1990s to people who were programming in the 1970s.