Show notes
Join jLove conference for free or use discount PROGRAMMINGLOVE OLI [00:00:23] Welcome to the Programing Love podcast, episode seven. I’m your host, Oli, and this is a High Fidelity podcast where we meet passionate people and discuss programing on this podcast. You’ll hear stories from individuals around the world on their journeys and the joys and pains they experience along the way so we can all learn and move forward together. Shameless promo from me. And today I also have my co-host, Anton. [00:01:30] And we have a wonderful guest, Kelsey Hightower! Kelsey Hightower has worn every hat possible throughout his career in tech and dangerous leadership roles, focusing on making things happen and cheap in software. Kelsey is a strong, open-source advocate focused on building simple tools that make people smile. And I’m smiling right now. When he’s not slinging go cold, you can catch him given technical workshops covering everything from programming to system administration. Hello. ANTON [00:02:10] Hey, I’m happy to be here. OLI [00:02:12] Thank you so much for coming. So before you came here, before the episode, we were discussing that you’re a visionary, that you inspire and people in tech and also has your opinions on how and where the technology should or will go. So and I would like to set up the main topic for today’s episode is discussing the current developments and current trends in software. And we’ve got a few. Blog posts that we want to discuss with you, except one thing, you gave a lot of interviews, at least I found a few about cabernets and your career from the beginning and still dance. So I would rather not focus on that in this podcast because it’s already covered somewhere else, if that’s OK with me. ANTON [00:03:22] That’s great. I’m looking forward to it. OLI [00:03:24] OK, so Enten, you posted this technology over there, Trent. KELSEY [00:03:33] Oh, yeah, like that’s that’s kind of a well known resource by Thoughtworks, where they built kind of a map of different technologies in a scale from adopt to hold or access or trial. And they are looking at different. Techniques, tools, languages, platforms, what would they adopt in their projects and what not, they’re what they would not suggest using for now or what would they suggest to assess or assess or adopt for others? I’m sure it’s not the latest issue. I think the latest latest issue of that radar has been published in December. So it’s not really recent anymore. So should we look at that first or we have another resource which was published yesterday about the languages. OLI [00:04:43] It’s up to Kelsey. What do you want to look first at? Kelsey [00:04:47] Anything is fair game. We can go in any direction, technologies, programing, languages. That’s pretty much my day job at this point. Anton [00:04:56] Let’s look at the platforms there, are there. I will post a link in our chat so that we could look at the same page, I guess. Yeah. There it is. So it’s interesting that in this part of their report, they are not suggesting to look to adopt any platform, but they are just they have just mapped out the trial and assess categories mostly. And that’s a little bit strange. Or if you’re suggesting to adopt something, it’s it’s a major technology and doesn’t make sense to to put it on the map. I don’t know. But ways like I would put in to adopt any cloud platform there, right? So, like Google, Amazon, Asia. Any others, but for some reason, they are not there, but it’s interesting to look at the assess category. I think it’s the largest one in the report right now, like, for instance, Plumy. Have you heard about the looming. Kelsey [00:06:12] Yeah, I mean, I’m looking over this list and things like plumy, which is, you know, if you’re familiar with TerraForm, know the whole infrastructure as code movement. You know, you had this idea that, you know, all these cloud providers have different ways of interacting with their APIs. You can pick a tool like TerraForm, which chooses HCL is its programing language of choice. And then the Plumy community kind of looks at all these declarative config and says something is missing, the power of a full programing language. And so we look at Pelamis, you know, there’s all of these libraries that try to give you these really clean ways of doing some similar tasks with way less code, but a full blown programing language, as most developers would expect. So if you kind of have this full stack engineer mindset, maybe you’re practicing dev ops where you share responsibility. I can see how some people look at me and say, hey, maybe this is the tool that we use instead of all of these maybe slightly different config languages. So I can see how, you know, maybe they’re starting to see people show up and say, hey, we want to try halloumi for our next project. Anton [00:07:19] Well, it seems to me that there is like the crowd is separate, very much like the first part of the crowd would be like yaml oriented, but we can do everything in a declarative way and use the gun for that or any any other markup language. And then there is part of the community that says, hey, we don’t like all those drawbacks that this stickler declarative configuration brings and we want to have control over what we actually write. And we need better validation for for whatever we create. So, like, it sounds appealing to have compiler checks on your configuration, right? Kelsey [00:08:06] Yeah, but I think in the case of this one, you know, like Cuban etiquette dictates that there’s a data model for everything it does. That’s just how that particular layer in the platform, other platforms like Cervalis platforms also are now delivering these declarative APIs. So now I think it comes down to what interface do you want? You want a command line tool? Do you want to just use Kerl and call the raw API? Do you want to use terraformed or do you want to use Plumy? Right. And let’s not forget about all the people that are still using Ansible, which is largely Python intermixed with some Yamal constructs. People are still using chef and puppet, which are largely either Ruby or their own custom. DSL, I just don’t think would ever be one. So I think what’s happening here is that more people’s preference of working. There are more tools that are showing up that aligns with that subset of people who say, hey, you know, I think one thing that is commonly shared. People do like the fact that there is a low level data model now. So if you want to go from plumy to terraformed or just writing Yamal by hand, that’s available to you. It wasn’t like that before. Right before you pick a tool, you’re stuck with that tool forever and you have to go rewrite all your code. And hopefully there’s a language module to interact with those underlying APIs. So I think we’re sliding into a world where treating infrastructure as data versus a bunch of APIs. Anton [00:09:33] It’s like every problem in computer science can be solved by adding another layer of indirection, it sounds to me like that basically we have modeling that can generate it in whatever way we want. Kelsey [00:09:46] I’m pretty sure someone’s going to show with a Haskell tool for people that want to do everything with pure functions. Right. There’s just no limit to it because there’s so many people working on these particular problems that they’re eventually going to solve it in a way that they think is best. And given the way open source works, they’re probably going to share with the world and it will get traction by a subset of our communities. Anton [00:10:10] Yeah, but one interesting part there in this map in this quarter of this map, let’s say in the platform’s category, is the category where we have just not overload. Basically, I’m looking at what’s written here, and I guess it’s something against Noad. As nogs, Kelsey [00:10:36] yeah, so I just clicked on it, so it’s basically saying, hey, look, there’s a tendency to use Noad indiscriminately for the wrong reasons, right? So, you know, maybe there’s an enterprise who says we went to some conference? You know, JavaScript is still arguably the most, you know, used programing language in the world. And so you go to a conference and you’re like, hey, you can use JavaScript on the front end and the back end. And I think a lot of enterprises just went crazy and says, oh, we can finally do it. We can add another language to our back and stack outside of maybe Java and now we can break in JavaScript. Now we’re cool, right? We’re doing Noguez. Everybody wants to work on Noguez. There’s like seven hundred thousand frameworks to choose from. We’re using one of them. And I think people just got a misguided I was actually reading the engineering or and I remember the team just really, really want to use nogs so bad. I was like, why do you want to use this for this back in project? I get JavaScript for a lot of frontin. It’s really great for that. Lots of knowledge, lots of framework. But the back for the micro services and restful APIs we were building, there was not a lot of value when we started to talk about resiliency. I like this thing would crash or how we would handle error recovery. And so it just it felt like it was more of a fad than a great engineering choice at the time. And I think a lot of enterprises have kind of made the same mistakes. And, hey, we want to write this in nogs. But why? Because we’re going to pick the language first before even thinking about the broader ecosystem for the problem we’re trying to solve. So I think that’s what they’re hitting us like. We need to hold on if using node by default for everything. We don’t need to use it for machine learning. Just because JavaScript is used in other places doesn’t mean we have to use it in all the places. OLI [00:12:23] You know, I have something to say about this, so I’m coming from Schola World Times Carlip developer and there is psychology’s, which is allowing you to write Fronton in Schallert apparently. And that is. The justification for this is that you don’t have to hire a lot of different engineers, you have your spot what’s called developers, and they can do front end and peck. And so I think the same ideas here, enterprises, a lot of the times are excited about not just because they don’t have to hire people from hired different developers. They kind of found their way, found how they conduct interviews, how they like find resources for hiring people. And that’s one of the reasons, like you think, OK, I have the silver bullet and now I can invite a genius developer to my team and they can do both backend and front end. Kelsey [00:13:42] I think that was the idea, right, and then you go and find out, hey, a lot of these platforms, the syntax is the least of your problems, right? Like if you want to go do iOS, the SDK is the library start to dominate. You know what? You’re going to get out of those. So, you know, maybe a company like we’re going to figure out how to rewrite all of the iOS libraries into JavaScript or JavaScript compatible. So we don’t have to learn those things. But we all know you get to a point where you have to break out into the native language to get something done and end up with a diminishing set of returns. If you try to shoo everything into one spot. So, yeah, it definitely makes sense why people would want to go that route. But I think a bit of pragmatism and honesty is required before we believe that there will be one framework for everything. Anton [00:14:27] Or the thing is, even though it’s appealing to have the single language for both back end and front end and well, I’m guilty for that too. I’m part of Cocklin Development Team and we are aiming for back and codling for front and cutting for mobile and everything. So it’s appealing to have the same language. But you have a different domain, right? So the front end developer who works with JavaScript has a completely different domain and problems to work with than the backend developer. And where you have to think of databases, transactions, concurrency, whatever else you have, their resiliency. And on one front and you have this domain object model rendering and now downloading resources and so on, completely different domains where you can’t really just take one person and dropped into the other domain without proper training. Of course, the same tool will actually help a little bit so that you don’t have to now break up or learning a different language. Probably it depends, I think. But but it’s it’s an appealing thing to have the same language for different domains, I think still. But in this particular context that we had in in the rather on NOGs is like they are looking at it as an as at the wrong time, not as a language. Right. So you can actually write typescript instead of JavaScript. And I see a lot of companies are doing it like some some startups here in Estonia. I know that they are using nogs, but they’re they’re writing stuff in typescript and pretty happy about it. Kelsey [00:16:24] Yeah, I think it will definitely work, I mean, if I have my choice, I’m probably picking something like Googling, just thinking about what that runtime particularly gives me and the standard libraries and the type of systems build with the goal. You know, this is probably why I would prefer for that particular set of tests. But yeah, I definitely get the appeal. But I’m just at this point, right. Tool for the job. I just it’s hard to shoehorn. I’ve seen people try to recreate libraries that don’t exist. And then instead of writing code, leveraging all of that cost savings from using the same language, they’re all maintaining a whole bunch of libraries to fill in all of the gaps because very few people are using that particular runtime or stack in that particular domain. Anton [00:17:09] Right. So talking about the popularity of the language is we have another resource which was published just yesterday. So I think it was just a good intro to that topic. So we’ll read Monk. Well, you know, all kind of popularity indexes are there, like Tobey’s these DOONG. Some people like it. Some people hated. I actually hate it because it’s I think it’s not. I think it’s not a viable metric to just count the searches, but read Monks’ stats is something that I really like. They correlate the number of questions on Stack Overflow and and the number of repositories created at GitHub. So that one looks more like a true story for me. So they just published a new report yesterday and all a JavaScript is the number one there. And they say it’s it’s going to take a long time when it’s changes. So we we we have JavaScript here for good and for long. But the other languages, especially when you look at the bottom, like number 10, number 15. They are changing. There are some trends there, and it’s interesting that Ruby and Go are actually losing losing deposition’s. As they say, I’m not sure if it’s really true or not, but, well, they provide the evidence. Kelsey [00:18:49] So I guess for me it’s like, what are you trying to win? I me like, yeah, I was contributing to a project written in one of these languages. That language will be No. One in that project because that’s how you would do it. So I kind of look at these like, cool. It’s kind of good to know if these projects are still seeing contributions. Is the maintainer ship pretty healthy? Is the governing body, is that healthy? What’s the roadmap look like? Is there a great feedback loop with their ecosystems, how the projects written in those languages thriving? Right. Are those projects still seeing adoption or people using them? I think when it comes to go, go is it’s one of those languages that gets boring really quick, which is why I like it. You know, you will complain about going to oh, it doesn’t have these twenty seven things. And the other language I was using that I don’t want to use anymore because it has too many things. So then you come over to g…
Full show notes at the publisher 
Our TOPPODCAST Picks 
Stay Connected
