Creating an Entirely New Programming Language with Elad Ben-Israel, Co-Founder & CEO at Wing Cloud

(Intro Narrator at 00:00:00) Today, we're talking to Elad, co-founder and CEO at Wing Cloud, about how they're creating an entirely new programming language. You're listening to Joel Beasley, Modern CTO.

(Joel Beasley at 00:00:16) Now the way I found out about you guys, I was scrolling through LinkedIn and I saw this company raised a bunch of money and that they were building a new programming language. And I was like, what? There's a lot of programming languages. Why, what are they doing?

(Joel Beasley at 00:00:31) And then I started digging into it and I thought it was absolutely fascinating. So I was hoping you could tell me what Wing Cloud is and why you decided to make this new language.

(Elad at 00:00:43) Yeah. Obviously, that's the first question everybody's asking. I think the easiest way to think about it is that if you think about cloud and how we're building applications for the cloud, you're realizing that the tools that we're using to build those applications, like the programming languages, they're generally designed for computers as machines. And so, throughout the history of programming, we've developed programming languages to tell machines what to do. That was the original reason why humans invented programming languages. Right? Because I'm creating some kind of human readable syntax in order to tell one machine what to do. And that's what programming languages are great for. And throughout the history of programming languages, we've slowly evolved this paradigm of telling the machine what to do. And we're today at the point where—and again, when I'm talking about programming language, I'm talking about the programming stack in a sense. It's the language, it's the standard library, it's the operating system, it's everything that I use in order to implement my business logic, my application functionality on that machine.

(Elad at 00:02:08) And we've reached a point where we really do have a great abstraction for that. When I open up a Java program or a Node.js program or a Python program, I really do have a great abstraction for this concept of a machine. Right? I want to write a file, then I just do FS.WriteFile. I want to allocate a dictionary in memory, I do new dictionary. I don't care about the mechanics. I don't care about how much memory I need in the RAM. I don't care about the structure of my files in my file system. Right? All of those things are abstracted away from me. And not only are they abstracted away from me, I actually have a pretty portable abstraction in that sense. Right? I can actually take this Python program and run it everywhere. Right? I can write it on Linux and Mac and Unix and wherever I want, and it'll, in most cases from a functional perspective, behave the same way. And so if you look back—and I'm old enough to look back—I've programmed in BASIC and C and Pascal and C++ and Visual BASIC and Objective-C and Swift and all of that. And so if you look back at this history of programming languages, you've realized this is what we've been doing. We've been basically perfecting this abstraction for a machine. And now you look at cloud applications, systems, services, and you realize we're no longer building applications that run on a machine. We're building applications that run on this distributed system that includes all these managed services, that runs on, you know, where my code is running on all these containers and serverless functions and jobs and workflows. And the languages haven't caught up to that new paradigm in a sense. Right? The languages that we use are basically designed to tell one piece of cloud what to do at every single point. Right?

(Elad at 00:04:12) So as you write your code and you use this amazing abstraction that we've created for this one machine, and then you compile it, and then you get this executable, you say, okay, so now I have this one executable that knows how to run on one machine. How is that related to my cloud application? That's out of scope for the compiler. That's out of scope for the language. Right? That's a different thing. And then what happened is, obviously, we as engineers needed to solve this problem. And so we started creating tools to orchestrate the execution of those single machine programs. And so we created things like Kubernetes, or we created things like serverless, and we created things like infrastructure as code, and we created things like CI/CD technology.

(Elad at 00:05:01) And all of those tools are generally designed to stitch together all of these small little programs to form my cloud system or my cloud application. Right? That's basically the reason those tools exist. And I think each one of those tools is extremely powerful and valuable, and there's this amazing innovation, amazing technology behind it. But those tools were particularly designed for how to run my application. They're not designed on how to describe my application. And so what happens is you end up as a developer having to describe your application in a very piecemeal way. Right? You say, okay, I'm going to write my FIFO code, and that describes how this one node is interacting with the world. But then I'm going to write my Terraform to describe the infrastructure. So I'm going to learn how to use HCL. I'm going to write Terraform. I'm going to need to understand all the cloud resources and all their surface area. And I'm going to need to basically specify my CI/CD pipelines. And so I'm going to learn this new tool that specifies my CI/CD pipeline. And I'm going to need to take my code and bundle it and upload it to the cloud and make sure that my infrastructure references. And so you end up spending 80% of your energy just gluing together all those pieces because we don't have a unified model that can describe the entire system. And this is what WingLang is. Right? It's basically a language that's designed to think about the cloud as this computing platform.

(Elad at 00:06:44) And I don't think that there are other tools that are designed like that because, again, I think it's a maturity question. Right? The cloud is evolving as a computing paradigm. And I think we're at this time where we can take a step back and say, okay, what is this computing platform? What is this platform, right, that we're building applications for? And AWS is not the platform. Azure, GCP is not the platform. To me, the platform is this abstract concept, kind of like POSIX, you know, which I adore. And what was POSIX?

(Elad at 00:07:33) POSIX was exactly the same exercise, you know, thirty years ago, I think, done for machines. Right? It's like, okay, so what are the requirements from an operating system in an abstract way? It wasn't about a specific operating system. It was about applications. It's about how applications are interacting with this machine, right, with the operating system that runs the machine. And POSIX changed the world in many ways because it enabled this portability. It enabled applications to actually have this solid abstraction that they can build against, and then operating systems could implement that abstraction and allow these applications to execute. And, you know, we have Unix and Linux and the world is basically POSIX today. Right? Everything is POSIX besides some last resort, some Windows stuff that people are—I don't know. Does that make any sense? Does that make any—

(Joel Beasley at 00:08:34) Yeah. Yeah. So I understand the concept that you've abstracted this, and it would probably help if we went down with a really concrete example. So let's take somebody. I'll give, I'll talk in the area where I'm most knowledgeable. I spent the last, you know, seven years or so building Ruby on Rails applications. Right? And so we touch things like, we'll maybe do some Elasticsearch or, you know, we'll have a Postgres database, got some Rails models and views and all of that. And then we'll be using, you know, Postmark for our API to send out the emails and, you know, all this different stuff. So how would I, managing a, you know, single tenant type Rails application and having, you know, a handful of these services. And of course, we, you know, we use Jenkins, you know, CI/CD type situation and recent tons of, you know, gems as well for Ruby. So how would I look at, okay, what I currently do today and how could I apply Wing Cloud to that?

(Elad at 00:09:40) How do you deploy your application?

(Joel Beasley at 00:09:43) Heroku.

(Elad at 00:09:44) On Heroku.

(Joel Beasley at 00:09:45) Yeah.

(Elad at 00:09:48) So, basically, you need to take a step back and think about your system. Right? And so what does your system contain? It contains some kind of a service. Right? A long running service, which runs your Rails application. But it also contains—

(Joel Beasley at 00:10:06) Oh, nice. We got kids. I've got three kids.

(Elad at 00:10:08) How old are yours?

(Joel Beasley at 00:10:09) Friday. Hey, buddy. Your dad's the coolest person ever.

(Elad at 00:10:14) He can't hear you. And or, or another—

(Joel Beasley at 00:10:16) You can tell him. You can tell him.

(Elad at 00:10:20) Sorry about that.

(Joel Beasley at 00:10:21) One girl and two boys.

(Elad at 00:10:23) Oh, wow. Nice. How old?

(Joel Beasley at 00:10:26) My daughter is six, and my son is four and a half. And then my other son is about eleven.

(Elad at 00:10:34) Okay. So our kids are that age, which is a beautiful age.

(Joel Beasley at 00:10:39) Yes. Yes, it is. I always like talking with other dads in technology. I've got dad questions for you later. But I'm really trying to understand right now.

(Elad at 00:10:48) Sure. So, yeah, let's go back to your Rails application.

(Joel Beasley at 00:10:51) Yeah.

(Elad at 00:10:51) So basically, you have a service, but you also have other resources, cloud resources that your application is using. Right? And so you have your Postgres database, AWS storage, Postman, your AWS, some AWS stores. And so the idea is that you use Wing to describe your entire application. And so you write some Wing code that says new service, new Postgres server, new Postman system, etc., etc., etc. And when you say new service in Wing, you actually talk about a service in an abstract way. You don't care about where is it deployed, what technology do you use to deploy it. And for example, one of the things that we're working on right now is supporting containers. And so you'd be able to basically say, I want the service to run this little Docker image or Dockerfile. Right? Build this Dockerfile for you and make sure that it's running. And so you get this basically abstract model of your application. And when you say new Postgres, then you use a Wing library that implements Postgres, that implements the API of Postgres.

(Elad at 00:11:56) And one of the key tenets of Wing is what we call multiplatform, or it's basically dependency injection. You're familiar with the idea of dependency injection? And so Wing, one of the interesting things about Wing is that it has basically built-in dependency injection in the language. And what that means is when you do new cloud bucket or new cloud service, then you're basically instantiating abstract classes, which is kind of mind-blowing a little bit, you know, because I grew up on you can't instantiate abstract classes because abstract classes are not a concrete thing in memory. But for all intents and purposes, this is what you want to do. Right? I don't care how my cloud bucket is implemented. All I care about is this cloud bucket is a place where I can put objects and get objects and list objects. So it has a very clear contract. Think POSIX again. Right? There's an interface that buckets have to implement, which is exactly how dependency injection systems work. Right? Basically, I'm like, give me something that implements this interface. And you say new cloud service.

(Elad at 00:13:09) And so one of the key ideas in Wing is that every resource, every class in Wing can have multiple implementations based on the platform. So the platform that you're compiling to basically defines the implementation of those resources. And one of the platforms that we provide with Wing as a built-in platform is a simulated cloud. So it's a cloud simulator, basically. And so when you're doing new service, you're basically instantiating the container locally in your machine. And when you're doing new Postgres, you're basically starting a Postgres image on your machine. And from the application's perspective, there's no... Right? Your application code can interact with the Postgres or with the Postman service, and the beauty of being, of building above that abstraction is that now you can actually test everything locally, and you can write unit tests that exercise the entire system, either on your local machine or in your CI system. And then you can decide how you want to deploy it, and you can pick what we call Wing platform libraries. So you can basically say, I want to use the platform library for Heroku, or I want to use a platform library for AWS and use Terraform.

(Elad at 00:14:29) So it's basically a combination of the operating system, AWS, and the instruction set, which is Terraform in this case. Right? And you can also create custom platform libraries. So you can basically say, I want to build my own custom platform library. And so let's say you're an organization and you have some compliance rules or some policies or you want all the buckets to be—

(Joel Beasley at 00:14:52) I get it. It took me twenty minutes, but I get it. You get that a lot?

(Elad at 00:14:57) It's my fault. And we're, you know—

(Joel Beasley at 00:15:01) No, no, no. We're—

(Elad at 00:15:01) We're tiny, we're just getting started. And we're one of the things we're trying to learn how to do is tell our story.

(Joel Beasley at 00:15:07) Yeah. Well, here's the problem with it. So I'll share with you mine since I think I got it. But I'll share with you sort of my journey of how I was thinking about it. At the beginning, because I'm in, you know, application development, I'm not a cloud ops person, you know, spending all my day dealing with that type of situation. I was thinking about how do I use this to build applications. That was my first thought. And then I understand now, my next train of thought goes over to I do have friends and I do get to talk to people on the show that they're managing crazy amounts of instances of various servers and booting stuff up constantly, and they have incredibly complex Terraform and, you know, AWS config files and all of this stuff. And I can really see how if you're a cloud ops type person—you can correct me if I'm wrong—but if you're a cloud ops type person and you have all these, essentially, we'll call them properties like real estate. Right? You have, you know, you have storage, you've got your Amazons, you've got your Kubernetes clusters, you've got all of these different things that you have to manage, and the knowledge of all of them woven together exists sort of in an abstract concept amongst the team of people who are working on them.

(Joel Beasley at 00:16:28) And you're instead saying we're going to create a language that takes it away from that team of it all kind of being in their active memory as humans, and we're going to put it down into writing so that that whole entire team could just, you know, explode overnight, and you guys don't skip a beat. You go and you have your document that essentially you pull up your Wing config or whatever you're calling it, your Wing Cloud, and you're like, this is how our stuff operates. Am I kind of in the right neighborhood?

(Elad at 00:16:56) You're in the right neighborhood, but not exactly reached the right house.

(Joel Beasley at 00:17:02) Bring me home.

(Elad at 00:17:04) So there's something really interesting about the way you describe it, which I think makes a lot of sense. When an organization uses the cloud, there's usually some kind of separation between the application and the platform. And in most cases, that separation is not very well defined. Right? I'll give you an example from the Kubernetes space, for example, where there's a cluster. The Kubernetes cluster, which is definitely part of the platform. But then there's a bunch of Kubernetes resources for the application.

(Elad at 00:17:39) And those Kubernetes resources that are part of the application, they're part of the platform's — sorry, the YAML files that you're applying to your Kubernetes cluster or the Helm charts that you're adding to your Kubernetes cluster, but they are part of the application. Right? They're distinctly — like, every application that I create on this cluster would need a copy of those resources in order to be able to deploy: the deployment and the service and the ingress rules and the stuff that are specific to the application.

(Elad at 00:18:21) However, because of the current tooling landscape of the cloud, those resources are, in a sense, part of the infrastructure or part of the platform. Right? The responsibility of those resources is either on the DevOps team or the platform engineering team, or they're kind of partially owned by the developer. Because you talk to developers — yeah, you know, the DevOps team told me that when I want to add an ingress rule to my application, I need to go to this repo and update this line in the Helm chart.

(Elad at 00:18:54) I really don't know exactly what I'm doing, but it kind of works. And then I go and I commit this, and I push it to my staging environment, and then I can test it and verify that it's working. So the point I'm trying to make is that there's this line between the application and the platform, and developers aren't really able to maintain parts of the application that belong to the infrastructure that are above the line.

(Elad at 00:19:26) And so to your point earlier about knowledge, kind of like distributed knowledge and abstract knowledge. What we're trying to do is we're trying to basically formalize this line and give platform engineers and DevOps teams the ability to define what is the platform. Right? Like, what is the platform that their organization uses? And they can use a ready-made platform that we have, or they can completely customize it depending on their needs and on their complexity and regulation and stuff like that.

(Elad at 00:20:00) And by defining this platform, they basically give developers the ability to build applications on top of that platform. And so you as an application developer, now you have this high-level language, strongly typed, IDE supported. You know, you have a much better tool than going into some repository and editing a Helm chart. And not only you have that tool, you can also run your entire application locally on your machine, which is something that is hard to do. As the more you use the cloud, the more you lean on cloud resources, the harder it is to — yeah, you say you have a monolithic application, but what about the Postgres?

(Elad at 00:20:45) And then what about the emails? And what about all those things that you're thinking are outside of your application? They're actually not really outside of the application. They're part of your application. But the tooling today kind of dictates that you're thinking about them as something that's outside of the application, if that makes sense. And so Wing basically brings all of that together into a single model that you can run locally.

(Elad at 00:21:10) We're actually working on this feature of preview environments. Right? So you can basically push your code like Vercel has. Right? You push your code to the repo, and you get access to an environment that basically has your latest app — your latest code deployed, and you can play with it and test it and check that it's working. And it includes your Postgres.

(Elad at 00:21:31) It includes your Postman implementation. It includes everything your application needs, not just your monolithic process, because that's not the cloud. That's not how you build stuff on the cloud. Right? These monolithic processes are just part of the picture.

(Elad at 00:21:48) Does that make sense?

(Joel Beasley at 00:21:50) I'm kind of getting it. Yeah.

(Elad at 00:21:53) Yeah. It's kind of hard to explain it without a demo.

(Joel Beasley at 00:21:57) I agree. Yeah. I think if I just saw it — because when I saw your website, I was like, oh, that's awesome. I see you have a playground. So let's tell people about that. There's a Wing playground.

(Elad at 00:22:08) Yeah. Check out the tutorial. I think the tutorial should be a pretty good way to get a — yeah. It's really light and quick. And I think it should give people a good sense of the general ideas behind Wing and why we're building a language — why does it need to be a language? Right? I think that's the first question a lot of people are asking.

(Joel Beasley at 00:22:31) That's better than Terraform is just a config file. Right? Well, if it's a language, you can do more stuff with it. If it's just a config file, you're kind of limited.

(Elad at 00:22:40) So if you compare it to — if you only take the infrastructure side, yes, you're right. But the beauty of Wing is what we call the inflight phase. And that means that you're not only describing your infrastructure, you're also able to describe, if you want — you can also describe your application logic with Wing. And when you describe your application logic with Wing, that logic can seamlessly interact with the infrastructure. And so you can actually say "bucket.put" inside your application, inside your inflight code, and we will take care of all the gluing and wiring and permissions and everything that needs to happen in order for this inflight code to interact with your infrastructure.

(Elad at 00:23:23) And so crossing these boundaries — call them space and time boundaries. I don't know if you want to hear this. It's a bit of a snooty — I can give you a little bit of a philosophical view. Think about the origins of programming languages. When you're writing code in a traditional programming language, the output is basically a list of instructions that go into a single CPU and are executed over time. So there's basically just a time dimension, right? It's one dimension. Now, if you're building applications for the cloud, there's also a spatial aspect to it.

(Elad at 00:24:10) Right? There's an architecture. Right? There's code that runs in this container, in this container, in this Lambda function. You're building this distributed system. So the distributed system also has this architectural definition.

(Elad at 00:24:25) And the existing languages are only describing this one line of execution every time, all over time. So in a way, the preflight phase of Wing is needed in order to describe this additional dimension, rather than just basically this new dimension in the program that is the spatial dimension. So the preflight is basically a way to describe the architecture, the spatial. It's like, this is going to be here, this is going to be here, these are going to be connected, this is related to here. There's also this hierarchical structure in Wing, so you can basically compose things together. And so you can create classes and you can put in the class a bunch of other objects.

(Elad at 00:25:08) And once you do that, it'll create this abstract unit, this composable unit. And so this is the preflight. And the inflight is the time dimension. Right? This is what happens over time in this specific machine. Every time I specify the inflight — I don't know. What do you think about this analogy? I'm wondering if it's helpful or it's just more confusing.

(Joel Beasley at 00:25:34) Well, I'm kind of getting it. Okay.

(Elad at 00:25:37) Thank you. Appreciate it.

(Joel Beasley at 00:25:40) I'm kind of getting it. I feel like you should call Martin Fowler and say, "Hey, bro, can you write a book on this?" But yeah. Look, when I started the podcast, I started seven years ago. And for the first couple years, I was still involved as a team lead of writing production code. In the past four years, I haven't been in it a whole lot. I've also never gotten to the point where I'm managing a large-scale system in the sense that there's hundreds of people involved in having to work together in configurations and permissions. I've always been startup, so I always have god mode permissions.

(Joel Beasley at 00:26:21) You know, I just do what I want. I'm not filing tickets, requesting stuff, and I'm not building software that was required to have these crazy audit trails and all these different things. So some of the concepts you're talking about are a little bit new to me. Also, you guys — the reason why it caught my attention is because, you know, I know enough to know that I believe — like, if I had to bet money, I'd bet money that this is the future simply because all you're doing is following history. Right?

(Elad at 00:26:54) Exactly. You're just — I'm old enough.

(Joel Beasley at 00:26:55) Another abstraction. Yeah. Yeah. Yeah. And I'm old enough to see it too. Right? Because it started — I remember when I first found ORMs. Right? And I was like, "Oh, man." I was manually transacting with the database, you know, with PHP code and as needed. And I thought I was all cool because I abstracted some of this into a database class, and I could interact a little bit easier. That's right. I thought I was brilliant. And then I found frameworks and ORMs, and I was like, "Oh, there's an abstraction." Then they got more advanced with the newer databases that had come out, so you didn't have to think about the database as much.

(Joel Beasley at 00:27:31) And you could literally define new tables by just adding a symbol in a file, in the model file. And then everything completely broke.

(Elad at 00:27:39) And it just kept going like that. Everything completely broke.

(Joel Beasley at 00:27:41) Yeah.

(Elad at 00:27:42) And then reincarnated in non-relational databases.

(Joel Beasley at 00:27:47) Yes. Yes. And so that just keeps going, and it keeps going, and you just have to think less and less about it, and the abstraction comes up. As long as that abstraction gives you speed — well, speed is time is money. Right? So if the abstraction buys you time and makes you money through that, then people typically will adopt it because they're out there in the job market. Companies are trying to be competitive. They're trying to do more with less. It's an efficiency thing.

(Elad at 00:28:19) Yeah. I mean, obviously, I agree. I always like to tell people, you know, because there's definitely a lot of — it's interesting, but there's a lot of skepticism in the software industry about abstractions, which is kind of almost an oxymoron as far as I'm concerned, because there wouldn't be any software industry without abstractions. Right? That's the essence of software. And I always tell people, you know, like, do you know how many layers of abstraction you go through when you move your mouse a little bit on your screen? You know, how many layers of — and this mouse is this idea, right? That you're, like, oh, I'm just pointing on something. It's like, even that is an abstraction. Right? Your brain is thinking about this little arrow as, you know, something that allows you to point into something. Having said that, I also really respect the art and science of building abstractions.

(Elad at 00:29:21) Right? I feel like it's really, really easy to get them wrong, and it's really easy to screw them up. And it's really easy to create abstractions that are leaky. And I think that's been a very — are you familiar with that terminology, like leaky abstractions?

(Joel Beasley at 00:29:39) Instinctively, I would imagine it's like, you know, with Cucumber where you could kind of start describing code as plain English and writing tests and stuff, but it kind of didn't work very well. Is that what leaky is?

(Elad at 00:29:51) Yeah. I mean, leaky abstraction is basically an abstraction that requires that you understand the underlying system.

(Joel Beasley at 00:29:58) Okay.

(Elad at 00:29:59) Right. That you can't really use in a reasonable way without fully understanding the underlying system or not necessarily fully understanding — is that the underlying system keeps leaking out of the abstraction. Right? To the file system example, think about the fact that you would, you know, maybe you would try to write a file, and you'd have to know that you're running on a specific file system, and then you'd have to specify some ending character based on the specific file system that you're running. And so that means that this whole abstraction is worthless because you'd have to know exactly which file system you're targeting in order to use this abstraction.

(Elad at 00:30:40) So why? It's not an abstraction. I might as well just use the direct interface of that file system. Right? I don't know if it was a good example, but leaky abstractions are very, very common. I know that some people say that there are no non-leaky abstractions. Every abstraction to an extent is sometimes leaking in. Even if it's beautiful and very solid, it'll eventually somehow leak out because systems are different, you know, and platforms are different. And if you use file watches in Node.js, you'll realize that they don't work the same way in Windows and on Mac and on Linux because, you know, the file system, the underlying system, behaves differently.

(Elad at 00:31:24) And then as much as they wanted to create this beautiful API, they really failed. And then you have sort of specific flags for Windows and specific flags for — and I think this is one of the hardest things to do when you're the first people, the first person, trying to create an abstraction for something like the cloud. Right? And I don't think that we're the first, but I think we're definitely really trying. I think a lot of people tried and gave up. And I think the timing — there's a timing dimension here. It depends on the maturity of the underlying model.

(Elad at 00:32:04) Right? Because when you want to create a good abstraction that abstracts two different systems, you really need those systems to have some stability, and you really need to understand these two systems or end systems in order to be able to actually determine what's the right common denominator and what's the right intention of the user so that you can think about that intention when you're creating the abstraction. And I think that's a matter of the evolution of the cloud as a paradigm and, you know, how people are using it. And, you know, I've spent about seven years at Amazon, and I've seen how Amazon has been kind of using the cloud and evolving its understanding of the cloud. And, you know, there are still tons of services internally at Amazon that think about the cloud as a bunch of machines. Right? That's the abstraction that they use. But there's also tons of services in Amazon that use serverless computing and Lambda, and the cloud is just a bunch of functions and resources. And so it's really interesting to see how our understanding of this computing paradigm is evolving.

(Elad at 00:33:20) And what we're trying to do is we're basically trying to codify that understanding, codify these ideas of what people perceive as what is the cloud. And that's why, you know, I gave you that example. It's like when you're thinking about your real application, you're basically thinking about this long-running service. And so that is in a way the mental model you have when you're — maybe. I'm proposing that that's maybe the mental model that you have. Yeah.

(Elad at 00:33:39) Other people might say the mental model is events, right? Like, you're just implementing something that reacts to events, and then that's a very different mental model in terms of architecting your system and how you want to describe your system. And so, as I said, I agree with you. I think abstractions are king of software, of computing, of technology. That's how evolution happens.

(Elad at 00:34:05) But I also think it's really hard to screw them up. And I think this is one of the reasons, you know, I'm a huge believer in open source, because I think open source as a way of life, in a way, is a great way to make sure that you're constantly connected with reality and you're constantly connected with what people actually, how people actually use what you're doing, because you get this instantaneous feedback. You get these signals from the community about where you screwed up and where things are working. And so, kind of like embracing the fact that software is malleable and organic, and that's how I believe in building good abstractions, is about giving that software to evolve and get to the right level.

(Elad at 00:35:01) Right? And it's really interesting. I love, I've been doing this for many years. I've done that at AWS too, and I love this work. I feel like it's, you know, pure design work, right? Like, it's kind of trading off constantly and thinking about ergonomics and fun things.

(Joel Beasley at 00:35:21) When you're selling to a company, when this is becoming a thing, what's the business case? Like, if I'm a CTO and I'm listening to this and I said, I just listened to this guy talk about this Wing Cloud thing for a little bit, sounds like it could be interesting. I might go to my DevOps person or, you know, one of my engineering leads and tell them to check it out. But before I do that, I want to know. Like, let's say the DevOps people and the engineering people are like, yeah, this is cool. Before I even present it to them or talk to them or show it to them, what's the, like, what would this do for my business? Like, why would I care? Why would my executive peers care about this?

(Elad at 00:36:01) So in a sense, it's basically why platform engineering teams, the platform engineering discipline, has started to kind of emerge. And the way I'm thinking about it is this goal of platform teams and platform organizations is to give developers the ability to self-serve, to be independent and build independently within the boundaries and constraints and regulation and compliance and platforms of the organization, right? Like, that's the reason platform engineering teams exist, or at least that's half the reason, let's say. Like, half the other half is usually to operate the platform that the organization is maintaining. But they're service providers in many ways. Like, their goal is to provide service to the organization so that developers can independently operate and won't have too much friction between developers and the platform, again, within those boundaries. And so in a sense, this is why, this is what Wing is offering, right? Like, it offers this decoupling. It offers the ability for platform engineers to define the platform and for developers to build applications on top of those platforms. And when I say applications, I mean infrastructure and runtime code that are combined together, right? Like, the, so applications that not only run in a single container, which is, you know, we talk to tons of people and almost everybody is using Kubernetes nowadays, which is amazing. I think it's crazy to see how this technology is so popular.

(Elad at 00:37:45) But there's nobody that only uses Kubernetes. So there's always, you know, with the example that you gave with your Rails application, there's always cloud, right? The power of the cloud is the ability to lean on those resources, to lean on those services. And what I'm seeing a lot is that in the Kubernetes space, again, the same way you've just, you know, you've talked about those external resources, that basically everything that's outside the Kubernetes cluster is considered an external thing. And you see all these hacks and tweaks and customizations and weird, you know, setups just in order to give developers the ability to build their application code. And so the ability to kind of create this boundary between platform and application, and that boundary is enabling developers to run locally, which is in many ways a superpower for developers. It enables developers to write unit tests for the cloud, which is something that I think is almost a holy grail. I don't think that anybody's really doing that.

(Elad at 00:38:58) But because we have the simulator, then now I can actually write a test that crosses my entire system, right? Like, it's not just testing my application code. It puts a request into my API gateway. It checks that the request goes into my application, sends a message, puts a file in the bucket, and I can write a test that basically checks this whole thing. And that test runs locally on my machine and runs in my build and can run at every cloud target that I'm compiling to. So if there's a situation where, and we've seen that a lot with vendors, right, that build SaaS, that build software as a service that needs to be self-hosted sometimes. If there's a situation where you actually need to deploy your application in customer accounts, and those customer accounts could be in different cloud providers, then you're in, you're in hell, basically, right? Like, and so you're either just shoving, trying to shove everything into your Kubernetes cluster, which is not a good, it won't work, because if you want a bucket, it's not going to be in your Kubernetes cluster.

(Elad at 00:40:00) Or you end up, again, with creating these external connectivity and, you know, we talk to customers that, yeah, I have to maintain a different Terraform for every cloud provider because those are different. And so this portability is something that's very, very valuable to some customers. And the other thing is basically preview environments, right? Like, the ability to actually instantly interact with your code before it's deployed, before it's merged. That's also something that's getting harder and harder the more you're using the cloud and you're leaning on the cloud. And the last thing is an application management experience. That's basically, kind of like, after you've deployed your system to production, and, you know, that's something that we don't have yet, but that's where we're going in a way. Once you have your application deployed into production, then we're going to give you this console, this application management console, that allows you to interact and see your application with the same view that you used during development. So kind of, again, putting this line between application and platform and then following the slide throughout the application development life cycle, which is kind of like the big vision, I guess. Did that make sense?

(Joel Beasley at 00:41:20) Yeah. So I would say if the question would be, you know, how is this meaningful to the business? It would make your platform engineering teams more efficient and the developer experience higher quality?

(Elad at 00:41:37) Yes. And enable some use cases that you don't have today, like testing, like portability across providers. Those are things that are really hard to achieve. And most people just give up on them. I'm just going to not test. Just, to me, is a really, really big thing.

(Joel Beasley at 00:42:00) How mature is this project?

(Elad at 00:42:03) So we're super early. Basically, released the first open source just the beginning of the year, and we hope to release our beta, basically, you can get to beta by the end of this year. And but, and again.

(Joel Beasley at 00:42:22) So you're not something we can buy today?

(Elad at 00:42:24) Nope. We're starting to onboard, we're starting to onboard some private beta partners for those commercial offerings like preview environments and application management, but it's not open for self-service yet. And the open source project is still very early as well. It's a big, it's a big endeavor, but I'm, we're super excited by it. And we're using, you know, the stack ourselves, and we're really having fun with it.

(Joel Beasley at 00:42:54) Yeah. Yeah. No, that's brilliant. I think you guys are definitely doing something unique and interesting, and I look forward to, you know, continuing to follow as you guys, you know, grow and explore and find your thing. If I had to put money on it, I'd bet you'd end up competing with a Terraform or a CloudFormation or something like that, and then you would just do that but better. That's for me, if I just take a step back and I walk away and I'm going to go talk to, you know, my buddy Derek about it, who's also an engineer. And if I were to say, hey, I talked to this guy today. They're doing something like a more interesting, like, think of if Terraform and CloudFormation, if those instead of just being the text files, at least they were when I was using them. It's like you got a programming language wrapped up in it so you can do more with it. If I said that to him, he'd be like, oh, that's pretty cool. Let's go check out what the more is you can do with it. And that's how my brain will process this conversation, even if it's inaccurate.

(Elad at 00:43:54) No. I think it's definitely a valuable use case for WingLang. And as I said earlier, WingLang compiles to Terraform. It compiles to CloudFormation. And so it's not like we're trying to replace Terraform because I think that Terraform is solving a very specific problem. It's solving the resource provisioning problem, which is a really important piece of, you know, building, building stuff from the cloud, delivering to the cloud. And so in that sense, it's not competing with Terraform, but it's maybe competing with HCL, right? I guess the language for describing those resources. I do think that one of the interesting things, more than one of the more interesting aspects, is this abstraction. And to that end, not in either Terraform nor CloudFormation, most of those solutions are low-level, right? Like, they're still working at the level of the cloud resources. And what we're trying to do is we're trying to raise the abstraction a little more and create an API, create a library that allows you to build applications without caring about those nitty-gritty details of the DevOps, in a sense.

(Joel Beasley at 00:45:10) Well, I'm glad that there's smart people like you out there pushing the world forward. I am by no means an expert in that area.

(Elad at 00:45:18) No. I mean, to me, it's really inspiring to have such amazing, you know, backers and partners and, you know, I worked many years in, you know, in Amazon and before that, Microsoft, and kind of tapping into the startup ecosystem and venture funding ecosystem is like finding all these amazing investors and partners and people who are really into making an impact and helping solve real problems. It's inspiring. You know? For us, being able to go and build this thing, to me it's like I didn't have a choice, right? Like, I have to build this thing. And so the fact that I was able to find these amazing partners and backers is really inspiring. And I'm really excited about the fact that humanity has reached a point where, you know, a group of geeks sprinkled around the world was able to go and build this thing. It's like, okay, let's just, you know, go try and do this, right? Help change the way people build applications for the cloud. So to me, it's really amazing. You know, I feel like it's pretty cool.

(Joel Beasley at 00:46:32) Yeah. Well, if you make people's lives easier, they'll line up and hand you their money. Thank you so much for listening. And if you found this episode useful, please share it with a friend or colleague who you think would get value from it. And if you have topics that you'd like to hear discussed on the podcast, either add me on LinkedIn or send me an email, [email protected]. Every time I get an email or LinkedIn message, it absolutely makes my day and inspires me to keep going.