Comment by nerdile | Hacker News Reader

Comment by nerdile | Hacker News Reader

> I disliked C++ because abstractions are leaky. So I am building a new abstraction on the cloud.

Oh boy, buddy. Let me know how that works out for you.

I've worked on app code, OS code, on-prem services, datacenter services, cloud on Azure and AWS. No matter what your platform, someone has to do the hard work to make the inner loop quick and the deployment process reliable. But no matter what, the abstractions are leaky, and the engineers who grok the underlying platform have the fast cycle times, and the ones who don't, are frequently blocked and need help from those who do.

Building on CDK now, I can build my code and run all my unit tests in under a minute, and deploy via CDK and run all my integration tests in under five. Since I'm focusing on microservice components with independent delivery, that's ok. Obviously, the monoliths are more complex and tougher.

I'm not sure how a new language and abstraction are going to help here. (Sorry, that's what I would say to a new hire on my team to be gentle. What I mean is, sorry this won't help.)

(Also, CDK is a mess because the underlying CFN techs are inconsistent in their adoption. SNS being one of the worst offenders.)

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.

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.

Also from the author:

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

>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 :)

I read

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

now.

Reply on news.ycombinator.com