Valentino_Stoll:
Hey there folks, welcome back to another episode of the Ruby Rogues podcast. I'm your host today, Valentino Stoll, and we're joined by our co-host, Luke Stutters.
Luke_Stutters:
Hello.
Valentino_Stoll:
And we have a special guest today, Adam Gordon Bell. Adam, why don't you introduce yourself and tell us a little bit about why you're joining us.
Adam Gordon_Bell:
Yeah, thanks for having me. I'm super excited to be here for a second time. I must have done something right the first time, I guess. Um, yeah, so I'm Adam. I, uh, I also have a podcast and I work for this company called Earthly that makes an open source build tool. I think I'm here to talk about some of the writing I've done in the past about, about programming, uh, languages and software development. Yeah.
Valentino_Stoll:
Yeah, you know that we discovered kind of two articles that you came out with recently, the slow march of progress in program language tooling, which is incredible. It's a hot topic in the Ruby community, getting our tooling up to speed kind of with some of the other languages that are out there. And another article that you wrote on the other kind software engineer, which is
Adam Gordon_Bell:
Yeah.
Valentino_Stoll:
kind of an amusing title, but I think is a great breakdown on what it means to be a staff software engineer and how that kind of differentiates from a, as you put it, a line software engineer. And we could dig more into that. I'd like to focus for now on the language tooling because it's a super interesting topic. kind of give a quick like high level, what are we talking about when we are talking about, you know, language tooling, and what
Adam Gordon_Bell:
Yeah.
Valentino_Stoll:
are some of the items that you maybe focus on.
Adam Gordon_Bell:
Yeah. So, you know, the, the stock overflow does a survey every year of what tools people use and whether they like them or not. And one of them is they ask what programming languages you use, uh, regularly and then whether you want to continue using it. And then they kind of piece this apart into what they call like loved languages and dreaded languages. So. If you use it, you know, every day and you don't want to continue using it, it's dreaded. And if you use it every day and want to continue using it, then it's loved. And the list, you know, kind of changes over time, year by year. But I guess the big thing that you would notice looking at it is that newer languages tend to be loved and older languages, uh, tend to be dreaded. And Ruby at some point was like one of the new loved ones and has drifted into the dreaded category. So I started thinking about this issue and started asking people some questions about what they liked about languages. And a lot of it was just the tools, not the syntax of the language, not the way you could do things concisely here or the way that this language looked versus that language. A lot of it was just tooling. Right. And so if you, if you think about an older language like C plus plus, which has been in the dreaded list on Sackoverville for a long time, it doesn't have a lot of the built in niceties of, of newer languages. There's no like equivalent of Ruby gems or actually there's like eight equivalent of Ruby gems, which is like actually worse than, than just having one. And like, nobody can agree you know, like standard way to put documents, documentation in your code. There's a more limited standard library than some things some people might be used to. So the article is about this. It's about how newer languages get to kind of take a fresh crack at what the tooling around a language looks like, which is much easier than bolting it on after the fact. That's what you got out of it as well.
Valentino_Stoll:
Yeah, I totally got that out of it. And one of the biggest things that jumped out to me to kind of put this in perspective was Go's auto formatter,
Adam Gordon_Bell:
Yeah.
Valentino_Stoll:
which there's kind of like the Ruby auto formatter that you can use that kind of goes along with RuboCop, right, to auto format code based on styling rules. I would love to see that. But if you've never worked in Go before, that is definitely something where, you know, your code is just magically formatted right to work. And when you get it at that level, it's, you know, you make a lot less typos. Because
Adam Gordon_Bell:
Yeah.
Valentino_Stoll:
you get that instant feedback, right, where it's like, oh, it's not formatting, right? Like something must be wrong, right?
Adam Gordon_Bell:
Yeah. And because like Go format was put out along with the language and it has like no knobs that you can turn. It's just like, this is how you format the code. Like there, nobody, it's not a discussion point, right? Like I, I assume the, the Ruby formatter I haven't used it has a lot of knobs that you can tweak and not everybody agrees with all the standards. And it's hard to add something like, like Go format retroactively, right? that there's all these code bases that exist and don't conform to it. So like nobody, no programming language that existed before Go format will get the like 99.99% code format compliance that the Go now has with all their open source code.
Valentino_Stoll:
Yeah, yeah, for sure. I'm trying to think of, I'm not really sure what Ruby's, targets are as far as their tooling goes, what's missing. What's something that jumps out at you as far as what could we do better as, the Ruby community to make some of this tooling better? I mean, package management is definitely one thing, I think resolving, with Bundler historically has been problematic, which has gotten a lot better over time. But what are some thorns in your side?
Adam Gordon_Bell:
Yeah, I mean, I got to be honest, I don't write a ton of Ruby day to day. So it's, but like, you know, you mentioned, um, like code linting, right. And if you, if you look at, at go or rust, like they have the linters built right in, you know, to the, to the tool, you use cargo to compile your code, but it can also provide linting options. Um, not to say there's anything wrong with having a tool that comes off the shelf. Uh, sorry, not to say there's nothing wrong with having a third party tool that to grab and download and configure, but it's so much easier for a new person when from day one, like the linting is, is built right in, you know, to the package manager or to the compiler. Um, and, and has same defaults that you can agree with. So I would look at taking a lot of the tools that people use, um, to the side and finding a way to kind of roll them all into, you know, into the tooling around the language. It's weird. I find that I feel like there's not good names for this, right? Like Cargo in Rust, you know, like it'll run your unit tests. It'll do linting. It'll suggest things. It'll do code formatting. Um, you know, it has fuzzing capabilities or whatever, right? So what is that? Is it a package manager? I don't know. It's kind of like all of the little things that you want to do with your language rolled into one and a lot of other languages, these are, these are secondary things.
Valentino_Stoll:
Yeah, I'm trying
Luke_Stutters:
I have
Valentino_Stoll:
to think of all the ones. Go ahead, Luke.
Luke_Stutters:
I have worked with a very disgruntled Ruby developer who moved to JavaScript. And one of the things he cited about why he liked moving to JavaScript so much was that he could add an automatic code formatter and mentor to his Git pre-hooks. The reason why this caused him so much joy is that he used to continually fight with his fellow Ruby developers code
Adam Gordon_Bell:
Yeah.
Luke_Stutters:
on commits and I will say that it's not just the fact that you can reformat the code, it's the fact that there is now an agreed way of formatting the code. So it's not so much that the tool exists, it's that you no longer have to fight your colleagues about it.
Adam Gordon_Bell:
Yeah, it makes a huge difference on like PR reviews and stuff. And like in the article, I talked about Python. And I included like an XKCD comic where like, you know, you have like, pip install, and then you have like, py environment and the conda and like all these different tools just to get the right dependencies in place. Like that's another example, like code formatting where, you know, when something straightens that out, like, why do I have to to tell things what version of Ruby to use all the time. Like these are all little paper cuts, I guess. Like I guess the sum of the article is like all these little paper cuts add up to make people kind of not like the onboarding process. Oh, I cannot hear you, Valentino.
Valentino_Stoll:
I'll say the first time I worked with Go, the setup was painful.
Adam Gordon_Bell:
Ah, there
Valentino_Stoll:
And,
Adam Gordon_Bell:
you go.
Valentino_Stoll:
and mostly it was, you know, the specific directories that everything has to be in as a language, right? And even where you're working from within, like has to be kind of like bundled with the language, right? Like,
Adam Gordon_Bell:
Yeah.
Valentino_Stoll:
that was hard to wrap my head around that, like to get it to work, right? Cause I wanted to work where I wanted to work.
Adam Gordon_Bell:
Yeah.
Valentino_Stoll:
just like no.
Adam Gordon_Bell:
Yeah, with like the go path, they
Valentino_Stoll:
Right.
Adam Gordon_Bell:
like they have changed that now.
Valentino_Stoll:
Okay.
Adam Gordon_Bell:
Um, yeah.
Valentino_Stoll:
So I mean, there's an example though, right of, you know, making the tooling better.
Adam Gordon_Bell:
Yeah.
Valentino_Stoll:
But
Adam Gordon_Bell:
I could see like Ruby gems, somebody in one of the comments mentioned like Ruby gems, you know, in terms of the length of the existence of Ruby, it was added fairly late in the game, but that, you know, great addition, right? Makes it like it wouldn't be the same language without it.
Valentino_Stoll:
And I mean the same with Bundler. I remember the days of rails and you inlined all of your gems
Adam Gordon_Bell:
Yeah.
Valentino_Stoll:
in the configuration files. And there's kind of hope that it worked. Yeah, there was no pulling from a central dependency resolver. Right?
Adam Gordon_Bell:
Yeah, maybe that's what the person was talking about. Sorry, I can't keep everything straight in my head here.
Valentino_Stoll:
It's hard to keep track, right? Like it's kind of funny to think about now. Like if I were to restart Ruby, I feel like I would have an easier time onboarding, I would
Adam Gordon_Bell:
Yeah.
Valentino_Stoll:
like to think, right? Cause there have been so many improvements kind of to these things where, okay, like I can just run Ruby right away. There's Ruby build, which is a great tool to just install Ruby right away, no matter what platform you're on. And it's great. It works every single time. And, you know, I struggled so many times to install Ruby. Like when Ruby version managers like started becoming a thing, like that was a new challenge, right? I feel
Adam Gordon_Bell:
Yeah.
Valentino_Stoll:
like, you know, and I feel like every language goes through these pains, right? Like you'd think that there would be a defined path. Okay, like if you want to make a new language, like, you know, these are things that you got to like make sure you have an order, right? Instead of kind of like, all right, language, like, we'll figure it out as we go, I guess, right?
Adam Gordon_Bell:
Well, I think like a lot of it is things get added on later. Like there's innovations, right? Like, yeah, like a code formatter wasn't a thing that people worried about when, when Ruby came out. And like when C plus plus, uh, was, you know, in its early days, there was no such thing as like, uh, you know, a third party package manager that you needed to have integrated and it's just, it's hard to add these things after the fact, cause things work, you know, you work in this environment and you just understand like, okay, this is how you do things. Uh, so like the standards always moving, I guess is what I'm saying, but, but I'm interested to hear like, what do you think, um, is, is the tooling holes that are the areas that should be polished in Ruby?
Valentino_Stoll:
That's a good question. I mean, getting Ruby on Windows is still a bit of a challenge. I know it's kind
Luke_Stutters:
Oh
Valentino_Stoll:
of
Luke_Stutters:
yeah.
Valentino_Stoll:
just been like, it's still, it's been a constant battle, I feel like
Luke_Stutters:
Yep.
Valentino_Stoll:
over the years. And it's definitely a barrier to entry for people just starting out, right? Like maybe they just wanna get a Chromebook and try and run Ruby. Or Chrome is a bad example, but you know, of a Chromebook, you know, just something, a cheap machine that you just want to try starting on. And it's hard to do that, which I'm hopeful that kind of this WebAssembly stuff can fix a lot of that problems starting out, right? Where you could just visit this webpage. And I think that's how tryruby.org works now, where
Adam Gordon_Bell:
Oh,
Valentino_Stoll:
you
Adam Gordon_Bell:
what?
Valentino_Stoll:
can, you can just go to the browser and try to play with Ruby just in the browser, which is pretty cool. But, you know, it's limited to dependencies. You can't just install gems, right?
Adam Gordon_Bell:
Yeah.
Valentino_Stoll:
So I feel like that multi-platform issue will continue. I'm trying to think.
Luke_Stutters:
They should just put the whole of active support into Ruby Core.
Adam Gordon_Bell:
I feel like it's like whenever somebody's learned, like if you get a chance to try to teach somebody, you should write down all the things they struggle with because you become blind to them, right?
Valentino_Stoll:
Yeah.
Adam Gordon_Bell:
Like you miss them.
Valentino_Stoll:
I know that the documentation is a common one that comes up, right? Like, because there are so many different documentation websites for Ruby that it's hard to follow, like which one is the official one. And then there's the new, like, Ruby API site, which is like kind of like a fresher user interface for the documentation. That's pretty nice. heard that maybe that is going to be the official, you know, don't take my word for it. But it's that is still unusually a hard part of the language, right? Is like, you go and you Google search, and, you know, there may be three different sites listed on the first page of the Google results, right? And you don't know which one to pick.
Adam Gordon_Bell:
Yeah.
Valentino_Stoll:
And you just hope that, you know, the first one works. And a lot of times, you know, result will be an older version of the language that is that first pick, right? So I feel like discoverability for documentation is definitely a hard problem to solve specifically for Ruby. It seems that this time
Adam Gordon_Bell:
Yeah, that's the hard one too. But, but so key, right? Because you want people to be able to solve their own problems. Yeah. But yeah, I think
Valentino_Stoll:
Right?
Luke_Stutters:
one of the
Adam Gordon_Bell:
central.
Luke_Stutters:
things. One of the things you wrote about Adam in your article was the idea that if you have a standard documentation system, you can link that into an IDE. So when you kind of mouse over, then you can kind of just instantly see what all the parameters are to that method and what it does. And yeah, I hadn't really thought about that before, but that is an incredibly powerful tool when you're just starting to work on a code base.
Adam Gordon_Bell:
Yeah, like for discoverability for sure. And then yeah, like having a central website is useful too, where if you're like, you know, every package, you know, we're going to generate docs for it and throw it on this one website in a familiar format, um, that's also super helpful.
Valentino_Stoll:
I did see recently, I feel like it was Koichi that gave a link to displaying something like this in an editor where you could just hover over and it would show you the, you know, RubyR docs for whatever method or class that you're in. I feel like that's hopefully coming soon. There's a, I don't use VS code enough, but there's a lot of plugins out there that I think can give that.
Luke_Stutters:
Oh, I've got another thing to say about Ruby documentation too. All right, you got me started now. Here we go.
Adam Gordon_Bell:
Ha ha
Luke_Stutters:
So
Adam Gordon_Bell:
ha.
Luke_Stutters:
I'm using some like gem, okay? And I'm in the R doc. I'm like, okay, what's going on, right? Let's have a look, click on the R doc. And on the left-hand side of the page is an enormous list of classes, which I will never touch, which no one will ever touch. They're all just kind of total implementation. No one's ever gonna touch that stuff. But the whole left-hand side of the screen right? You know what I'm saying? Yeah? And you're looking at this kind of massive list of classes thinking, oh my word, I don't know what's going on here. Where do I start? You know, where's the entry point? Which of these am I actually going to use? So some way to kind of tag those up and say like, you're never going to do this, you know, hide all of these, put all these right at the bottom of a list, you know, you only want these four to use this library. That that would save me a lot of time.
Adam Gordon_Bell:
Yeah.
Luke_Stutters:
So some kind of meta tagging in documentation. Now, I'm not sure if I've seen it in another language. So this isn't, I don't know if that even really exists. The idea, you know, where you say, yeah, this is a kind of implementation. These are the ones you want when you're actually using this thing. I don't know if that exists in Go or anything else.
Adam Gordon_Bell:
But this is where innovation happens, right? Like if the Ruby community thinks hard about that, it does a really good job of it. Then, you know, people will be leaving Ruby and ending up somewhere else and being like, why isn't there a way to highlight, you know, what the main things in the docs are, right? And then it will spread.
Luke_Stutters:
I know you're supposed to look at the tests, alright? I know I'm supposed to look at the tests, but believe me, that doesn't always help.
Adam Gordon_Bell:
Yeah. of valentino i see your lips moving but i can't hear you Can you hear him, Luke?
Luke_Stutters:
No.
Adam Gordon_Bell:
I don't know, is it? Am I just not able to hear you guys?
Valentino_Stoll:
I'm sorry about that, I had a phone call come in from the kids daycare.
Luke_Stutters:
Oh no.
Adam Gordon_Bell:
Oh, that's okay. I thought I was missing something. That's fine.
Valentino_Stoll:
Ha ha. Uh, anyway. Uh...
Luke_Stutters:
Are they okay?
Valentino_Stoll:
Yeah, they're all right. We can edit this out, but my son brought in too much money to his trip today, and they were concerned that he had a lot of money with him. I don't know. I don't know where he even got it from so...
Luke_Stutters:
Oh
Valentino_Stoll:
Anyway.
Luke_Stutters:
man.
Adam Gordon_Bell:
I don't know.
Valentino_Stoll:
Um, where were we? Uh, programming tools.
Luke_Stutters:
I was proposing a system of a semantic documentation.
Adam Gordon_Bell:
Yeah, let's do it.
Valentino_Stoll:
Yeah, I would love that.
Adam Gordon_Bell:
I think anything that makes it easier for,
Valentino_Stoll:
I mean,
Adam Gordon_Bell:
you know.
Valentino_Stoll:
there's been so much work with the parser lately and the Ruby grammar. I feel like being able to pipe that into, you know, some new tool should be easier this day and age where it could just, you know, automatically pull from source locations kind of thing. I don't know. I feel like maybe there could be something there.
Adam Gordon_Bell:
Another big thing that came about that wasn't covered in the article, for those of us who use VS code like me, is the LSPs, like the Language Server Protocol. Is that what it stands for? I think.
Valentino_Stoll:
I think
Luke_Stutters:
I didn't
Valentino_Stoll:
so.
Luke_Stutters:
really understand what that was, the LSP. What is the LSP?
Adam Gordon_Bell:
So Microsoft came up with this idea for, I guess, solving the IDE problem. If you think of it, the text editor slash language problem is if you come up with a new programming language, you need to add support for it to like all these various editors that people use. So like, if you use a heavy IDE with like refactoring support, you know, that support needs to be built into that whatever, IntelliJ or Visual Studio or whatever. So it's kind of like an N times M problem, right? Like every Visual Studio needs to know how to do all these things for each language. So to kind of cut this knot in half, they came up with this language server protocol, which is basically a protocol where your compiler or can tell the editor about the code, right? Tell it like, you know, where the definition of this is and things like that. So that way, if you build a new editor, you just have to support the language server protocol. And if you build a new programming language, you just need to support the language server protocol, like on the emitting side. And then every language and every editor can work together.
Valentino_Stoll:
I feel like I saw something recently where somebody was doing inline Ruby evaluations. So you could see, you could just open up any Ruby file and you could see line by line what the code evaluated to kind of in a sidebar. And I thought
Adam Gordon_Bell:
That
Valentino_Stoll:
that
Adam Gordon_Bell:
is
Valentino_Stoll:
was
Adam Gordon_Bell:
cool.
Valentino_Stoll:
pretty neat. Because that instant feedback you can get anytime, that's kind of the power of the Ruby console, right? But it'd be nice to just like open a file and get that right.
Adam Gordon_Bell:
Yeah, I don't think LSP goes that far, but yeah, Shopify has built like a Ruby LSP that I assume there's probably a VS code plugin you can use with it to get some nice, you know, like go to definition type features. But because Ruby came after the LSP concept, right? It's not like built into the compiler where in some newer language, they might just like, you might just ship with LSP. all the like parsing of Ruby and send this through. It's like some things are just harder to add after, right? It's like when you build a
Valentino_Stoll:
Yeah.
Adam Gordon_Bell:
house, it's like, it's easy to put in that gas line when there's no walls, but then once there's walls, you know, things become a lot more complex.
Valentino_Stoll:
I think two of, you know, standards that get put in place that aren't official, right? Like
Adam Gordon_Bell:
Yeah.
Valentino_Stoll:
for Vim users out there, like Tim Pope's, like Vim Rails is like the de facto standard for like finding the definition of something within a Rails framework. And so you can like open up a model and a controller context that's related to it. There's just a whole bunch of extra things. And so like for people that have been around Rails a while, you know, you just, you know, and that are Vim users, which is quite a few people, right? You get all these standards in place, and then for new things to come about, it's like hard to kind of change your behaviors. You know, the longer you're around, the harder it is to change, right? And I feel like that's kind of the problem that Ruby is into now, right? Where we have all these people that have been around with the language for so long that are working on this tooling that have, you know, adjusted kind of to those, you know, ways of doing things that, you know, maybe aren't people, you know, new to the language that are using, right? So you get a lot of people using VS code as an example, where, you know, maybe some of the older people in the Ruby community aren't using VS code or aren't using some of these other tools that they would be missing out otherwise. First, how do you discover about them other than, you know, scouring Twitter or something like that and hoping that you pick it up someday, right, or from a co-worker? And second, like how do you readjust your whole way of working with the language, right? Like
Adam Gordon_Bell:
Yeah.
Valentino_Stoll:
it's definitely that's a hard problem to solve
Adam Gordon_Bell:
Totally.
Valentino_Stoll:
I don't have any answers.
Luke_Stutters:
got a fun one for you. At what point does a language become unfixable? Because that's the implication here, right? At what point is it too far gone that you just got to kind of throw it all away and start again just like they did with Python 2?
Adam Gordon_Bell:
Well, the interesting thing to me is that like all of this stuff is actually not a technical problem. It's all actually a community problem, right? There's no reason why, you know, why it will be hard for, for, you know, wide adoption of the Ruby code formatter to happen, but it could happen. Like the limitation is everybody agreeing on a standard way to format the Ruby code. exists, right? Like it's just nobody, it's less common in usage, right? Or in C++, where they have at least eight package managers, like they could all agree on one. The issue isn't they don't know how to build a package manager, they keep building them. It's that they haven't come together to say this is the one. It's a community problem. And sadly, these are the hardest things to address, right? Because you can't just crank out some technical solution, you need to get everybody to agree.
Valentino_Stoll:
It's kind of funny too, because people use languages in so many different contexts, right? Like, you know, everybody's not just a web developer, right?
Adam Gordon_Bell:
Yeah.
Valentino_Stoll:
Like, are people using Ruby for mobile development, right? Like, or like embedded systems, like so many different kinds of applications and contexts. And how do you like make core concepts like the same for all those different contexts where you even have completely different environments sometimes, right? different workflows. I totally understand the Ruby core's hesitance on a lot of features.
Adam Gordon_Bell:
Yeah.
Valentino_Stoll:
Because so many features just don't make sense in so many contexts. And to focus attention or change things too dramatically, you can collapse the entire ecosystem with the wrong decision.
Adam Gordon_Bell:
Yeah. And if you look at it's, if you look at the, you know, in my article, I mentioned Go and Rust a lot because they've put a lot of work into a lot of tooling, but they also have a lot of resources comparatively for programming languages, like, you know, Go is coming out of Google, Rust had, you know, Mozilla support for some time. Like this is a lot of work doing all this stuff. Like that's the truth of it.
Valentino_Stoll:
Yeah. I mean, I'm trying to honestly thank goodness for the amount of, you know, money that Shopify is pouring into Ruby. You know, especially recently, I hate to, you know, with their huge layoffs recently, I hate to talk too much in positive light. But they are doing some great things, right. But, you know, we all we need more. more people you know funding and and uh propping the languages up right uh i don't know if you know go would be as popular as it was if it didn't have something somebody like google saying you know sponsoring it um or if it was just like some third-party organization non-profit right if it would also uh have the same effect which maybe it is now but uh It's kind of funny to me to see what becomes popular of languages based on who's funding it, right?
Adam Gordon_Bell:
Yeah.
Valentino_Stoll:
Because there are so many smaller languages that a lot of people use, too, right? Like Lua as an example,
Adam Gordon_Bell:
Yeah.
Valentino_Stoll:
or what was that one with the Z? Zig, right? alternative if you will as
Adam Gordon_Bell:
Yeah.
Valentino_Stoll:
far as applications, right? So it'll be interesting to
Adam Gordon_Bell:
Yeah.
Valentino_Stoll:
see what else comes out is kind of what I'm getting at, right? Like there's a lot of big companies out there, right? Like that all want to, you know, take advantage of the next thing.
Adam Gordon_Bell:
Yeah.
Valentino_Stoll:
I'm kind of interested to see what will come out of it. Or if, you know, because once you've, let's say that, you know, a program lineage has made all the tooling the most incredible thing to use, right?
Adam Gordon_Bell:
Yeah.
Valentino_Stoll:
You know, people get tired of it.
Adam Gordon_Bell:
Yeah, so
Valentino_Stoll:
Right?
Adam Gordon_Bell:
previously, so previously I wrote this article called like Brown versus Green programming languages. And it was about this topic where I said like, you know, when you are working on like, so it was about the same thing, the Stack Overflow developer survey and about maybe a possible different answer, which is that people like to use new programming languages because they don't want to work on their old code bases because they're a mess. It might be great fun to work on a new Rails project, but if you have one that's super old and has not been given the most care, like you might think differently, right? And how much does that rub off on the language, right? If you're doing a new project, if you're working in Zig, you're probably doing something new because it's a fairly new language, right? So you might not have all this old code that you have to worry with. You
Luke_Stutters:
What is dig?
Adam Gordon_Bell:
might. What's Zig?
Luke_Stutters:
What is sick?
Adam Gordon_Bell:
Oh, it's a cool new programming language. It's like close to C, I guess. It's like a modern take on C development with like, you know, raw memory management.
Valentino_Stoll:
I know when they were... when they're trying to merge the new, what was it? The word is escaping me, but... new compiler or not compiler but uh
Adam Gordon_Bell:
Purser.
Valentino_Stoll:
parser maybe for Ruby. Oh, man.
Adam Gordon_Bell:
Grammar?
Valentino_Stoll:
Why JIT? The new
Adam Gordon_Bell:
Oh,
Valentino_Stoll:
JIT. So
Adam Gordon_Bell:
yeah, yeah,
Valentino_Stoll:
they're
Adam Gordon_Bell:
yeah.
Valentino_Stoll:
trying, right? They're, they were trying to figure out whether they should use Rust or and they were considering Zig, right? Like,
Adam Gordon_Bell:
Yeah.
Valentino_Stoll:
for their practicality with kind of extending C for more like higher level abstractions, right? Because that's one of the biggest problems with C is you don't really have that like class structure that and make it a little more modular. And so I don't think Zig had the maturity that it needed at that stage, but I know it was in kind of close consideration.
Adam Gordon_Bell:
Do you want to talk about the staff software engineer article?
Valentino_Stoll:
I do. I'm curious what a staff software engineer is. I know
Adam Gordon_Bell:
So
Valentino_Stoll:
you, you,
Adam Gordon_Bell:
that.
Valentino_Stoll:
you, the article does a great job of kind of summing it up, but I kind of, I, I love to make fun of titles. I feel like everybody is just, you know, that the word engineer kind of in, in a software title, you know, I get a lot of, my wife is an engineer, a
Adam Gordon_Bell:
Ha ha ha.
Valentino_Stoll:
So, you know, anytime that I say engineer in my title, you know, I didn't go to engineering school, right? Like, I don't know engineering principles, like, I know software principles. So I'm curious, you know, what what to you as a staff software engineer, or staff software developer, if you will.
Adam Gordon_Bell:
Well, so this is the aspect of the article I got the most feedback on. It wasn't positive feedback, but
Valentino_Stoll:
Ha!
Adam Gordon_Bell:
like, so in, in big tech, there is a role above senior that it's called staff. And, and so, yeah, it's just like a, you know, a, a step on a higher, you know, hiring ladder or whatever, right. But, um, so I wrote about what I called the other type of staff engineer, which When I was in school for software engineering under the computer science school, but don't tell the engineers about that one. But I had to take a class in the business school at university and it was like this management class and they talked about like staff versus line employees, which was like a traditional way to think about people's roles within companies. So basically it's a different meaning of staff. might work on the line assembling the car, or you might be staff. You might work in the office somewhere. You might do HR or accounting. And it's true for every business. You either are in a supportive role or you're actually like building or selling the product or service that the company makes. So, I was trying to say in this article that whether you're line or staff in this sense, like affects your job a lot. Like if you, you know, you could work on billing software at a utility company as an employee of the utility company, or you could be a consultant who comes in as part of a consulting team to work on the software for a billing company. And these two jobs, although you're doing the same software will be vastly different, right? If you're an employee of the utility company, you probably mainly work with on a small development team, you mainly interact with non-developers. You probably have like a really wide scope of what you do, there's like a lot of software and you mainly try to keep it running. On the other hand, like if you work at a software company, you know, there's probably a lot of software developers. You probably specialize a lot. There's probably a lot of competition for roles. It probably pays better than at the utility company. But I guess what I was trying to say in the article is that there's a lot of differences between these two jobs and people act like they're only is working for like Fang But there's all these other jobs that are under discussed. And I know Luke was telling me that he has a preference, I think.
Luke_Stutters:
Yeah, I've done both. And I never before I read this article, I never kind of really realized that was the difference. So I started off doing software in a software company kind of clawing your way to the top doing that. And I changed over working for a manufacturing company, also doing the software role, but they were a manufacturing company. The factory was for the giant machines that made sheet metal and injection molded. And they needed It was all kind of aggressively outsourced as much as it could. But the opportunities in the manufacturing company were much, much broader than they ever were in the software company.
Adam Gordon_Bell:
Yeah, I think that's common. Like you'll have a wider scope. Like my friend who works for a utility company, like there are very few software developers there, but he, you know, his boss reports to like the COO of the utility company. So if, if he was hungry to climb the corporate ladder, you know, he gets a lot more exposure to how a business works and, and things like that. jealous of and is uncommon in the software world. So there are
Luke_Stutters:
through
Adam Gordon_Bell:
differences
Luke_Stutters:
true.
Adam Gordon_Bell:
for sure.
Luke_Stutters:
And let's face
Valentino_Stoll:
Where does
Luke_Stutters:
it,
Valentino_Stoll:
he
Luke_Stutters:
standards.
Valentino_Stoll:
work again?
Adam Gordon_Bell:
A utility company. Utility companies have like the highest rate of like unionization and pensions of, you know,
Luke_Stutters:
Yeah, let's
Adam Gordon_Bell:
of
Luke_Stutters:
not
Adam Gordon_Bell:
many
Luke_Stutters:
talk
Adam Gordon_Bell:
fields.
Luke_Stutters:
about Enron though, right?
Adam Gordon_Bell:
Yeah, he doesn't work for Enron.
Luke_Stutters:
hahahaha
Adam Gordon_Bell:
But yeah, I think their pension went bust, didn't it? Down with the whole ship.
Luke_Stutters:
Yeah, that's a joke for all the mums and dads out there.
Adam Gordon_Bell:
Ha ha ha!
Luke_Stutters:
The yeah, I was gonna say the other thing is standards, right? If you're working for a software company doing software, the standards are going to be much higher if you're going to sweat the details. But if you're working for like a utility company doing software, those standards are going to be right away down the bottom. And
Adam Gordon_Bell:
Yeah.
Luke_Stutters:
anything you do is going to be seen as a miracle.
Adam Gordon_Bell:
It's true. And like, if you, um, I mean, you also have more ability to sneak by like a weird pet project, I guess, if you're not at a tech company, because nobody's going to question it. If you're like, oh, of course, this new thing has to be built in Zig. Like at the tech company, they're going to be like, what, why? But at the utility company, they'll be like, oh, that he knows what he's talking about.
Luke_Stutters:
Oh yeah, Zig, yeah, sure, we know, Zig, yeah.
Adam Gordon_Bell:
Carry on.
Luke_Stutters:
Yeah, no, I mean, the downside, of course, is that you are no longer in a company with a whole bunch of software engineers. So the opportunity for personal improvement and actually learning stuff is much, much lower. So even though the
Adam Gordon_Bell:
Yeah.
Luke_Stutters:
overall professional opportunities are going to be much bigger, it's not a great place to learn more about software.
Adam Gordon_Bell:
Yeah, I totally agree. The couple of people that I've talked to that have done this did what I called retiring to staff. So it's kind of like, you know, they worked at a tech company where it was high pressure and they got really good at it, but they got a bit burnt out on it. And from there, you know, they transitioned to a more slower paced, more, yeah, I guess just slower paced job at a larger non-tech company where they as much, but they're consciously making that decision. I don't think it's a good place to start your career. Like that, that's my thinking.
Valentino_Stoll:
I think everybody should start their career in consulting.
Adam Gordon_Bell:
Yeah.
Valentino_Stoll:
I think you just work on so many different things and are at the whim of the customer that I think it just shapes your mind, right? Specifically for software. I feel like it's easy, like kind of in a product sense to get trapped by the product, right? Like if you're trying, if your goal is to just work, like, okay, maybe it doesn't matter. But if your goal is to become like good software engineer, and you want to discover a lot of new concepts, it's going to be harder to, you know, dive into a product first. I don't know, in my experience, you know, because I kind of did that. I jumped into trying to make my own product. And maybe that was also a problem on my end. But I feel like I joined a consultancy and just was like thrown at the wall, basically at so many different problems. And over time, a lot of the core components came together and having the experience of seeing a large array of ways to do things, I feel like it made me better a programmer.
Adam Gordon_Bell:
Yeah.
Valentino_Stoll:
I don't know if that's true of everybody, but I feel like it's... It's hard to start in a very, I don't want to say controlled environment, but when the design decisions have already been made, it's hard to learn from that, right? Because you're just learning those design decisions,
Adam Gordon_Bell:
it.
Valentino_Stoll:
right?
Adam Gordon_Bell:
Yeah, no, I totally
Valentino_Stoll:
So.
Adam Gordon_Bell:
agree. It's like you're saying, yeah, cause in the conception of this article, like that is a very clear like line position, right? You're getting thrown, like you're selling your time, right? And
Valentino_Stoll:
Right.
Adam Gordon_Bell:
you, you know, you get to learn from other consultants. I hope, I hope it wasn't just you on a thing alone, but.
Valentino_Stoll:
No, it was definitely with other
Adam Gordon_Bell:
Yeah.
Valentino_Stoll:
people. I was pairing quite a lot, thankfully.
Adam Gordon_Bell:
Yeah, it's a good way to level up your skills, right? But it has the downsides of these line positions. Like it's high pressure, right? And the standards can be hard. I mean, maybe that wasn't your experience.
Valentino_Stoll:
Yeah. It was, it's definitely overwhelming to start no matter what. Right.
Adam Gordon_Bell:
Nah.
Valentino_Stoll:
So maybe it's, maybe it's easier, like a more calm experience starting in a more controlled environment. Right. So I guess it would depend on your, you know, how you learn. If you're, you know, if you need things to be, you know, more delicate to start and then, you know, ramp yourself up, maybe it would be better to be in a more controlled environment. Right. But yeah, I mean, consulting is definitely chaotic. right like you're at the whims of the customer and you know sometimes you know the right consultancy can help you know buffer between the client enough but it's never gonna be perfect and you're always gonna be you know there's gonna be something where the the customer is just like doing something crazy and asking a lot of you right and you're like I don't know if I could do this right like I'm learning
Adam Gordon_Bell:
Yeah. It's like somebody had described, um, everybody I know who's done consulting only did it for a certain amount of time. And it makes me think of somebody who was talking about working at Amazon as a web developer who said that they would burn through developers like they were tea candles.
Valentino_Stoll:
That's
Luke_Stutters:
I can't believe that. Jeff Bezos always strikes me as a very nice man.
Adam Gordon_Bell:
Very relaxed.
Valentino_Stoll:
You know, it's kind of funny though, this line staff, you know, analogy, I think it makes a lot of sense, like even outside of software, like my wife, she works at a pharmaceutical plant and you know, they have tons of consultants
Adam Gordon_Bell:
Yeah.
Valentino_Stoll:
come in, right, and do various things and they are their line, right? Like they have, you know, they won't do work unless you ask them to do something, right? And so they have very specific things you line up their work and they get it done, right? And as people are growing as part of the staff, like, you know, supporting basically for when, as they call it, the real work
Adam Gordon_Bell:
Ha!
Valentino_Stoll:
needs to get done. You know, it definitely makes a lot of sense to me. But I still have this thing with titles. The whole, I know I get the origins of the military nature, right? And there has to be, email phrases for things that everybody can come together and agree on. I feel like titles though are, they're
Adam Gordon_Bell:
Yeah.
Valentino_Stoll:
still not great, right? Like you, you stamp a label on somebody and then they're, you know, that doesn't travel to different
Adam Gordon_Bell:
Yeah.
Valentino_Stoll:
companies, right? Like let's say just senior, software engineer, right? Like that's different at so many different companies, right? Like, uh, I feel like, enough and they're not standardized, right? So like just go just saying, you know, staff software engineer, maybe that paints a certain picture maybe as far as like, you know, what some of their abilities are but I don't know, it's also funny just staff software, like
Adam Gordon_Bell:
Yeah.
Valentino_Stoll:
isn't everybody part of the staff, right? I Definitely throws me.
Adam Gordon_Bell:
What we need is like maybe a Pokemon based system.
Valentino_Stoll:
Yeah, something that's completely
Adam Gordon_Bell:
Yeah.
Valentino_Stoll:
different from our reality, right? Where we could be like, all right,
Luke_Stutters:
Thanks for watching!
Valentino_Stoll:
well, it's definitely, you know, it's defined,
Adam Gordon_Bell:
Yeah.
Valentino_Stoll:
clearly defined, right? It has this hierarchy, like.
Luke_Stutters:
could just use the github system
Valentino_Stoll:
That would
Luke_Stutters:
and
Valentino_Stoll:
be
Luke_Stutters:
say
Valentino_Stoll:
great.
Luke_Stutters:
you're like a 15,000 star general
Adam Gordon_Bell:
Just how many stars you've accumulated. I like it.
Luke_Stutters:
So Adam, you're in quite an extreme position. You're not only a line software engineer, right?
Adam Gordon_Bell:
Um, I don't know.
Luke_Stutters:
in that you your company is a software company.
Adam Gordon_Bell:
Yeah, that's right. So my, my company is a software company. So I work for earthly and we make an open source build tool. And actually, um, something cool. I thought I'd mentioned here is we we've just gone open source. Well, I mean, it was in April, but relatively recently we were, um, we were using a open core, uh, model, I guess for our build tool, but we switched now to a MPL too, so we're open source. The code was always on GitHub, but now all the legal asterisks are gone.
Luke_Stutters:
But I was going to say was
Valentino_Stoll:
I have
Luke_Stutters:
not
Valentino_Stoll:
so many
Luke_Stutters:
only
Valentino_Stoll:
questions.
Luke_Stutters:
is it a software company, but you are selling software to other software developers, which has always struck me as a bit extreme because it's not like you're kind of making a product for just e-commerce or a particular industry. You're selling it to other developers, right?
Adam Gordon_Bell:
Yeah, that's right. It is
Luke_Stutters:
that
Adam Gordon_Bell:
extreme.
Luke_Stutters:
is that the complete nightmare that I dream it is?
Adam Gordon_Bell:
Uh, I think it's great because like as software developers, we have a very good understanding of what our customers would like. I mean, you know, I'm sure it has, uh, upsides and downsides, but, uh, yeah, we definitely have a good grasp on, you know, the needs of our customers since we, you know, are similar to them. I don't know. I don't find it a nightmare. What's your concern about it?
Luke_Stutters:
I just imagine it'd be like cooking for Gordon Ramsay.
Adam Gordon_Bell:
Yeah, that's true. You think software developers are hard to deal with? You're like, I could have any customer I wanted and I chose you guys.
Luke_Stutters:
I've done a lot of software products where people kind of phone me up and say, hey, you know, why doesn't it work like this? Why doesn't it work like that? But I've never done a product where those same people can look at my code and say, hey, why have you done this? Hey, why have you done that? That's another level, right?
Adam Gordon_Bell:
Yeah, no, that is true. Um, so
Luke_Stutters:
So
Adam Gordon_Bell:
I don't, I don't know.
Luke_Stutters:
on that note, why did you decide to go open source?
Adam Gordon_Bell:
Yeah. So we, um, yeah. So, so Earthly is like, it's a combination of like a make file and a Docker file, if you want to think about it, like it's, it's an easy way to build. Software. Um, and it's, it's open source and then we're commercializing it by, by building like a, a CI that people can, can use. Um, so originally we use this license, uh, BSL license that was originally created by Maria DB. And it basically says like, this software is completely open source, except unless you use it to compete with us commercially. And Maria DB came up with this because of Amazon. Mr. Jeff Bezos, we were talking about earlier, right? They wanted to offer a hosted version, I guess, of Maria DB and they didn't want to have to compete with AWS. So they came up with the special license and then lots of other companies followed it. We're open source, you know, just with a asterisks, but you know, that's very confusing for people. I think, you know, they haven't heard of this license. They don't understand. Like you're only trying to preclude, you know, somebody directly competing with you. People understand open source much better than like open source with an asterisk. And when you want to convince a developer to use, you know, your open source software, you don't want them to have to go talk to you. to legal and try to figure out like what the ramifications of this might mean. Um, so we just change it for simplicity. Go for it.
Valentino_Stoll:
I have so many questions. I mean, it's kind of like It's kind of a dream for a company to like be able to take what
Adam Gordon_Bell:
Yeah.
Valentino_Stoll:
they've worked on and get other people to contribute it to it. Right. Is is that what you've experienced like have when you took this you know open were people already kind of contributing to it. Like do you see a
Adam Gordon_Bell:
Uh,
Valentino_Stoll:
huge
Adam Gordon_Bell:
no.
Valentino_Stoll:
uptick after you
Adam Gordon_Bell:
So,
Valentino_Stoll:
did make
Adam Gordon_Bell:
I
Valentino_Stoll:
it
Adam Gordon_Bell:
mean,
Valentino_Stoll:
officially
Adam Gordon_Bell:
it was
Valentino_Stoll:
more
Adam Gordon_Bell:
always
Valentino_Stoll:
public.
Adam Gordon_Bell:
source available. So the source, it was always on GitHub. Um, we were always working out in the open. Um, and people did contribute, um, somewhat, although most of the development is internal. Um, but what did happen is like when we would get some publicity somewhere, people would be like, well, you know, it'd be nice if it was open source. Like we kind of got more like the occasional snide remark about like, what's this weird license, um, you're using. that aspect of it, like people, but like the people, I don't think the people who are excited to contribute, you know what, it's hard to say, right? Like if people were being scared off because of the license, we would never know, we would never hear from them. So it is hard to say, but yeah, we get some contributions,
Valentino_Stoll:
Right.
Adam Gordon_Bell:
maybe a little bit more than before, but we've always been working out in the open. But my job is developer relations. And so I contribute to the product in a minor way. I'm not the primary developer. If I put in a big PR, it gets looked at closely.
Luke_Stutters:
I will say that having
Valentino_Stoll:
Oh, that's funny.
Luke_Stutters:
Go ahead.
Valentino_Stoll:
So I mean...
Luke_Stutters:
I would say that having tried to get open source products
Valentino_Stoll:
Go ahead
Luke_Stutters:
into
Valentino_Stoll:
Luke.
Luke_Stutters:
very large corporations a couple of times, both in America and Japan, licensing is an enormous barrier to entry. The more corporate it is and the more money they have, the more they're going to worry about the legal status of the license. I had the most incredible showdown about using GPL-based
Adam Gordon_Bell:
Yeah.
Luke_Stutters:
software in a product because part company was just utterly convinced that this meant that they had to release all of their source code for different products that weren't actually in that product, which was obviously not true. But there's a very large amount of nervousness when it comes to licenses, especially when dealing with bigger companies and bigger accounts. So I think it's definitely the right way to go.
Adam Gordon_Bell:
Yeah, no, I totally agree.
Valentino_Stoll:
I'm surprised it's not like a can I use, right? For a repo on GitHub, right? Where you
Luke_Stutters:
Hmm.
Valentino_Stoll:
could just click a button and say, okay, this is what I'm doing with it. You know, kind of like,
Adam Gordon_Bell:
Oh,
Valentino_Stoll:
you
Adam Gordon_Bell:
yeah,
Valentino_Stoll:
know,
Adam Gordon_Bell:
that's
Valentino_Stoll:
HTMLs
Adam Gordon_Bell:
a good idea.
Valentino_Stoll:
can I use for elements and selectors and stuff? Because I mean, I don't even think about it often. I'll just like use it and be like, oh, this is great. And then after the fact, right? Look at the license and be like, oh crap, right? I've definitely started looking at it more now that our company has grown. But licensing is just so
Adam Gordon_Bell:
Yeah.
Valentino_Stoll:
funny. If it's on GitHub, people just think you can use it. And so people do, and it doesn't really become a problem until something happens with the company that you're using it with. Let's say you wrote this incredible new application. And you've gone and used all these things and then you know you went to sell whatever
Adam Gordon_Bell:
Yeah.
Valentino_Stoll:
you've made right and they'd be like Oh, well, you sorry you can't sell it Like and people scramble to you to swap it out with something else right like that's typically what happens and so It's it's funny that you mentioned that like, you know people would complain about license
Adam Gordon_Bell:
Yeah.
Valentino_Stoll:
because I feel like for the most part You know people don't really look at it, right? Like of curious, have you gotten any new feedback since you've like, you know, changed that license or, you know, what advantages are you hoping like long term to get out
Adam Gordon_Bell:
Yeah,
Valentino_Stoll:
of this
Adam Gordon_Bell:
I
Valentino_Stoll:
other
Adam Gordon_Bell:
mean, that's
Valentino_Stoll:
than
Adam Gordon_Bell:
the
Valentino_Stoll:
just
Adam Gordon_Bell:
big
Valentino_Stoll:
maybe
Adam Gordon_Bell:
one.
Valentino_Stoll:
like corporate
Adam Gordon_Bell:
But I mean,
Valentino_Stoll:
adoptability?
Adam Gordon_Bell:
we were always source available, right? So it wasn't a huge change. Um, like the code was already always out there. And that's
Valentino_Stoll:
Right.
Adam Gordon_Bell:
important because like, I mean, we've been talking about developer tools here today, but like, people don't want a proprietary developer tool, like if, if you, especially like we're making something. To, to do your builds and to, to do your CI and like, you don't want for us to disappear and then you can't build your software anymore. Like that sounds horrible. Right. it all open source, all out there like on homebrew or on your various package managers and you can audit the code if you want. Like, I feel like that's the big advantage. You know, just from a developer safety point, if I'm thinking about it, I'm like, well, I don't know what this thing is. Um, but yeah, the legal question. Yeah. I mean, I think it
Valentino_Stoll:
Right.
Adam Gordon_Bell:
comes up and that, and then like, it depends on the size of the organization, right? Like we've definitely talked to companies who they just want to use open source tool, but first they have to set up a meeting with us and there's like eight people on their side. And I assume that those companies think very carefully about the licensing if they're having meetings with every tool they pull in. I mean, I wonder how they get anything done, but these places do exist.
Valentino_Stoll:
Yeah, I wonder if like, has there been anything else that you've had to kind of focus on to help support, you know, now that it is truly an open system to use, I know it's been, you know, the source has been available. But you have you had to add like extra documentation or anything like that that you focused on?
Adam Gordon_Bell:
Uh, you
Valentino_Stoll:
Like,
Adam Gordon_Bell:
know,
Valentino_Stoll:
what
Adam Gordon_Bell:
before,
Valentino_Stoll:
was your next step
Adam Gordon_Bell:
before
Valentino_Stoll:
after
Adam Gordon_Bell:
we
Valentino_Stoll:
just
Adam Gordon_Bell:
even
Valentino_Stoll:
like
Adam Gordon_Bell:
changed
Valentino_Stoll:
changing
Adam Gordon_Bell:
the license
Valentino_Stoll:
the license
Adam Gordon_Bell:
file,
Valentino_Stoll:
file?
Adam Gordon_Bell:
we did, um, participate in Haktober Fest a couple of times. Um, and to do that, we spent some time like making sure we had a contributor's guide and then, you know, we also tried to collect like easy issues, you know, like it's actually hard to do where it's like, if you see a small problem, like don't just fix it, like put in an issue and label it as like a good first issue. It's just some minor little thing. A lot of times people need that to get their feet wet, right? They need something that they can, you know, go through the whole process, but just make a small change, like this flag, you know, isn't, you know, the help for this flag at the command line is wrong or something, right? Just, um, those things become like kind of on ramps where, where people can understand how to contribute, uh, to the project, but, but honestly, like most of internal. The whole process is external. You can see what we're working on. But it's mainly done by us.
Valentino_Stoll:
Yeah, I remember seeing that methodology used on was it the Rails mini profile or gem, which basically like if you're familiar with the rack mini profile, it's like this tiny little tab at the top
Adam Gordon_Bell:
Yeah,
Valentino_Stoll:
of your
Adam Gordon_Bell:
yeah.
Valentino_Stoll:
Rails pages that shows you like how fast things loaded in various parts of the stack. And this guy made this new like version that was Rails mini profile, what gives you like this slicker like UI to kind of in the stack and the timing of it. And I went to look at his repository and it was great. Like he would just put like, he was just like loaded up the issues on the repository of everything that he wanted to get done. Everything that he wished to, right? Like just basically did like a mind dump, like in the issues and then just like slowly started like chipping away and tagging stuff. But
Adam Gordon_Bell:
Yeah.
Valentino_Stoll:
like just seeing that all the issues there, it like made me wanna jump in, right? Like, I'm like, oh, like this looks like interesting. right? Like, you know, just seeing where the trajectory
Adam Gordon_Bell:
Yeah,
Valentino_Stoll:
would
Adam Gordon_Bell:
that's
Valentino_Stoll:
go
Adam Gordon_Bell:
a good point. Now that
Valentino_Stoll:
can
Adam Gordon_Bell:
you
Valentino_Stoll:
kind
Adam Gordon_Bell:
mention
Valentino_Stoll:
of like
Adam Gordon_Bell:
it, like,
Valentino_Stoll:
bring
Adam Gordon_Bell:
so
Valentino_Stoll:
in
Adam Gordon_Bell:
we,
Valentino_Stoll:
more contributors that
Adam Gordon_Bell:
we
Valentino_Stoll:
way
Adam Gordon_Bell:
get
Valentino_Stoll:
I
Adam Gordon_Bell:
a lot
Valentino_Stoll:
feel.
Adam Gordon_Bell:
of interaction in terms of yeah, issues and proposals. So we, we do proposals up as, uh, tickets in like, GitHub. We have like a roadmap on there with, has like some swim lanes where we can put, you know, this is experimental. Like we actually have this, but it's not, uh, guaranteed. Like we might remove it at some future point, you know, some things that were just planning, um, and we put together these proposals. discuss it on the GitHub issue. And a lot of times people will suggest something and then we're like, this is a good idea, let's turn this into a proposal, right? Like this is the change you might be suggesting. So yeah, we get a lot of contributions that way. And in a lot of ways it's a lot more valuable than, yeah, like somebody just fixing a minor bug, right? These are people who use the product, who are trying to help shape what it would become. Sort of similar. Sorry, go ahead.
Valentino_Stoll:
uh... kind of taking your So have you noticed, have you noticed anybody like...
Adam Gordon_Bell:
Oh yeah, like we definitely see people using Earthly
Valentino_Stoll:
you know
Adam Gordon_Bell:
to build
Valentino_Stoll:
seeing
Adam Gordon_Bell:
their software.
Valentino_Stoll:
something out there that
Adam Gordon_Bell:
Yeah,
Valentino_Stoll:
are like oh no they've taken it and they're you
Adam Gordon_Bell:
I
Valentino_Stoll:
know
Adam Gordon_Bell:
don't
Valentino_Stoll:
making
Adam Gordon_Bell:
know.
Valentino_Stoll:
their
Adam Gordon_Bell:
I'm
Valentino_Stoll:
own
Adam Gordon_Bell:
sorry,
Valentino_Stoll:
thing
Adam Gordon_Bell:
I don't have a good story of
Valentino_Stoll:
if
Adam Gordon_Bell:
like
Valentino_Stoll:
we're in
Adam Gordon_Bell:
this
Valentino_Stoll:
running
Adam Gordon_Bell:
guy
Valentino_Stoll:
with it
Adam Gordon_Bell:
was like, finally,
Valentino_Stoll:
like
Adam Gordon_Bell:
now
Valentino_Stoll:
was
Adam Gordon_Bell:
I will
Valentino_Stoll:
that was
Adam Gordon_Bell:
use
Valentino_Stoll:
anybody
Adam Gordon_Bell:
it. And then,
Valentino_Stoll:
higher up
Adam Gordon_Bell:
yeah,
Valentino_Stoll:
like you know that
Adam Gordon_Bell:
let's
Valentino_Stoll:
was
Adam Gordon_Bell:
just
Valentino_Stoll:
worried
Adam Gordon_Bell:
pretend
Valentino_Stoll:
about
Adam Gordon_Bell:
he's out there.
Valentino_Stoll:
you
Adam Gordon_Bell:
His
Valentino_Stoll:
know
Adam Gordon_Bell:
name
Valentino_Stoll:
the change in the licensing
Adam Gordon_Bell:
is Jeff and legal told him no, but once we changed things, then he ran with it. Yeah.
Valentino_Stoll:
Ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha
Adam Gordon_Bell:
Thank you, Jeff.
Valentino_Stoll:
Ha ha ha!
Adam Gordon_Bell:
Yeah. Yeah. Yeah. Yeah. Yeah, Elasticsearch is a great example. So it's like what Amazon's they changed its name from Elasticsearch, I think, but they like put it in brackets. But anyways, yeah, Elasticsearch, uh, you know, you can, what, do you know what the AWS one is called? I don't know, but Elasticsearch, the company was not happy that like everybody's using Amazon's version of it because everybody's on AWS. Legitimately, I think they have right to be upset about this. So, yeah, we're taking that risk. If you're listening, Jeff Bezos, please don't crush us. Yeah. Yeah. I mean, also, so MariaDB was the BSL license and they're a database and Amazon will Amazon does sell databases, right? Like they're directly, I think in the, in the line of fire. Um, you know, CI is, they do have, uh, they do have build products, but it's, it's less directly in their wheelhouse. I mean, maybe it's more in Azure's wheelhouse. Maybe that's who we should be worried about. But the bet we're making is that we're making really valuable and people will want the earthly brand and you know that we have advantages that we can add on. Yeah, so hopefully that works out. Yeah, see they changed the name. They're like, it's not. dangerous game. Oh, okay. Yeah, I think there was a lawsuit or something. No, I don't think so. This has been fun.
Luke_Stutters:
Yeah, I mean, to call back to my earlier point about languages that are too far gone to save, the obvious one I'm thinking of is C++. And Google this week have announced there would be C++ killer called Carbon Lang. I'm not sure if you've seen it, but it's caused a lot of discussion, shall we say. So everyone should go and learn that doing C++ anymore. My next two picks are from, of course, Adam's own podcast called Co-Recursive. Now the first one is for older people and it's an interview with a guy called Jeff Schrager who was involved in the first ELISA protocol. This was a kind of early chat bot. Now I actually had an ELISA in Basic which I got from which I ordered through the mail. So this episode has a certain amount of magic for me. It's not going to appeal to younger generation at all. But I loved every second of it. It was absolute gold. And if you want something more up to date, they've also got my personal heroes on there. By day, I mean you, Adam, which is the interview with Casey Muratori, who is absolute and there's a great episode with him on there as well.
Adam Gordon_Bell:
Do you see Casey's terminal, like Windows terminal stuff?
Luke_Stutters:
My favorite video of Case Miratoria is how to use Git video on YouTube. That is fantastic.
Adam Gordon_Bell:
He's a harsh, he can be harsh.
Luke_Stutters:
It's very, very entertaining.
Adam Gordon_Bell:
Yes.
Luke_Stutters:
We're all very aware, we're
Adam Gordon_Bell:
Yeah.
Luke_Stutters:
all painfully aware. That's not
Adam Gordon_Bell:
Weird.
Luke_Stutters:
funny,
Adam Gordon_Bell:
Yeah,
Luke_Stutters:
that's gruesome.
Adam Gordon_Bell:
that's strange.
Luke_Stutters:
I'm pretty sure Will Smith was in that movie, right?
Adam Gordon_Bell:
Um, so my pick's unusual. So I got a Peloton tread, the Peloton treadmill. Um, so.
Luke_Stutters:
Oh wow, like a peloton but without all the awful cycling.
Adam Gordon_Bell:
Yeah, you run instead. So I had a treadmill that I didn't use very much that I got rid of. And I used to like walk on it sometimes, but now I have the Peloton tread. The classes are amazing and have got me like actually exercising. So there's like, I don't know what type of music you're in, but I'll do like a Pearl Jam class and it's all like Pearl Jam songs and somebody, you know, getting you to run and also telling you facts about the history of Pearl Jam and there's some nineties rock ones and system of a down one. I think you can see just by what I've named, like the genre of music that I listen to, but it's been great. So hard, like turns out running is hard and it's not like jogging. They're like, they'll yell at you, tell you to keep going faster. So yeah, Peloton Tread has been awesome. I'm loving it. That's my pick. Ha ha. Yeah, it hasn't happened to me yet, but I've worried about it too. And they're like, faster, go faster, go faster. I'm like, I'm going to get thrown through the wall. Like if I turn this up any higher. Yeah. So I'm on Twitter at, uh, Adam Gordon Bell also on Pelton. Uh, although I don't really know what that means. If you, if you track me down on there, I guess you could see what my runs. Um, yeah. And check out my podcast. The that's co recursive.com. Yeah. I think that's enough plugs. Awesome. It's been fun. I like your on air light. Does it, is it hooked up to something? Like is it?
Luke_Stutters:
Thanks for watching!
Adam Gordon_Bell:
Oh. That's awesome.
Luke_Stutters:
Huh.
Adam Gordon_Bell:
Oh.
Luke_Stutters:
Hmm.
Adam Gordon_Bell:
That's cool. That's super cool. Ha ha ha. Awesome guys. Well, this has been fun. Do you know when will the episode come out?
Luke_Stutters:
Duh. We do now get a notification. I got an email saying an episode has gone out, but it doesn't tell us when it's going to go out.
Adam Gordon_Bell:
Yeah, no worries. Yeah, no worries. I'll survive either way. It says 99% uploaded. I'm not at 100 yet.
Luke_Stutters:
Yeah, mine too. Just having to think about it. Mine said recording.
Adam Gordon_Bell:
Yeah, mine's recorded too. Uh, I've had some bad luck. Like I've been using Riverside for my podcast too. I have occasional bad luck with it. Yeah, one time I, the episode ended and then, yeah, the, the guests would never get past 99%. And then, uh, yeah, I had to reach out. I reached out to the Riverside people, like we ended the call and then they said, Oh, it's lost. Like we can't get it back. Right. Yeah. So I like, I tweeted it out and I like CC'd Riverside and I was like, you guys are calls or whatever. I got like a sport ticket like three minutes later. They had like sent me a link to it like an S3 bucket that had that in there. Yeah. Yeah. Yeah, and then I deleted the tweet. I felt like there's like a Yeah, but yeah, it didn't it didn't feel right though, right? It's like You shouldn't need to threaten them to get results
Luke_Stutters:
I'm just gonna let it sit there, but I'm gonna call it a night, because it's half three here.
Adam Gordon_Bell:
Yeah, I'll just hit leave studio, but leave it running and upload. Thanks guys, this has been fun.
Luke_Stutters:
Yeah, I wish I was in better shape, Adam, but I'm dying here.
Adam Gordon_Bell:
I'm out. I hope you start feeling better.
Luke_Stutters:
The Imodium does nothing. It does nothing.