Hypercomplexity with Aldo Bucchi

Episode Description

Aldo Bucchi discusses the epidemic of 'hyper complexity' in modern development and how his project Lambdragon aims to tackle it at the language level.

Episode Summary

In this episode, Aldo Bucchi joins Anthony Campolo and Christopher Burns to share his self-taught coding journey, which began with viewing source code in Internet Explorer in the mid-1990s, and explain how that curiosity-driven approach shaped his career in research and tooling development. The conversation centers on Aldo's thesis that the software industry is experiencing an epidemic of "hyper complexity," driven by trends like full-stack development, microservices, and monorepos that have caused the complexity of everyday codebases to explode exponentially — a problem once confined to companies like Google and Facebook. He argues that the current wave of startups building faster compilers, build tools, and caching systems are merely treating symptoms rather than addressing the root cause, creating a cycle he likens to "tooling addiction." Aldo proposes that the real solution lies in retrofitting proven programming language concepts — encapsulation, composability, metaprogramming, and high-level abstractions — into the JavaScript and TypeScript ecosystem, which is the mission behind his project Lambdragon. Drawing inspiration from Rust's cohesive toolchain design, the discussion touches on SWC compatibility challenges, the promise of GraalVM, and the philosophy that framework and tooling developers bear a serious responsibility to reduce complexity rather than add to it.

Chapters

00:00:00 - Meet Aldo and the Self-Taught Coding Journey

The episode opens with introductions as Aldo Bucchi shares his origin story: he learned to code by clicking "View Source" in Internet Explorer around 1996 and taught himself from there. He explains that the difficulty of finding educational resources in those early days forced him to develop a distinctive problem-solving methodology that still serves him today.

Aldo describes how this self-directed learning approach naturally led him into research work for companies building real products. His role involves looking into the future, understanding emerging technologies before they become mainstream, and then bridging the gap between deep technical research and practical application — particularly with startups tackling poorly defined problems.

00:05:02 - The Hype Cycle and Building Your Own Framework for Importance

Christopher Burns highlights how developers rarely get time to deeply research the things that interest them, and Aldo responds by warning about the "hamster wheel" of chasing whatever the community deems cool each week. He stresses the importance of developing a personal framework for evaluating what truly matters rather than relying on social buzz and marketing signals.

Aldo positions himself not as a contrarian but as a realist who insists on having logical reasons behind his opinions. He notes that after 25 years of coding, building compilers, and learning eight programming languages, he sees recurring patterns everywhere. The hosts briefly discuss whether computer science is a finite domain compared to fields like medicine, and draw a playful analogy between UI trends and the fashion industry.

00:08:37 - The Hyper Complexity Epidemic

Aldo introduces his central thesis: developers are suffering from an epidemic of hyper complexity. He explains that over the past several years, the complexity of typical codebases has grown exponentially due to the network effects of adding tools, frameworks, and configurations that all interact with each other. Trends like full-stack development, microservices, and monorepos each offer real benefits but collectively push projects past a tipping point.

He points out that hypercomplex codebases used to be the exclusive domain of tech giants like Google and Facebook, who had years to build internal tooling to manage them. Now, small teams face the same complexity explosion without those resources, using tools designed for a simpler era. Christopher shares his own painful experience with a monorepo that chained incompatible dependencies together, illustrating exactly the kind of cascading problems Aldo describes.

00:17:43 - Treating Symptoms vs. Solving the Root Cause

The discussion shifts to the current landscape of developer tooling solutions. Aldo argues that the industry is focused on treating individual symptoms of complexity — slow builds, dependency conflicts, complicated CI workflows — rather than addressing the underlying cause. He compares this approach to treating a disease's symptoms without curing the disease itself, offering only temporary relief.

Aldo warns about what he calls "tooling addiction," a cycle where developers chase micro-rewards from adopting new tools and rewriting configurations week after week, reinforced by tooling startups whose business models depend on perpetuating that cycle. He frames the key question as how to prevent complexity from building up in the first place, using the analogy of preventing cholesterol buildup rather than requiring bypass surgery after the damage is done.

00:24:07 - The Lambdragon Approach to Killing Complexity

Aldo outlines what he believes actually works: retrofitting proven programming language principles — encapsulation, composability, layering, and high-level abstractions — into the JavaScript and TypeScript ecosystem. This is the mission behind Lambdragon, a new TypeScript toolchain that aims to fundamentally reduce codebase size and complexity rather than just managing it with additional tools on top.

He shares that Lambdragon has already demonstrated the ability to cut large monorepo codebases in half without losing features, simply by tweaking how the language and toolchain work together. The project includes its own compiler, IDE integration, bundlers, and built-in frameworks, drawing heavy inspiration from Rust's cohesive approach to tooling, testing, documentation, and dependency management.

00:35:03 - Rust in the Real World and the Future of JavaScript Tooling

Christopher raises the example of 1Password rebuilding their apps with a Rust core wrapped in Electron, sparking a discussion about Rust's growing real-world adoption at companies like Cloudflare and Mozilla. Aldo explains that Rust's zero-cost memory management and its core team's disciplined, cohesive approach to tooling make it a powerful reference point for what JavaScript tooling should aspire to.

The conversation covers the trend of rewriting JavaScript tooling in natively compiled languages, starting with Esbuild and continuing through projects like Rome. Aldo argues that while these rewrites provide speed improvements, they still don't address the fundamental complexity problem. He also touches on GraalVM's potential as a polyglot runtime and shares that Lambdragon's Rust-powered compiler now matches Esbuild's speed, though SWC compatibility bugs remain a challenge.

00:43:13 - Lambdragon's Vision and the Path Forward

Christopher expresses excitement about learning more about Lambdragon, and Aldo explains that the project is in private beta, with a form on the homepage for requesting demos. He clarifies that the tool targets teams dealing with highly complex codebases — those already using or considering tools like NX or Turborepo — offering an alternative that eliminates complexity rather than layering management on top of it.

The episode wraps with Aldo discussing macros and metaprogramming as underutilized concepts in the JavaScript world, explaining how Lambdragon integrates these facilities without requiring developers to understand ASTs or compiler internals. He closes with a passionate call for more critical thinking in the JavaScript ecosystem, arguing that developers ultimately pay the price for hype-driven tooling decisions and that the community needs voices willing to challenge the status quo. The total runtime is approximately 00:54:08.

Transcript

00:00:00 - Anthony Campolo

So now that everyone is aware and conscious of the fact that you're being recorded, everyone is now being recorded. A public service announcement. Now, the way we always do: have you ever listened to the show, Aldo?

00:00:21 - Aldo Bucchi

I have, yeah, a few times.

00:00:23 - Anthony Campolo

Okay, cool. The format is almost always: we just want to know a simple description of who you are, where you work, what you do. For you, there is no simple description, so good luck with that one.

And then how you got into coding. I want to know the very first time you ever wrote a single line of code. I have no idea what that story is, and I find that very interesting to know. Then we can kind of go up to the present, and then we'll get into this huge chunk of topics you want to talk about. There'll be a couple of terms I'll want you to define, like monorepo and mega repo and stuff like that. That'll be how we'll get into it, and then we'll get into the flow. It'll just go.

00:00:57 - Aldo Bucchi

My first line of code. Oh, so first, I'm Aldo. That's my name. And that's all you need to know.

Actually, now we're going to fill in the blanks. You know how I learned to code? I learned to code by clicking on View Source in Internet Explorer back in like 1996, 1997. I had internet like everyone else, and I found it fascinating. And I realized that I could look at the code. So I pretty much taught myself to code. That was the track.

And then I kept learning on my own, and I took a very nontraditional path, I guess. But one of the advantages of having had to learn on my own, especially at a time where it was hard to come by information, because right now you have all these online classes, which would have been great, you know, in the beginning it was very inefficient to learn and to piece it all together on my own. But one of the advantages of doing it that way is that I still learn with the same strategies.

[00:01:50] Basically, I developed a way of approaching new problems. And I think that was the defining feature or characteristic of my career. You know, that kind of attitude, even though there's nothing out there that I can use as an educational resource for something, I can actually just go and look at the thing itself and tear it apart and learn.

And so that led me down a very long path, which I don't think is very interesting. We don't have infinite time, so I'll skip through that. But I ended up working on research, doing research, which is basically more of that. When you do research for companies that are actually building real products, what you're trying to do is you want to look into the future, try to understand things before everybody else understands them, because otherwise, you know, it doesn't give you any advantage. But at the same time, you have to carry a team with you. You have to lead the way, and you can't really run too far off that.

[00:02:45] Nobody can follow. So my career has been basically learning to balance those two things. And I love it, man. I mean, it's not a career as much as it is a compulsion.

00:02:58 - Anthony Campolo

It's good to hear that research is still a career that can be done today, because I've had this conversation with some people that you have things like Bell Labs. Bell Labs was really famous for having a research lab that invented things like the transistor and all this ridiculous stuff, and there aren't as many concentrated areas that are producing lots and lots of really in-depth research, but there's kind of pockets of it in lots and lots of different niches, it seems like to me. So when you say you're doing research, research into what, specifically?

00:03:27 - Aldo Bucchi

If I asked you, like, what is research, you would probably say universities have postdocs doing research and you have institutions that have labs like Nokia, Bell Labs, Oracle Labs, and so on. These guys have labs. But if you look inside those labs, you also find postdocs doing research. And that type of research is usually done by someone who is very specialized, who has accumulated an insane amount of knowledge on a very specific topic. They're very aware of where they are in the bigger picture. They know that they're focusing on something specific. They know what kind of problem they are trying to break.

If you look at the people that do programming language research, it's pretty clear what the edges of that are. Now you have a cluster of people that are trying to push those limits. The same with database technology or AI at this time. Even though research sounds like a very vague thing, it's actually very concrete in that sense.

So what I like to do is something else, something more complementary, where I try to be more general and I try to do the work that comes before going deep.

[00:04:28] I can't go deep and I can't relate, and I can't communicate well with people that are highly specialized. But I like to build the bridge between reality, the technology, and the application. So in that sense, it's more freeform. That's why I work mostly with startups.

I like taking problems that are not well defined, where people have an intuition that maybe there's something there. And then I go through this phase of obsession and just consuming all possible information. And I eventually regurgitate something that makes sense and then build a prototype. And in the process, I also find the right people. So now we're ready to go deep.

00:05:02 - Christopher Burns

One of the big things you're saying, and it's so hard in normal life, is we're all developers. We get busy, we're working jobs, we see something cool. You're saying you like to really research that thing that's really cool, and then go as deep as you can, know every little nook and cranny you can, and really enjoy your time with it.

00:05:22 - Aldo Bucchi

Exactly. Now, when you think of what people consider cool these days, we are actually in a moment in history where it's very easy to get distracted and jump in this sort of hamster wheel, where we're always searching for the next cool thing. And week after week, we shift our focus to something that is not necessarily driven by any understanding of the significance of the thing, but more of a marketing or social reaction. People are talking about this. It must be cool.

So another important aspect here is to be able to have your own framework to assign importance to the things that happen. Otherwise, you get easily distracted. So that's another thing that I try to take a step back and understand the fundamentals so that I can tell, even though everybody might be regurgitating or kind of rehashing the same information, saying, hey, this is really cool, this is where the future is going. I try to have my own opinion based on a logical understanding.

00:06:21 - Anthony Campolo

So do you see yourself as a contrarian?

00:06:23 - Aldo Bucchi

Well, I see myself as a realist, and I think I always try to have a reason behind my opinion that I can go back to, and it's becoming increasingly important. We've had a lot of discussions lately around all these tools. They appear, and I'm the one complaining, but what I'm trying to do is to remind people that you need to be able to explain why something is truly novel and will have an impact, not just because everybody is thinking that way.

Another thing: I've been coding since I was 15. I'm 40 now, so I've been doing this for a long time. After, you know, learning eight programming languages and building a few compilers and then building databases and so on, you accumulate a set of knowledge, and after some point everything is more of the same for me. It's not that costly at this time to go deep on things because I see patterns mostly.

00:07:14 - Anthony Campolo

Yeah, you see the larger structures.

00:07:16 - Aldo Bucchi

Yeah. And I think computer science isn't really that deep. Medicine is huge. It's a very vast universe, an ever-expanding frontier. It's impossible for a doctor to say, I think I know pretty much everything. But in computer science, you can, if you leave aside AI and the more statistical, non-deterministic branches. If you just talk about programming languages and processors and storage and all that, it's a pretty finite universe.

00:07:42 - Christopher Burns

It all goes down to ones and zeros at the end of the day and in its final form.

00:07:46 - Aldo Bucchi

And quantum computers are going to change that, but yeah.

00:07:48 - Anthony Campolo

It still wasn't zero. But it's ones and zeros in different [unclear] and deterministic states.

00:07:53 - Aldo Bucchi

So right.

00:07:54 - Anthony Campolo

Still ones and zeros.

00:07:56 - Christopher Burns

One thing that stuck with me: someone said when it comes to UI, it's just like the fashion industry, but software developers don't want to say it. I agree.

00:08:07 - Aldo Bucchi

Absolutely.

00:08:08 - Christopher Burns

Why are we redesigning our UIs? Every year there's a new trend, and then we go back on ourselves five years later with the old trend. It's just bonkers half the time because you're no longer in fashion.

While we're on the subject of UIs, I really want to dive into two specific areas where you seem to have vast knowledge, and that is CLIs and dev tools. You've been building and experimenting with dev tools for Redwood. I would love to get deeper into it.

00:08:37 - Aldo Bucchi

Let's do it. Let's approach this from the top. One of the hardest things these days is to be able to communicate clearly, especially in this environment where there's a lot of noise and everybody's voice is very loud. My voice is not loud. I quit social media in 2013, so I've had trouble finding a megaphone.

00:08:55 - Anthony Campolo

I was going to say, you're going to be the only person on the show that I'm not even going to bother linking to your Twitter in the show notes, because your last tweet was in 2014.

00:09:04 - Aldo Bucchi

Yeah. And it was something like, hey, I'm back after a long absence. And I don't find the motivation. Not now. I have the startup and I have something to say; things are going to change.

So for the last two years, I've been noticing that things are getting worse in general for developers. They're getting really, really hard. Four years ago, it wasn't common to spend 50% of your time fighting with build tools or configuration, or even talking about build tools. You would just start a project, set it up somehow, and then it would be all about the features. But today, it's almost like there's no time to talk about the actual features. It's all about the technology. It's all about the compiler they're using, or the framework. The conversation has completely shifted towards the meta issues.

And I've been trying to think, is there some sort of common denominator, like an underlying trend that is driving this? Because from the surface it looks very complex. When you try to approach this problem, you find pockets of issues.

[00:10:00] You find issues with build tools, configuration, compatibility between things, dependency management. It seems like it's a constellation of problems, and there's no common denominator here. But it turns out that there is something under all of this. It took me two years to start seeing it clearly, but once I put a label on it, this was like maybe a month ago or so when I started talking about this. I've seen people's reactions, and it's pretty cool. So I hope your reaction is going to be cool as well.

So what I think is going on right now is that we are going through a phase of hyper complexity. We have an epidemic of complexity that is taking over our lives in general, but more specifically in technology. What I mean by hyper complexity is that the complexity of any project, any code base, anything that we're dealing with, is way higher than what we can manage easily as a human. As developers, we have a limit. As humans, we can only remember a certain amount of words.

[00:10:56] We tend to think of ourselves as machines and that we are infinitely scalable. But we're not. We're just a bag of meat.

00:11:02 - Anthony Campolo

This is actually a really good experiment that I ran when I was in AP psych that they would do. They would give you basically a list of words that they would flash in front of you and they would say, like, remember as many as you can. And they would flash like 20 words in front of you. And then you'd have to say back however many words you could remember, and almost everyone would cap out somewhere between 6 and 8. There was an actual specific number limit that your brain, your short-term memory, could hold in its head.

00:11:26 - Aldo Bucchi

Yes, that's absolutely right. And that's the problem. We actually do have a limit when it comes to managing complexity, to managing the number of tools, the number of packages that you have. There are different concepts, and the quantity of these concepts is too high. And not just the quantity, but the relationships between things that you put in a code base. They grow exponentially. The number of relationships grows exponentially because there is a network effect. If you have TypeScript, things are fine. Then you add, I don't know, Webpack. Okay, still fine, but there's an interaction between these two. Add a testing framework. Now there's an interaction between these three things. And now you need to add coverage and add this and that. And each of these tools or each of these requirements that you add, they talk to each other.

So you have an exponential growth. And that means that at some point you reach a tipping point where this thing just explodes. It's the nature of exponential growth.

[00:12:13] What we're really dealing with is an explosion in complexity. Why is this happening? Why are we seeing this now and not ten years ago? There are a few trends that are driving this.

So one of them is the movement to full stack development, where you expect one team, one developer to actually take care of all of the different layers of an application. So that means that in this unit, this project, you now throw in more things than you used to throw in before. Then you have microservices. Microservices embrace the idea of splitting things into manageable, independently evolvable services and things. But how you connect these together, how you make the machinery for this work, adds complexity. Now you have three different projects with five different build tools because of microservices, right? Then you have monorepos on top of this. So now it's okay to make your repo grow infinitely. It's not frowned upon. That's the whole point: bring everything into the same repo.

[00:13:10] And there are more trends. But these are, I think, the major ones. Now if you look at why we are following these trends, they all give us something, right? So monorepos remove all the overhead in collaboration. Now you don't have to think about where to go to file an issue for X. It's all in the same place. So you have the collaboration benefits, removing the overhead. In monorepos and microservices, you have decoupling, independent evolvability, and the scalability that you get. Microservices and serverless are kind of related in that sense. Then you have full stack, where you evidently have more leverage if you use a framework that helps you deal with every layer.

We're chasing these benefits, but in the process of doing that, we're incurring hyper complexity. Now, a few years ago, if you looked at all the code base in the world, you would still find hypercomplex code bases, but they would only happen rarely. So you would have the likes of Google, right? They would have hypercomplex code bases, but it took them years to get to that level.

[00:14:06] They had time to adapt. They had time to build mechanisms and processes and tools to manage this complexity. You had Facebook, you have some big financial institutions, so it's not a new thing. What's new is that now everybody and their dog has a hypercomplex code base, and we're not Google, and we haven't had that much time. And the tools we're using are the same tools we were using for the previous reality. That's kind of the problem statement.

Before I continue, I'd like to ask: do you guys have any comments or feedback on this?

00:14:34 - Christopher Burns

Yeah. One of the hardest things I find about this is when you're a single developer, say you've worked in a company or you haven't, or you're at different stages, you tend to clutch to your previous experiences to say what to do next, how to set up a new project, how to go about it as a developer.

And it's the thing of when someone says to you, haven't you tried a monorepo? You go, why would I want a monorepo? They tell you everything. You go, okay, you go away, you implement it. It seems in that second I've made a good choice, a right choice. But how do you truly know you've made a right choice or a wrong choice?

And I've seen this with elephant. To a certain extent, we start bridging multiple projects quite easily. A WordPress plugin in PHP, API in Redwood, a website in Next. I made the mistake of putting it all in one monorepo, and I can say that, hand on my heart, it was a mistake.

[00:15:34] Why? Because Yarn workspaces just chained everything together, making npm modules incompatible between Next.js and PostCSS, and it just added so much more complexity. For what? What was the reason? I could just put my Git issues in one repository. Did that seem worth it? And then the second thing to that was the money you were spending on what?

For example, if you have three websites on Netlify or Vercel in one monorepo and you push an update to one of them, well, Vercel and Netlify are going to rebuild three websites because it's all in the same Git repository. When you stop and think, what was the reason for using a monorepo? I still don't think I could really say them in practice. Yeah, all my code's in one place, but does it need to be?

If you know what I'm saying, it's a really hard one. And obviously that is complexity at scale. You know, when we've had developers join us at the fund, it's been this thing of, okay, this tiny part of this pie is what you're working on.

[00:16:37] Just ignore everything else. And let's not even get started with Git submodules and all that kind of stuff. It goes on for days, doesn't it, as you're saying, complexities. And we're like, why are we making these complexities for ourselves? We're building a cage at the end of the day.

00:16:52 - Aldo Bucchi

You know, I hear you talking about this, and I see the struggle, like trying to find the local maximum, trying to think long term, sifting through all the new projects, trying to keep it all in your head. The liberating insight for me, which is really like an aha moment, was when I realized none of this matters. It's just more of the same.

You're describing your problem right now from your current perspective. Tomorrow, you're going to have another issue. And if I ask Anthony or I ask somebody else, they are all going to have their own little set of problems that they're trying to solve. But the underlying cause of all this is that there has been a complexity explosion, and we haven't acknowledged it from a systemic point of view. And this is not an abstract exercise. So actually there are solutions to this.

You know, you were talking about tools, and that's a great segue for the next part. So we talk about the problem, right?

[00:17:43] We're trying to agree on some terminology here. Let's just play this game for a while. So we have hyper complexity building up in our code bases because there are some trends that are driving this, and it's spreading like wildfire. So what are we doing about this now? What we're doing about this right now is that we are focusing on solving the symptoms.

We don't see complexity directly. We experience the side effects of complexity. Things start breaking down and they start breaking down in a million different ways, which is what makes it even harder. But if you start enumerating these ways, there are some that are very common. Build speeds are terrible. Dependency conflicts. The CI workflows are complicated. Pushing a release involves so many moving pieces. We have a list, a long list of things, and for the last two years or so, we've seen people complaining about these things in increasing numbers. And this has driven investment in this area. So you have tech-savvy VC funds that are looking into this and recognizing a pattern, like something's going on here.

[00:18:36] People are complaining a lot, and then you have startups that are managing to get huge initial traction just by focusing on each of these individual issues, right? So you have a whole new generation of projects that are promising to rewrite the toolchain to make it faster and so on, but they are just going after the individual side effects. Will this succeed? Is this a good thing? If all of these startups succeed, will we get out of the problem?

Unfortunately, I don't think so, because we know already that if you treat the symptoms of any disease and you just treat the symptoms, you don't really get out of the underlying problem. It gives you relief, a momentary kind of bliss. But eventually another symptom will appear. So in the long run, it's a losing game. It's a losing strategy. You need to focus on the underlying cause, and I don't think that anybody has framed it this way because it seems so confusing. But once you start looking at it from this perspective, then you can ask yourself another question.

[00:19:32] And the question is, how can we prevent complexity from building up in the first place? It's like cholesterol. You can go and get a bypass or some sort of surgery to clear your arteries, but it would be much better if you have prevented that from building up in the first place. That is the guiding question behind what we're doing: how can we prevent complexity from building up? Because if we prevent complexity from building up, all of these problems go away.

And here's a little mental exercise. If you don't believe me, if you get your code base and you throw away everything and you just keep like five lines of code, one build tool, one way of making tests, you don't need to worry about tooling anymore. It's unrealistic. If you do that, you're going to lose all your features. But the point is, if you shrink things to a manageable state, you don't need any of these other tools. These other tools are just patching the issue.

00:20:18 - Anthony Campolo

It's a really interesting idea, and I'd like to hone in on this for a second, because this is very similar to how I approached tutorials, in that when I want to create a tutorial for something, I want to create an end-to-end experience where you start from zero, build something from scratch, and then get to some sort of end state.

So the question is like that end state for me is usually a thing deployed to the internet that someone else can hit with a URL. You create an end-to-end experience of how do you create that? What are the steps involved with that? What steps with the CLI? What code do you write? What language is that in? And then you can get a self-contained experience of what is actually building a thing with this.

And then you can look at, okay, if I needed to extend this to XYZ use case, what would I need to add on? Are those things provided? Are they not? But it gives you a baseline to think about that that is, like you say, manageable and can be contained within a single article.

00:21:11 - Aldo Bucchi

Yeah, our job as developers, we are all monkeys. I'm a monkey, you're a monkey, and some of us have more time to focus on solving these issues, and others are just struggling with family and work and a lot of things. Our job as the monkeys with more time to build tools for the other monkeys is to try and make them simple, is to understand what you can throw away, what you can keep so that they don't have to invest valuable time.

Trying to figure that part out and making things simple is the hardest thing to do. Because in order to make something simple, you need to know everything about everything related to that. You need to know exactly what you can throw away because you know the consequences.

So this quest for simplicity is our mission. This is what we should do as tooling developers, as framework developers. It's a big responsibility because then you get millions of people that are using whatever you build. And if you were lazy in doing this and you were careless and you didn't squeeze as much simplicity as you could into this, you're going to cost them time, right?

[00:22:08] You're costing people time. It's like sending someone to jail in a way. It's like as a tooling developer, you can be responsible for thousands of hours of people just banging their head against the wall. It's like a lot of power.

I've been workshopping this into sort of a coherent story. I'll try to rush to the end so that you guys see how it all connects. So we're talking about the solutions right now. People are building tools, and we are kind of seeing this gold rush. My projection is that none of this is going to work. These companies are going to make money. But Herbalife made a lot of money. Vitamin supplement companies make money, but they don't necessarily solve the problem. They just prey on people's pain and confusion. I'm not saying they're evil, I'm just saying it's more of a temporary relief.

But there is a side effect to this that we need to be aware of. It's very easy to get stuck in a hamster wheel of trying new tools, evaluating them, getting some benefit from this.

[00:23:00] And then a week later you go through the same process. You get like these quick wins, small sprouts of happiness because, oh, my filters are so fast. Yeah. You commit, everybody applauds you. Then next week, the same. And this starts building a habit over time because there is this micro-reward kind of cycle. You start reinforcing this idea that searching for tools and rewriting and all that is actually a good thing, and it isn't. That is unnecessary work.

And I see that we are going headfirst into this, and you have the perverse incentive of tooling startups to try and sell you this idea. That's what they're counting on. Like, hey, have you tried my new build system? It does distributed caching. It's better than this one because of X. And you're like, oh yeah, that's going to save us, right? Next week you change the testing framework. It breaks because of course it can't cover everything, and you have to move again and so on. So I'd like to try and label that idea as well.

[00:23:50] For now, I'm settling on the notion of tooling addiction or tooling dependence because it has exactly the same structure as an addiction. It's funny when you look at how it takes over teams. They've become addicted to tooling, and now you can't really talk to them anymore because...

00:24:04 - Anthony Campolo

They just want that next fix. They need the next fix.

00:24:07 - Aldo Bucchi

Exactly, exactly. They're looking at Twitter. They're trying new things, but that's not going to work. So what is going to work? We've talked about the problem. We've talked about what doesn't work. So what does work? Well, the answer is not simple, but it exists. And we can try to understand what the general strategy is.

So we already know about a certain set of characteristics that are really good at fighting complexity. So we already know that, for example, encapsulation, layering, composability, high-level abstractions, leverage. These are things that if a programming language has many of them, these languages tend to be better at dealing with complexity, at scaling. They let you do more without hitting this exponential kind of runaway point where you just lose control of everything.

So the question then becomes, how can we take the technologies that we have now and use some of these basic principles, like retrofit these basic principles into the technologies that we use now, because we don't want to tell people that they have to change everything and learn a new programming language.

[00:25:07] That's not going to work. We need to do it with the technologies that we have right now. So we need to retrofit them and add more of these characteristics. And that's what I've been working on for the last two years, taking, in this case, TypeScript and JavaScript, and rethinking from a very fundamental level how we can retrofit these magical things that we've seen work in other places. This is not about discovering something totally new. It's about bringing things that we know work into the mainstream, into the tools that we use.

So because this approach is generic experimentation in a way, because we're taking genes from other species, right, and we are splicing them into JavaScript and TypeScript, that's where the name of the project came, the Lambdragon, which I think is pretty funny how it's all starting to make sense now, right? The Lambdragon is a little lamb with some dragon DNA, and it spits fire and it has wings. So it's a very good analogy to what we were trying to do for JavaScript and TypeScript.

[00:26:00] We're trying to make it spit fire so that you can kill complexity, and it actually works. We've managed to take huge monorepo code bases and slash the size without losing any features at all. Slash it in half just because we tweaked the language ever so slightly, so that now you can have a different kind of layout. We rebuilt all of the tools, the compiler, the IDE, the bundlers, and so on.

00:26:22 - Anthony Campolo

Just because I thought it was a lambda dragon, like a lambda function that became a dragon.

00:26:29 - Aldo Bucchi

It could be. So if you look at the logo, the letters are colored differently. So you can read Lambda. Those are darker or something. We're going to go there.

So what do we need to add to our languages? We need to make them more composable. Easy to layer them, easy to encapsulate things. So for example, we don't have visibility control in something like JavaScript. And we need that. You were talking right now about something like that. But all of these problems, you see, you can solve them at the language level. And then all of a sudden they vanish.

But on top of that, we also need to add more leverage. One of the best ways to prevent complexity is to avoid doing work in the first place, right? So if you have good abstractions that give you leverage, then you express things at the right level. You don't have to do all the mechanics. So the dragon is not just a new toolchain with its compiler, bundler, and so on and so forth.

[00:27:18] It's also a set of frameworks that let you build products for different platforms. So it's about building everything all together. It's very ambitious, and it's basically a platform where the experience is TypeScript and JavaScript, but it's a fundamentally different thing. You've seen some of the demos or the prototypes, right? There's a lot of crazy stuff there too.

00:27:40 - Anthony Campolo

I've seen some of the demos. Chris has not.

00:27:42 - Christopher Burns

I've seen nothing.

00:27:43 - Anthony Campolo

Aldo has already shown me some of this stuff, but Chris has not seen any of it. So I feel like Chris probably has some level-setting questions right now.

00:27:50 - Christopher Burns

I do. There's something I've always wondered about for some time, and I feel like this fits into it: why do we need to worry about file system routing or page routing? I wish we could just encapsulate things into folders that could just be interchangeable, kind of like mini npm repositories. Just be like, okay, this service has an API, a page view, and an underlying function. These are the four npm modules that it uses. And this is this version. And then you could just glob all of these little sections into one app at the end, and it does it all automatically.

I feel like this thing has never existed to a certain extent, as in, why do we have these massive apps that do all these things when really each one is a service that does one thing, and then why can't we just have a skeleton that just pulls it all together? I feel like big companies like Facebook and Google definitely do that, but tiny companies definitely don't.

00:28:50 - Aldo Bucchi

Yeah. Do you remember Portlets and Portals back in the Java days? It was kind of the same idea. It's a unit of functionality, and then you just aggregate all of them together into like the Chrome.

But you're touching something interesting there. On a more abstract level, what you're saying is, I feel constrained by this abstraction or this convention or this way of doing things, and I wonder if there's probably a better way. That kind of thinking like, oh, maybe there's a different way of approaching this. I don't like it. That's common. It happens to us all the time.

Now, there are two ways to solve that problem. One is to actually come up with alternatives and say, okay, you have file-based routing, and then you have this new portal thing, and you can go and build it, and you can create some protocol and standardize it. And it's going to be a lot of work, but you can do it. And then maybe you find something, you end up creating a huge startup.

[00:29:40] And then you bring me in and you give me a lot of stock and we're all happy. But there's another way of approaching this where you say, wait, I have this idea. Now I'm going to have a different idea tomorrow, and then what can I do so that I am not constrained and I can just do whatever I think I have to do in the moment? That might sound like a trick question, but it's actually a very simple thing to answer.

What you can do is make use of programming languages. A programming language, like JavaScript, is a general thing. It allows you to do whatever you want. But when you have a problem that wasn't considered at the time of designing the language, what you have to do is you need to add scaffolding around the language, and now you're restrained by that scaffolding. But if you eliminate the scaffolding and you just use the language, you can actually do everything you want. That is part of what we have been trying to do.

[00:30:32] And you've seen this, like the build tool, the way you express what you want to build, the way you change things together, is making use of the programming language itself. Everything is code.

00:30:42 - Anthony Campolo

This is really worth honing in on. And I've been talking about infrastructure as code going back to like episode nine. I kind of laid out this whole vision, why I thought this was so important and why I've been so excited about what you've been working on, because a programming language, by definition, can do everything every other programming language can do. That's what makes something a programming language. If it's Turing complete, it can compute anything any other programming language can compute.

So if we just accept that we're working with programming languages and we lean into that, we can create any abstraction we could possibly think of within the bounds of that programming language. And so you're creating abstractions on top of JavaScript and TypeScript. And so that's kind of what you've decided is like your programming language of choice, right?

00:31:26 - Aldo Bucchi

Yeah. For our project. So the Lambda is a new type of TypeScript toolchain that kills complexity with fire. That's the tagline, but it is TypeScript. Personally, I don't really like JavaScript. I kind of hate it a little bit.

00:31:39 - Anthony Campolo

You like Scala, right? Scala is your programming language of choice.

00:31:43 - Aldo Bucchi

Honestly, I don't really care in that sense. I jump from one thing to the next. The one I'm using now mostly is Rust, these days. I started just porting everything to Rust, and I think they hit a pretty sweet spot. Rust is a good example. It's a good source of inspiration because Rust has a few things that we need to emulate if we want to solve the problem for the JavaScript community. The first one is that the core team took care of many of the issues at once.

So Rust has testing built in. It has macros built in. It has great dependency management, built in almost right. But it's very cohesive. And then on top of that, you have documentation. And the way you publish things is all streamlined. All of those things, they add up to eliminating complexity. So the complexity in a Rust code base doesn't grow as fast as it does in a JS monorepo code base.

And you can have in one project multiple different binaries, and you can publish different targets, and you can have this idea of different configurations for building.

[00:32:42] You can have multiple dimensions and products being generated from the same code base. And when you are in that code base, you're free to think about code and not the boundaries around you. I think Rust is also giving me a reference point, because many of the things that we've added to Lambdragon, I can say, oh well, look at how Rust is doing it. So kind of validation, I like it.

And Scala 3 is great. But the thing with Scala 3 is it doesn't push the limits like Rust does. So Rust is actually giving you something new, something pretty powerful. Scala 3 is still potentially going to be game changing because of the metaprogramming, but I haven't seen that yet. We haven't seen the result of the libraries that people have built with the metaprogramming facilities in Scala 3.

And the other cool thing with Scala, I mean, the whole Java ecosystem is Graal. Graal is going to generate some crazy innovation, right? I think people are trying to get their head around the possibilities.

00:33:39 - Anthony Campolo

No, none of our listeners, I think, will really know what GraalVM is, but I actually do because I've listened to many podcasts about GraalVM. It is quite interesting. It's a new VM, essentially, is what I've gotten out of it.

00:33:53 - Aldo Bucchi

It's a new JVM, which is faster, but that doesn't really matter. That's not revolutionary, but it's also a polyglot runtime engine. What that means is you can write code in multiple languages, and they're going to run in the same runtime, which means that the objects, for example, are shared between your Ruby and your JavaScript and your Java. So there's no overhead there, and it's a little rough around the edges when it comes to developer experience and tooling, but that's just a matter of time.

The core part, the hardest part, is there. It actually does work. It's very performant. It also gives you a lot of possibilities when it comes to instrumentation, which is very interesting for me as a tooling developer, the kind of things you can do, like coverage. And, you know, Lambdragon has Quokka inside. What do you call it, live? I don't even know if I call it a sandbox or a playground. What is the category for those things like Quokka and Wallaby?

00:34:43 - Anthony Campolo

There is no good term for them because it's not a large enough category, I think, to have a term. When you think of playground and sandbox, it gets across the idea, but those terms are also used for many other things. So it's like anytime you want to just define something that's like.

00:34:58 - Aldo Bucchi

Interactive, as in interactive development or something.

00:35:01 - Anthony Campolo

Yeah. Interactive something.

00:35:03 - Christopher Burns

I did want to quickly bring up Rust recently. 1Password is really stirring up all the conversations around Apple and Mac apps. The reason why is 1Password is dumping their native apps and going Electron on all platforms, with the core written in Rust. So the cores were written in Rust and the Electron wrappers were written in TypeScript. There's so much to that story. They've said that they've been using Rust in production now as the core of their apps on Linux and Windows, and now they're obviously transferring over. What other real-world cases have you seen for Rust so far? Any big companies that you know that are using it with success, why they use it?

00:35:51 - Aldo Bucchi

Well, I'm not an expert in that area, but I know that Cloudflare has a bunch of Rustaceans. You have Mozilla, which created the language. So Firefox, for the most part, the CSS engine, I know for sure, and I assume more parts are built in Rust. But it wouldn't surprise me if everything ends up moving to Rust, because it gives you something that no other language can give you, which is there's no memory management. It gets compiled away, and that is a huge selling factor.

And then if you combine that with all this cohesiveness that I was talking about, like the fact that they figured out so much and the core team has been so responsible in the way that they evolved all of these tools together, it's a pretty powerful competitor right now. And I know that Wasm allows you to do this kind of combination where you keep your web app or your Electron app, but the core is written in Rust. I think we're going to see more and more and more of these cases.

[00:36:41] I've seen a bunch of talks of people talking just about that, like, hey, we had this drawing app and then we replaced this part with Rust. Compile it down to Wasm and now it's faster. So there's a lot of movement there, but it's not a language for everyone.

That's another important thing. I think JavaScript and TypeScript are going to be the king of languages in terms of adoption. They already are, right? And it will just continue growing. They're easy to learn.

00:37:03 - Anthony Campolo

I've messed around with Rust myself, because I've been very interested in a wide range of Rust-related projects over the years. It seems like the benefits it gives you to write real, serious programs is just massive, but there is more of a barrier to entry than just spinning up a really simple JavaScript thing in your browser console.

So I agree with you there. There's always kind of going to be this separation, I think, between people who want programming and then people who want to go that next level to get the whole benefit they can get from a programming language. And that's where Rust comes in. But it's always going to be kind of like a step beyond.

00:37:40 - Aldo Bucchi

Yeah. So Rust forces you to do more work because you have to take care of something that, in the case of JavaScript, is transparent to you. Memory management. You never think about it. In JavaScript, you create an object and you pass it around and that's it. In Rust, you have this whole dimension of lifetimes and borrowing and things that you need to keep in your mind. That is a significant overhead. It's a real overhead. It's not just, get over the style and you'll move fast. No, because you have to do more work. But it's worth it, especially for tooling and for things that need to be fast.

And we're seeing this trend where everything is being rewritten in a language that compiles to native. So it started with Esbuild, I think kind of triggered it in the JS world. But now there are a whole bunch of projects moving there. It's kind of interesting because you have Rome raising money, having built everything in TypeScript, and now they have to rebuild it in Rust.

[00:38:27] I think it's funny. I don't mean to talk down any of these projects because they are actually incredibly hard to do, and the teams are super talented and all that, but I can use them as a reference point to say what I think they're doing wrong, or why I think they're not going to get us out of this problem, right?

So if you look at what Rome is doing, they are actually doing something valuable. If they succeed, they will give you this unified toolchain that has everything and everything works cohesively. So it's like what Rust did for Rust, which is great, but it doesn't really tackle the problem of complexity. It can diminish it a little bit.

But if you really want to fix the problem of hyper complexity, let's say that a project today has ten times more complexity than a project a few years ago, or 100 times more because it's exponential. You need to then slash complexity by a factor of ten. You need to do something extreme. If you want people to continue to use full stack and serverless and all these things, you need to give them a way to collapse this. Rewriting the toolchain so that the same work you use today works slightly better and faster just doesn't do that for you.

[00:39:26] And then you have a whole other set of startups that are working on build tooling. They're going back, looking at Bazel and all of its offspring, all of the lineage of Bazel-like tools, right, that do build automation and distributed caching of builds and speed your builds basically.

00:39:42 - Anthony Campolo

And does NX fall into that category of tools?

00:39:45 - Aldo Bucchi

Absolutely. And this is, I would say, like the incumbent there. They have great penetration in the market. They've been around for a long time. There's a lot of knowledge around NX. It's a community. You can go and watch videos and you feel like they're holding your hand, and they are at the center, I would say.

But around now you see a lot of other companies saying, but we're doing it better. We're going to put it together and it's going to be fast and we're going to cache and blah, blah, blah.

00:40:07 - Anthony Campolo

This is good because I like to actually get into, like, how can someone now get involved with what you're doing, Lambdragon? Like, how can they see it? How can they try it? How can they? How do we engage with this today?

00:40:18 - Aldo Bucchi

Go to the home page. We are currently doing a private beta. We've been working on real projects for a while. So, you know, I've been using this to build the Redwood extension and a few other things. So I've been working on real projects with this tool. We are now letting some users use the tool for their own code bases. So we have a little group, like a beta, but it's very controlled because I actually want to be able to talk to people, but we are slowly expanding this.

So by the time this comes out, there's going to be a form on the home page where you can go and request a demo, and then we will talk. So just so you can filter yourself out and not waste your own time, this tool is going to be focused mostly on highly complex code bases. If you're using NX right now, if you're looking into using, I don't know, Turborepo or something like that, this is an alternative to that, where instead of you keeping this idea of the monorepo and keeping the complexity and just adding something to manage it on top, you can actually start eliminating this complexity.

[00:41:12] And I think at the end, this is a much more powerful option because it just makes everything faster. It's not just about build speed. Build speed shouldn't even be a thing. If you have a small code base and it's lean and the tooling doesn't even have to be great, it's just okay. You won't be thinking about build speed ever. It's not a thing. You think about it because you have a very complex setup, and you have builds that depend on each other, and you have a lot of code that shouldn't even be there. And then you have three different transpilation processes here and there. So complexity is what is creating this for you, right?

So the dragon is an alternative to patching things up. And it's starting to be pretty fast. The Rust version is as fast as Esbuild. We're still fighting with some bugs in SWC that are very hard to manage.

00:41:54 - Anthony Campolo

I actually just tweeted about this yesterday. Peter tried to port Redwood from Babel to SWC, and here's the one liner for you: roughly 40 to 50% of all Redwood tests failed.

00:42:09 - Aldo Bucchi

There you go.

00:42:10 - Anthony Campolo

Roughly half of all tests failed with SWC.

00:42:13 - Aldo Bucchi

Remember I told you 40% of my tests were failing?

00:42:16 - Anthony Campolo

Yeah. You are the canary in the coal mine. You told me this a month ago. You're like, SWC is broken.

00:42:21 - Aldo Bucchi

Yeah, it is. And I'm surprised that they are using it in Deno. It's a safe alternative to Node, but then the transpilation step can produce code that is not what you meant it to be. It's kind of crazy. But now there, I think Vercel is sponsoring or hired a developer, right?

00:42:39 - Anthony Campolo

So they hired the lead maintainer of SWC. So I imagine it's going to get a lot more funding, a lot more people working on it. And so it will be hopefully a rising tide that lifts all boats there. And having a use case like Redwood to me is like, I've called this technical chicken, where you have a large project and a large project trying to integrate, and then you see where everything breaks and it forces each of them to actually figure it out and make it work. So it's just a matter of time, you know, hopefully they'll work it out.

00:43:08 - Aldo Bucchi

Yeah, it's a huge undertaking. Anyway, interesting codebase. It's like a Frankenstein.

00:43:13 - Christopher Burns

I'm super excited to know more about Lambdragon, because I've heard nothing about it so far, and I kind of want to see some documentation, to be fair.

00:43:21 - Anthony Campolo

There's a bunch of Lambdragon URLs that are actually live. You just have to actually know what they are.

00:43:26 - Christopher Burns

It was like that with Astro. It's like there's a beta, but if you know the URLs, you can just look at it.

00:43:32 - Aldo Bucchi

Astro is cool. I like that it is very bold. Instead of going from the single-page app and slowly crawling towards static generation, it's like, let's flip it around. Let's build a framework where static generation is the thing, and then the exception is some things can be dynamic. And I think that's a very good mindset.

So in Dragon, we have built-in frameworks. So the thing is that Dragon is going to include or absorb many of the different things that you're doing now. So it also has its own frameworks. You don't have to use them, but they're there. We have a web framework, like a single-page app web framework. It's kind of easy. It's just React.

But with Astro, I could finally see a direction for an alternative web framework, one that is going to be focused on massive, statically generated sites, and it integrates with everything else. So Dragon also has infrastructure, databases, and so on. It's like the whole thing. It's a lot of work.

[00:44:25] It's taking two years to even scope it out, you know?

00:44:28 - Anthony Campolo

Yeah. No, this stuff doesn't come out of nowhere. And for any FSJam superfans who may have heard, I've referenced you multiple times throughout the course of this show, going all the way back to episode two with David Price. We were talking about the Redwood extension, and then we had Monica Powell on, and you worked with her a lot on the Redwood internals package. And so you have been kind of a background character in so many interesting things that have been going on with these frameworks.

So I usually think about this show as like a two-way street. There's me getting to reach out to people who are doing interesting things that are already public and talk to them. And then the reverse is people who haven't really gone out much and talked about these things and hopefully present to the world. So I think what you're working on is so interesting, and it's going to be really great to get more people involved in looking at it and seeing what's going on here.

[00:45:20] So do you have like a single home page that people can go to for Lambdragon?

00:45:26 - Aldo Bucchi

Lambdragon. Lambda.

00:45:28 - Anthony Campolo

Lambda.com. That's a good place to be.

00:45:31 - Aldo Bucchi

We're also working on hyper complexity. That's going to be fun. This idea of hyper complexity, I coined the term. Hyper complexity exists as a mathematical term, but as applied to technology, I was looking for a term that could describe what was going on, and I arrived at that one. It had this magical effect that once I started using it, people immediately get what I'm trying to say. Even you, Burnsy, you embraced it immediately, right? Now you were saying, yeah, the complexity is killing me.

Once you hear it, you're like, yeah, that's happening to me because it's happening to us. Not just in tech. Like our lives have become so complex that they're hard to manage. How many emails do you have that you haven't even gotten your head around? Like I am overwhelmed. I'm done with it. I think it might become some sort of, I wouldn't say movement, but some idea that we can work on and help guide if you want people in the industry to work on solutions.

[00:46:20] Ideally, we should understand what the problem is first. And I think all of these startups, they're getting funding, they're pulling in talent, but they're focused on an inconsequential symptom of something. It's a waste of time. Like, why would you even rebuild a compiler for the nth time? Why would you build a build tool? You have Bazel, you have Pants, you have three, four different things happening already. You have NX, and now you have a sixth and an eighth and ninth one. And they're getting funding and they're getting buzz. And you know why they're getting funding and buzz and all that. Because they're talking about a problem that people have.

00:46:53 - Anthony Campolo

Because it resonates with everyone. But no one can quite figure out what is the solution. So hopefully you have the solution.

00:47:01 - Aldo Bucchi

I mean, if you say, are your builds slow, people are like, yeah, they're so slow. Okay, I'll speed them up. Thank you. But that's not the issue. Why are they so slow in the first place? Right. I hope that we can kind of change the focus into what we should really do.

00:47:14 - Christopher Burns

Sometimes decisions are not truly known until you've experienced the problems from them. A really good example, and I hate to be the one that brings up, is Babel. You add a Babel plugin or you add two, or you add three, and then you start increasing the size of your code base, and the transpilation times increase and increase and increase. So if you're using something like Emotion, styled-components, you really don't notice how much transpilation is adding until it's too late. And you're like, why is my app taking like five minutes to just get going?

And then you realize, oh, you know, all these compiled styles are really slowing it down. You don't think about these things when you think, oh, I want CSS in JS. You don't think, how is this going to be performing when I have 500 files with this in? And then you're at the point of do you go, hey, how do I actually fix this and speed it back up? Or what can I convert it to, back to the old PostCSS?

[00:48:14] And that's just one example that even I've seen where a decision that looked like it ticked all the right boxes when the decision was made, only to have it implemented into a bigger scale and see that, no. While yes, it ticked all the boxes as yes, it allowed me to have CSS in JS, blah, but actually the developer experience was degraded so much.

00:48:40 - Aldo Bucchi

It is hard to escape that. So in this particular case, what the solution would look like is, for the general case, for the common scenarios, we consider those in the core language. We need to improve the core languages, the way modules work, the way our build tools work, all these things. We improve them so that everything that falls in the common category of things doesn't add complexity at all. It's covered.

Okay, that's step one. And that might sound abstract, but it's actually going through a list of things that people do often and making sure that the languages accommodate those. And then you have the extraordinary cases, like I want to use some preprocessor or a specific plugin. So for those cases, if they don't fit in the general mold, then what you have to include in the language is a way to isolate things. It's a way to allow you to draw a boundary around the thing that is strange or different, and then provide a mechanism so that it fits into the bigger picture.

[00:49:36] I know this is abstract, but these are things that we know how to do. Programming language design has been evolving and understanding the benefits and strategies for modularization, for encapsulation, for composability. We also have a whole toolbox of techniques that we haven't used in the JS world, like metaprogramming, not just Preval or macros, but something that is also tightly integrated with the bundlers, with the IDE.

And I showed Anthony like we have macros.

00:50:06 - Anthony Campolo

This is actually great because macros as a concept don't really exist in JavaScript, and if you're into things like Lisp or these other languages where it's a key feature, you're very aware of that. But you were showing me macros, and I'm like, almost no one I know who does JavaScript stuff, macros aren't even a concept they're aware of.

00:50:27 - Aldo Bucchi

Yeah. The thing is that if you want to use macros, you will very quickly end up having to understand ASTs and compilers and a whole bunch of things. So it's like pulling a thread and you just get this huge mountain that falls on you. But you can have some simple macros for simple cases where if you just want to get a list of files in a folder, or if you want to preprocess something, you shouldn't need to touch an AST or even deal with that.

So we've put a lot of work into figuring out how to add some metaprogramming facilities to JavaScript that don't break anything else. So that's the nice thing about building the whole story, like everything from the compilers all the way to the frameworks, is that you get to see how your decisions affect every level.

And I think it's the only way, because if we don't do that, then we're not pushing things forward. We're just one more little isolated innovation that then you need to piece together with something else, and that will only contribute to the problem.

00:51:19 - Anthony Campolo

Cool. Well, thank you so much for being here on the podcast. When I created this show in the first place, you were one of a small number of people that I created it to get on. So I'm very happy to finally get you onto the show to talk about all these things. I think this is a really interesting episode.

00:51:37 - Aldo Bucchi

Thank you, Anthony.

00:51:38 - Christopher Burns

One year late, but it's definitely been worth it. You've been in secret mode, is that what VCs call it these days?

00:51:45 - Anthony Campolo

Stealth mode is what they call that, secret mode.

00:51:48 - Christopher Burns

Stealth mode. I'm not on the VC brags talk. I'm not in the know. But yeah, it's been really great to have you on.

00:51:56 - Aldo Bucchi

I apologize for the long silence, but I hope now it makes sense. I really didn't want to talk about these things before I had a story that didn't contribute to the confusion.

00:52:07 - Anthony Campolo

You didn't want to put vaporware out to the world, and that's awesome.

00:52:10 - Aldo Bucchi

I despise vaporware with all my heart. I see how greed operates and the different incentives that we have in this current JS, VC-driven world or whatever. It drives me really mad in the end. Who's going to pay the price for all this confusion? It's the developers that have no control, right? So as a developer, I feel very responsible because I know that if I succeed, people are going to use my stuff and I'll have a great influence in their lives.

If you ever create a program like that, I've seen some YouTube channels where they just roast pitch decks or things like that. They just laugh at them, and we should do that with startups in the JS world and projects. Not in a mean way, but just to give people perspective because there's no opposing force. There's this new shiny thing. Everybody's tweeting, everybody's talking about it, and the people that can see the problems with it, they don't have the energy or they are not going to go and try and reach you to tell you.

00:53:03 - Anthony Campolo

You want to show that the emperor has no clothes. That's what you want to do.

00:53:07 - Aldo Bucchi

Nobody wants to do that. But I think we need to start. The JS world is out of control, if you ask me, in that sense.

00:53:13 - Anthony Campolo

That's a good note to end on.

00:53:15 - Aldo Bucchi

It's all your fault, Anthony. It's all your fault.

00:53:20 - Anthony Campolo

I mean, when I look at the JS world, I can't imagine how anyone could not resonate with the things you're talking about. So thank you so much for laying out this whole case and then attempting to build something to actually address it. I think it's really exciting, and I hope that lots of people will check out Lambdragon.

00:53:36 - Aldo Bucchi

Thank you, Anthony. Hey, man. See you around.

[00:54:08] - [unclear interjection]