I heard this described as the "200% problem": when you introduce a new layer to solve your annoyance with learning the layer below it, new users likely have to do 200% of the learning because now they have to learn your new layer and the layer below it because your layer is leaky. I first heard this from a great recent talk by the creator of Chef, Adam Jacob -- What if Infrastructure as Code never existed [1]. This applies to everything with a error / abstraction-leakage rate that is observable on human timescales, definitely including everything cloudy/devopsy/sysadminy. An example of an abstraction that lands on the other side of that definition are 'digital' computers, which are really analog underneath but they present an abstraction with an error rate like 1e-15 which is well below the threshold where we suspend disbelief.

Really the best you can hope for with a layer on top of system configuration is to just reduce boilerplate in the lower layer.

[1]: https://www.youtube.com/watch?v=5lPa2U239C4

A colleague once coined the term "horizontal abstractions" (referring to a lot of the java "enterprise" pomp and ceremony) referring to much the same effect (there's no pyramid of abstractions - just more layers of similar complexity).

Unless.. you do a really good job, like heroku, vercel etc.

Also why is AWS so complicated? That’s where the money is: enterprises!

I believe businesses like Microsoft, AWS, etc. all make their enterprise stuff super complicated as an excuse to sell support contracts. I remember trying to set up Windows Deployment Server, and the whole thing was very unreasonably complicated. I got it working, but I can see why businesses would pay for support contracts just so they have someone to call to walk them through all the esoteric steps, menus, options spread across the whole OS. The other side of it is, if you make your cloud offering super complex then you're pretty much locked into that platform because of sunk cost. Switching from Azure to AWS or whatever would be a huge undertaking.

That's really what frustrates me the most about modern technology. It's like tech and software developers love to rube-goldberg things, and everything is vastly more complicated than it needs to be. The thing is, tech people seem to like complexity for the sake of complexity. It gives them a fun [read: masochistic] puzzle to work on and makes them feel smart.

Heroku is great until you need to do something non-standard in your deployment, like compile node and configure a python virtualenv in the same deploy. Then you have to learn their Buildpack framework and that is a nightmare. It's a hugely complicated abstraction layer that, like one of the parent comments says, requires me to learn 200%. I have to learn all the steps to install/configure nodejs, then python, then how they decided to slap together a layer on top of it that made assumptions like you would only be doing one of these things.

This is a spot on term for this, unfortunately way too common in the SaaS world.

While I don't disagree entirely, I feel like you're misrepresenting what they're offering. Their language is an attempt at simplifying orchestration and application code. The diagram you're showing only proves that point - that's an AWS diagram, and the code on the same page is what creates it:

    bring cloud;

    let queue = new cloud.Queue(timeout: 2m);
    let bucket = new cloud.Bucket();
    let counter = new cloud.Counter(initial: 100);

    queue.addConsumer(inflight (body: str): str => {
      let next = counter.inc();
      let key = "myfile-${next}.txt";
      bucket.put(key, body);
    });

If they can deliver on their promise, it's actually promising. (I haven't evaluated it; just taking things at face value)

Any reason I can't import an NPM package that has 90% the same interface?

There's likely a clever way to do that despite Wing's explanation, but it'll be a whole separate project.

Wing will pave the way and come up with a good abstraction or two, then become obsolete once general purpose languages with better ecosystems can do the same.

Of course not. There are some powerful options like CDK and others.

An additional goal seems to be to create a simplified language that doesn't have the surface area and dependency issues another language might have. While I understand the reasoning, I've been in tech long enough to know that usually doesn't work, and just creates another real world example of XKCD 927 (https://xkcd.com/927/)

All of that is indirection away from users.

Just configure *nix “user” like they’re containers, or queues, or buckets.

How many DSLs do we need for the single domain of managing electron state?

I don’t mean to say other abstractions are unnecessary, I mean for that realm of platform/sre/ops/sysadmin metrics, telemetry, observability. Really though why isn’t it just fork() all the way down and code thread counts reacts to eBPF? Jettison Docker, k8s. Just release “user” profiles that are dotfiles, namespaces, cgroups rules, and a git repo to clone.

Better yet just boot to something better that mimics CLI for the lulz but isn’t so fucking fickle

I see both ends of it, but as a python/boto3 fanatic I'm not sure that the added functionality outweighs the rest of the pythonic joys on offer.

Isn't this how every single progress is made, though? [Literally anything] => "Hey, this is better" => [Better] => Repeat

it’s just that simple

Don’t? But maybe also don’t gratuitously trash someone’s work?

I’m not saying their work is bad. But every abstraction is leaky and it’s a lot easier to find someone who knows how to use the native SDKs for AWS/Azure/GCP than someone who knows an obscure framework that doesn’t cover everything.

Your original comment went a fair bit beyond that assessment.

No. Adults aren't made of sugar. Meaning was clear and professional using layman terms.

> And why would I base my entire application on a framework by a tiny developer?

If we work like this we'd have no frameworks. Everything started from 0.

Frontends are pretty much always awful... They work until they don't and then you're invested and screwed.

I've become a much bigger fan of well-designed libraries. Do one thing and do it well, and preview a simple API for doing it.

Seeing the clusterfuck of the modern front end ecosystem, you act like that’s a bad thing.

But the two most popular front end frameworks that came out over the past few years didn’t exactly come from small companies.

Great, now do Linux. Or cURL. Or Clojure. Or Perl. Or Python.

Great tools can, and often do come from solo developers without large corporate backing.

So the top contributors of modern Linux are large corporations. cURL is not a framework

And isn’t that the ultimate in survivorship bias? How many other languages and frameworks would you have left you screwed if you jumped into whole hog in before they had popular uptake?

Linux was started by one man, and the qualification as “framework” is immaterial to your point.

And was it actually used or became popular before it was adopted by and had contributions from major companies?

Actually, yes! And you are conveniently ignoring the other examples that don't fit your world view.