To do that with JavaScript or python you’d need some really strong static analysis to work out what to do if the user, say, writes a function that returns a list of new buckets to create, or whatever.
Eg the argument seems to be the ability to statically deduce the required underlying cloud resources the code is talking about
This appears to be using application code to derive infrastructure config automatically. It’s a but like the https://www.shuttle.rs/ approach.
Edit: after taking a deeper look, a more accurate description might be that it allows you to embed application code within IAC.
One product that's taking this approach is shuttle -> https://www.shuttle.rs/ (disclaimer: I work there). It's built around Rust and not TS but we have some updates coming soon which is going to expand on this.
We've been thinking about this DSL question for a while and it's pretty much a trade-off. By having your own language and parser you can build language primitives which get your close to your domain, as for example in the example you gave with HCL. It will be interesting to see where Wing goes with this concept, it could offer a great developer experience.
For us, we've chosen to stick with a robust and performant programming language which is increasing in popularity and has enough meta-programming capabilities to make this 'infrastructure from code' paradigm feel natural - the framework blends in well with the language. The advantages of this for us is that users of the language experience a very small learning curve and they can also use incredible Rust libraries off-the-shelf. We can also piggy-back off the Rust compiler and ecosystem to provide an A-class developer experience (those compiler errors are amazing).
We're excited to see more companies in this space - optimising for a beautiful developer experience.
I think the future isn't as much Lo-code as much as it will be (and goshdarn should be) Lo-DevOps.
There are so many advances in programming, like WASM for example, that will continue to cause this Lo-DevOps movement, but honestly, digging into the language, using the stuff that already is baked in for other existing business purposes.
But things like encore.dev and shuttle.rs (I'm associated with neither) are just mind-blowingly straightforward with no language, infrastructure, or other cognitively burdening information.
I'm not sure about it. If you're going to have Rust-specific deployment workflows, you should reuse the solutions that have been developed for the embedded ecosystem. There's no reason why "cargo flash" could not be extended to upload your binaries to the cloud, and support the same "probe run" workflow for remote logging and debugging.
Glad you like Shuttle! What do you mean exactly by support for GCP? Shuttle right now is built on AWS but that is mostly abstracted away from you. Do you want to use GCP products (say BigQuery) or do you want to host Shuttle on your own GCP project?
Most should not use HCL as an argument for forcing bespoke languages on users. (1) HCL is not a programming language, more of a config language. (2) It was the right time and place, but has shown rough edges as it has aged, it feels more hacky now.
Just write libraries
1. You need to enforce a relatively unique set of invariants, which in turn come with new constructs to interact with them. For example, if you want a system for managing a distributed system, enforcing the lack of global state can be a lot more natural by using a language that cannot express it.
2. You want to provide some sort of novel language construct that cannot be expressed well in existing languages (function argument pattern matching, for example, cannot be retrofitted onto an existing language by a library, maybe by pre-proccessor or sufficiently advanced macro system).
It doesn’t support global state. Instead you’d write a “process” that’d respond to requests with the state at time of request. Another request could mutate the state, but each request is processed one at a time. So a “bucket” type data store (object store etc) would likely be implemented as “server” that returns the state. If the objects were large you could pass a URL/handle to the file which you’d retrieve later.
These processes/servers/whatever are running inside the language VM and are SUPER lightweight. Multiple language VMs can be tied together so the actual processes can be distributed across a fleet of physical hosts in a data center - this would be transparent to how you write the code.
If you wanted to implement that in native AWS primitives you’d probably run a lambda function to transform an http request into a S3 bucket address, then you’d go and make an s3 request to download/modify the file. Or the lambda would make some modifications to the file.
So, that’s the prior art on a hypothetical distributed language handling global state, which fwiw is basically how “cloud” systems work today.
This is how we think about this too. Applications that use the cloud use a new kind of "computer" which have different characteristics than the model of a computer exposed by existing programming languages. There are some unique invariants and language constructs that cannot be implemented libraries.
The first of these unique primitives is what we call "inflight functions". You can think of `inflight` as "remote `async`". They are async functions that can be executed on a remote system (such as inside a container fleet or on a FaaS). Inflight functions can interact naturally with cloud resources around them (by simply calling `inflight` methods on the resources such as `bucket.put()`).
Interaction of inflight functions with the outside world poses a unique set of invariants. Currently inflight code can reference immutable serializable data and call `inflight` methods of resources defined outside that closure.
The compiler then analyses these interactions and inverts the control over to the resources to take care of the mechanics like wiring deployment information, synthesizing security policies and anything else that can be deduced from this high level intent.
Defining the cloud architecture of the app and being able to naturally crossing these distributed boundaries is the essence of what we call "cloud-oriented programming", and where we think a lot of the friction and pain of the cloud comes from today: every time I need to interact with "The Cloud", I leave the safety and comfort of my compiler, and I am out in the wild having to understand all the mechanics and layers involved.
Almost all existing languages/compilers take a fundamental assumption that the entire program runs inside a single machine. This is, in our view, the impedance mismatch of cloud development today. This is where we believe language innovation can dramatically reduce the cognitive load and barrier to entry for building and delivering cloud applications that fully take advantage of the cloud. Inflight functions and resources are only the first step. Think first-class support for things like defining and consuming API endpoints, writing distributed workflows, emitting metrics, raising alarms and other things you would expect from your friendly neighborhood cloud programming language.
Also, linking the infra code inside of your app code is a terrible idea imo.
Why do you think it's a terrible idea?
Seriously, when shit's on fire, the last thing you want is to be deciphering the magic that brought it to its current state. How many layers to dig thru are there, between "thingctl deploy" and a critical S3 bucket having somehow been deleted?
Not trying to shoot down the idea - I'm sure there are people 10x smarter than me working on this, who are more than able to make a lot of this work well in practice. But that's the problem with using stuff made by people 10x smarter than you - when everything goes wrong, it tends to require being 10x-smarter-than-average to fix it.
The true power and success of Terraform is in the blunt simplicity of its interface. Every time you run it, it will spell out in very large writing, what exactly is it going to do: add this, change that, DESTROY this - it even uses the word "destroy" to signify the danger. I really appreciate any tool that makes it harder to do the wrong thing.
I don't think having your infra with your code precludes a lot of these things, depending on how it's done. They're good points, and as engineers we'll likely need to be able to do this for a while (until maybe an AI can).
> Seriously, when shit's on fire, the last thing you want is to be deciphering the magic that brought it to its current state. How many layers to dig thru are there, between "thingctl deploy" and a critical S3 bucket having somehow been deleted?
I see it as analogous to how higher-level languages abstracts machine code. When it was a newer technology, people absolutely needed to debug and analyze the "magic" but as the space has matured that's becoming less and less common.
The fundamental difference is that you can keep analyzing a program in isolation as much as you like. Infrastructure is a living organism - if you shoot it in the head, you can't copy-paste an old working version over it; you have an outage.
> until maybe an AI can
Why is the solution to every problem always more layers, and never less? We understand running production infrastructure far better than we understand AI.
It's not that I don't appreciate ML/AI - it's fairly impressive what it can do, given you keep nudging it in the right direction - but I would never delegate unsupervised authority to it.
I think you're right here and it's going to be something that's really hard to get right. I think prioritising the developer experience is the only way to get this right - even at the expense of other things you want to optimise for like costs.
> The true power and success of Terraform is in the blunt simplicity of its interface. Every time you run it, it will spell out in very large writing, what exactly is it going to do
I agree with this statement 100%. The explicit, simple and clear information on what exactly is being modified is one great piece of devex. This precise workflow is something that's inspired us and we want to bake into shuttle.
Thankfully Pulumi[0] allows me to write Terraform configuration in a language I know without reinventing the wheel. It feels like Pulumi's approach is better in every single way I can imagine. I simply do not see the reason for HCL whatsoever.
What about the poor support for defaults and partial overrides on object-type (read: namespaced without redundant_underscore_thing_*) configuration directives?
What about the very limited module capabilities?
What about the limited set of deterministic functions available (e.g. you get base64, yaml, csv, and otherwise GLHF)?
HCL is its own language so Hashicorp can "own" the experience, tie you into an Enterprise toolchain, and scratch their "I've always wanted to build a language!" itch
But it works and ops people love it because most ops people in industry today cannot even write a simple Python script. So...tools like Pulumi are actually out of their reach.
No. Pulumi can do it but they have a compiler in the background. And you still need a lot of boilerplate devops stuff around it.
So if you already need a compiler to do the packaging, etc. why stop there. A lot of other tooling problems go away.
But yes, you'll be reinventing the wheel to some portion.
I'm not sure if you're making some distinction I'm not following, but yes? One of them is called 'AWS SDK for JavaScript'?
Let's say you are writing JS and you have
`const handler = ...`
You can not do something like
`const lambda = deployLambda(handler)`
on the next line.
Instead you need a deployment package. And to build this, you need to leave JS and involve some CI code and some IaC tool.
But wing enables you to just do that. (seemingly, I've not tried it yet)
I'm one of the founders of Klotho (https://klo.dev), and we're in the camp of expanding existing programming languages with cloud native building blocks. We’re building Klotho in that spirit.
There's a few reasons to opt for using a compiler rather than SDKs:
- Being able to catch errors as early in the development process as possible, rather than in runtime or production.
- Being able to use existing language features and popular libraries. For example, we’re able to turn a standard Node.js EventEmitter into an asynchronous invocation on a different compute engine (basically, spinning off an AWS Lambda invocation or adding a message to an SQS queue). Not only does this reduce the barrier for entry, but it also often enables fast iteration time by supporting a local development workflow (no more waiting for deployments between changes).
- Being able to trim the runtime to a minimal set that is necessary for that execution unit alone. In SDK land, you include the entire library, which means more lines of code to reason about in a live-site incident, alternatively going fully granular means developers now need to reason about what to include and what not to. Compilers, and specifically static analytics can reason about that automatically.
- Being able to use all of that logic across languages: rather than having to write a separate SDK per language, we can write a single tool that works the same across multiple languages. In addition to aesthetic niceness, that could in the future let us handle polyglot code bases in a more cohesive way.
We support JavaScript/TypeScript/Python, and are developing Golang/C# support
pulumi is the 'terraform as a library' option, haven't tried but it makes sense
> loops and conditionals were impossible for a while
Yeah they were, in what version was it? 0.11 and 0.12 I think when those were added? But those have been there for a while. It was admittedly beta during the time and under active development. Regardless, its a moot point now, so not worth discussing.
Still, conditional statements are limited to ternary style operators as opposed to complex multi-line if-statements. That would be a stronger argument to make that I could agree with. However, this was a design decision made by the team not a technical limitation. The goal is not to make complex logic decisions inside the declarative nature of Terraform since it takes you away from the declarative (documentation-style) markup that it stands for.
Between using locals and modules and data sources you can still accomplish almost anything despite not having multi-line conditionals. The end result is cleaner, which is a design decision that was made.
> the minimum unit of reuse is a folder with a file in it
I don't really understand the problem with this. This is essentially how Go(lang) is too and other full blown languages. Its another design decision and not really a limitation. There are significant advantages to this, for example modules are folders and everything inside of them gets compressed into a single unit for replication purposes. Within that folder you can break your code up however you wish to improve readability and maintainability. This gives utmost flexibility to the author, and standardizes the consumption for the consumer. You can import a module and use it as a "packaged" unit without needing to understand how the author created it.
These just sound like opinions you have more than "ergonomic warts". If anything I could argue that both of these design decisions of the language actually make it more ergonomic to use (and consume) not less.
Its also worth noting that I mentioned multiple times authors/creators and consumers. Terraform is very much designed around being consumed and read, almost like documentation. If you talk to Hashicorp this is a huge motivation behind the DSL that is HCL. It was designed that someone who has minimal Terraform knowledge could use modules to create powerful infrastructure within a company. This is how we use it in our company. The SRE/Platform Engineers (where I work) build very advanced, complex, and powerful modules that are easy to consume with a handful of variables.
We have developers that can spend a few hours learning Terraform and know enough to build production infrastructure within the company that is built to our design standards and security compliance requirements. They often don't even have to know what that is, they just declare a network, a database, and a cluster of compute with a handful of parameters that are auto-documented and they end up with some incredible infrastructure as a result. This is what Hashicorp is designing Terraform around. If you meet with them or go to their conferences, this is the direction and purpose of Terraform and how they designed it. A handful of Terraform experts at a company can create modules that are consumed by developers that have minimal knowledge of Infrastructure or Terraform. Its a powerful system.
in terraform I can't do this
I suppose you could say the same about Terraform using HCL - but that makes extensive use of it being declarative, which is so unusual that they'd be picking an obscure probably-new-to-the-user language anyway. This just looks.. JS-ish, a bit like anything really.
I suppose I'm asking what are the language features that make Wing great for 'cloud', any `new Bucket()` etc. aside?
If you look at its 'design tenets', the only ones that are about the language not the SDK are just saying 'be good/familiar like other languages'... Ok so why not be another language? https://docs.winglang.io/reference/spec#02-design-tenets