Also from the author:

>I've spent the last five years building the AWS CDK

Unless the foundations themselves are changing (that is, AWS bringing something different), I suspect it's going to make it worse. It just hides the ugly truth behind yet another layer of abstraction, hoping this layer will make things work.

I don't remember when building extra abstraction layer had ever helped runtime performance. Faster and simpler coding, less learning? Sure - and that's great. But I suspect it's going to be as bad as my first large Terraform project (and oh man it sucked so bad).

Or it could be decently fast, but it'll make a number of assumptions and $deity help you if you step in a wrong direction.

Faster and simpler coding with less learning wins every time against snappy but esoteric, at least in business applications. It's better for the client, better for the developer and better for the company, even if it doesn't squeezes every processor cycle

The pure advantage of iterating faster on requirements and deploying new functions beats having a very fast but very restricted and possibly incorrect feature set. And if an application takes off, it's always possible to identify its critical path and optimize it for speed, or even re-engineer it starting from a much clear solution to the business case.

> and deploy via CDK and run all my integration tests in under five

Aka "my integration tests take 30s and remainder is CDK sitting around like an idiot".

this is why you have to use the apis directly. the apis are the actual boundary, the rest is optional and expensive.

I read

"I used to love building object-oriented code in C, but it was a leaky abstraction"

now.

Actually I really love C++ :-) Just spent some time at Core C++ in Tel-Aviv and was so inspired by the community and depth and incredible innovation that's still happening around this language.

But there's actually a specific technical reason why we realized we need a new language: it's because cloud systems are distributed. They are a composition of both infrastructure and application code. Not just one of them.

Existing languages (including my beloved C++) have a fundamental assumption that a program is executed on a single machine. This means that whenever you exit the machine boundary (e.g. call a service), the compiler basically says adios and leaves the room. Now the onus is on the developer to stitch the components together.

And that happens A LOT in the cloud. More and more as you transfer responsibilities from your application code to managed services. Isn't that what the cloud is all about?

The power of compilation is the safety you get from linking decoupled components together. This is exactly what it's doing for "traditional computers" today. Two functions in memory are effectively decoupled (they are just two sequences of opcodes in memory). And so compilers and linkers were invented to check that when I call function A from function B I give it the right number and type of arguments at a very very early stage.

>I'm not sure how a new language and abstraction are going to help here.

It will help the author make his millions. He already built CDK for free which solves all the problems described. He just needs to do the same thing again in a VC-funded context :)