SE Radio 471: Jason Meller on Choosing the Right Tech Stack for a Greenfield Project

Jason Meller, CEO and CTO of Kolide, discusses the strategies and heuristics for finding a tech stack for your next startup or project. Host Adam Conrad spoke with Meller on the basics of modern tech stacks, understanding trade-offs for these stacks as well as use cases for each choice, and then took a deep dive into the world’s most popular programming languages and the best applications of their frameworks for greenfield projects.

This episode sponsored by NetApp and Conf42.

Show Notes

Transcript

Transcript brought to you by IEEE Software
This transcript was automatically generated. To suggest improvements in the text, please contact [email protected].

SE Radio 00:00:00 This is software engineering radio, the podcast for professional developers on the [email protected]. Se radio is brought to you by the computer society. I sure believe software magazine online at computer.org/software. I see radio listeners. We want to hear from you. Please visit sc-radio.net/survey. To share a little information about your professional interests and listening habits. It takes less than two minutes to help us continue to make se radio even better. Responses to the survey are completely confidential. That’s S e-radio.net/survey. Thanks for your support of the show. We look forward to hearing from you soon.

Adam Conrad 00:00:51 I’m Adam Conrad, and this is software engineering radio. Today. We’re talking with Jason Miller. Jason is the CEO and founder of collide. Jason has dedicated his career to building products and tools that enable security experts to successfully defend Western interests from sophisticated and organized global cyber threats. Jason, thank you for coming on software engineering radio today.

Jason Meller 00:01:12 Oh, thanks

Adam Conrad 00:01:12 For having me. I’m really excited to talk about this today because there are so many tech stacks out there for people to build their applications with. I only have experience in some of them, but I’m really excited to see how one thinks about building a tech stack for a new Greenfield project. So to start at a very high level, what is a tech stack specifically? The stack part?

Jason Meller 00:01:31 Yeah. So the way that I think about it is I think a tech stack is really a series of foundational technologies. So you’re talking about frameworks, languages services, and together they should be best suited towards achieving a specific software engineering goal. You know, obviously business schools are important there, but it’s really about specific software engineering goals and requirements. And those are the components that really make the decision tree for choosing a Czech stack, our tech stack really important.

Adam Conrad 00:01:59 And why don’t the business goals play into that? That’s actually interesting. I’ve never heard that particular line of reasoning before

Jason Meller 00:02:04 ’cause business goals should really be divorced from specific technology choices. And I have to deal with this all the time because I’m sort of dual hatting in my startup as the CEO and CTO. So it’s really important that I don’t conflate a business school, which is, you know, I want to build a specific type of product that has these specific features that meets these specific use cases, and then try to use that foundational set of requirements to then move forward towards directly to technologies. We want to really take that and take a separate step and actually define specific software engineering, architecture, and requirements that should inform the tech stack decision-making. So you don’t want to just jump from one thing to another, if you’re really experienced and you have a very small team, that’s often what happens and that’s fine if you’re making really good decisions, but often if you skip that step, you’re actually losing some fidelity in what you’re actually trying to accomplish. And you really should start thinking about software engineering goals specifically, as they relate to technologies, you know, software is a means to an end and at the end of the day, software may not necessarily be the solution to a specific business goal. And so you have to kind of just take that extra step and really understand is software engineering even required for this business goal. And if it is that’s when you want to start thinking about a technology stack, that’s complimentary,

Adam Conrad 00:03:22 That’s really interesting. So you’re still saying that it informs the decision, right? So for example, if the CEO of the company says, well, I want a recommendation engine, or I want recommendations for the customer. That’s implicitly saying, oh, you might want to think about Python because recommendation implies artificial intelligence and the pythons are really good tech stack or language for, for AI develop.

Jason Meller 00:03:46 I think that’s a really great example though, because the way that I think about that as a CEO is you stated it perfectly, you know, we want to provide recommendations for our customers for X, Y, and Z. Well, depending on the scale and how many customers you have, you may not need any software engineering for that. You may just need some people to actually go and manually curate those recommendations and then email them to prospective clients and existing customers. So really when we have the software engineering goal would be there, okay, we need to achieve that goal, that business requirement for this scale and these other additional more technological requirements that are sort of embedded in that. So I think it’s really important that you tease that out because oftentimes a lot of the high level goals that you have at very early stages in your organization don’t necessarily require software engineers to actually go in, start typing code into a code editor. You can actually solve them and actually test the merit of the business idea before you’ve invested a lot of time and money into actually writing software against it, which is the most expensive part of the process.

Adam Conrad 00:04:45 Yeah. I’m thinking back to what if the startups I used to work at many years ago, the way that he started their application was a WordPress site. So because without was going to say was technology right now is sort of embedded into every company. So I think it’s probably, I don’t think you’re saying that you don’t use technology at all. It’s just that what facets of your business are actually using technology, I think is kind of the, the right thing. You’re sort of striving towards here. And I think back to, like I said, I was at a startup where their very first iteration of their business was a WordPress site and a series of Craigslist ads. So they were leveraging technology, but they didn’t use the software engineering piece of that for businesses that you’re talking with or, or your friends that are starting companies. What areas do you think require software engineering from day one? And what areas do you think you can leverage existing software solutions?

Jason Meller 00:05:35 Yeah, so I would encourage founders that are out there that really want to test the validity of an idea, right? Because that’s how most startups start. You, you have an idea and you really want to test the validity of that idea in a market. You want to test whether or not people are willing to pay for that. Now a poor way of doing that is to just ask people and what you’ll find when you do that is people aren’t necessarily honest. You know, they don’t want to insult you. And they’ll sort of say at a high level, yeah. Maybe I would use that, but when it really comes down to it, would they actually open up their wallet and pay the money? That’s a completely different level of feedback. So you want to get that level of feedback. So the first thing that you really need to think about is how can I test the theory, actually get people to pay money to me for providing a service or some kind of benefit.

Jason Meller 00:06:20 And how can I do that in a way that requires the least amount of software engineering, and the reason why you want the least amount of software engineering is can you test the validity of the idea before you need to raise capital or you need to invest your own time and your own capital into actually writing code, which once you’ve written code. And now you have technology debt, you have bugs, you have infrastructure, you have a lot of decisions that we’re going to be talking about in this podcast. But if you can avoid the majority of that and still test your idea, then once that idea is vetted, you’re going to know a lot more about it. And you’re going to actually be able to pick a better tech stack when it is time to automate that business opportunity. Okay.

Adam Conrad 00:06:55 So let’s assume that we know there’s going to be at least one developer, maybe it’s yourself who has to make that investment. And what comes with that investment right out the gate is I have to store this data somewhere. So I’m probably paying for a database server and the application itself needs to be stored somewhere. Maybe it’s a downloadable application or it’s a web application. So we at least know one person and one tech stack has required to accomplish our mission. First question I have for you is how do you know whether to build it yourself or buy it? So a common example of this is dev ops infrastructure. It’s very easy to spin something up now in AWS with Beanstock elastic Beanstalk, or you could actually just buy the whole system with Heroku or some service like that. So for the very beginning, you know, you have one stack, how would you go about making that decision on build versus buy?

Jason Meller 00:07:43 So let’s review the scenario that you just gave me. I think that when you are a, if you’re a person, you know, it’s just, you, you have your idea and you have enough software engineering knowledge, and it doesn’t necessarily mean, you know, definitively that you can build the whole thing, but you’re willing to bet on yourself to actually build it out. Then the thing that you want to do is you want to optimize where you’re actually, you know, filling your own knowledge gaps with services that are already structured. So, so for me personally, I’m a Ruby on rails engineer. I know how to build web apps, like, you know, like the back of my hand, but the part where I always struggle with is really getting into the weeds in terms of the persistence layer. Like, how am I going to make sure that I’m running PostGrest with the, uh, you know, the right modifications?

Jason Meller 00:08:28 How am I going to backup Postgres? I’m going to make sure that it’s, you know, has high availability having to do all these things. And that’s a series of knowledge and capability that I don’t necessarily want to slow down and have to learn in order to get my idea out there. Well, that’s a perfect example where you might want to reach for a managed service like Heroku has managed, uh, Postgres. And it’s a great option for folks who really just want that problem solve for them so they can focus on the business logic of their actual application. Now, if you are someone who actually has the opposite scenario, where you are really passionate about, you know, you’re an SRE, you’re really passionate about operations, but you don’t know much about building web apps. That’s when you might want to reach for a consultancy and then have them really kind of help you choose the right foundational technologies to base that on.

Jason Meller 00:09:14 But when you’re at this early stage and you really have meager resources to work with the actual technology choices that you make today are really going to be ones that should be optimized, or how much can you participate in the process directly? And if you can’t participate in the process directly, who are the folks that you can get access to and what is their skills and expertise actually look like? And then you should really optimize the tech stack to their experience because that’s going to maximize their chances of helping you. And I think a lot of engineers and a lot of founders fret a lot over the tech stack. There’s a lot of anxiety when choosing tech stacks, because that’s really going to determine the quality of life or the day-to-day for that engineer. No, whatever language is being chosen, the framework and the maturity of the framework, the maturity of his API is how good is the documentation. But at the end of the day, if we’re talking about really small teams and shoestring budgets, we really want to optimize for how much of this work can you actually do yourself and invest your own time versus having to raise capital and pay a lot of money so that you can support technologies that you don’t necessarily understand,

Adam Conrad 00:10:17 Right. So first do complimentary skillsets. So if you’re not a DevOps person, let Heroku handle the DevOps for you. So you can focus on the application layer, which brings me to my next point. You’re talking about layers here, the persistence layer, the application layer, or even, you know, other layers like the mobile layer. So what are the common layers of a tech stack that you consider when you’re thinking about technologies?

Jason Meller 00:10:38 Yeah, so data persistence is a huge one, and I think that’s where you can get a mixture of technologies. Obviously lately Postgres has just been killing it in terms of actual relational database. And they’re really good at now document database storage. So that’s a fine choice for, I think a lot of early stage projects where there’s a lot of potential consternation around. Okay. You know, we might have a lot of events and we have a lot of things going in. Are we going to need something like elastic or are we going to need other document storage mechanisms? I think Postgres has proven that you can actually be multifaceted technology and actually do each one of those components relatively well. So I think that’s a great choice. And then red is, is a, is another obvious choice for people who just want really fast reads, writes, and, you know, hot store tree, either event queuing and things like that.

Jason Meller 00:11:23 I think red, this is a fine choice for both of those things. So the majority of projects that I’m working on, those are usually the two foundational technologies that I’m choosing for data persistence, but there’s data processing, there’s API slash business logic. There’s the user interface. And if we’re talking about a web application that might also have native apps as well, you know, that can live in multiple areas, then you have infrastructure which can be considered hosting or operations dev ops. And then finally you have just the generic structure of how the stack works. Know, is there, are we looking at microservices? Are we going to need to be able to bring in some sort of containerization or Kubernetes, or can we go with a more majestic model of the approach? We’re pretty much everything is in the same exact code base. We don’t really have to worry about how these things, how these different components communicate with each other, because we’re just using one language and everything’s sort of globally available to us. And so those are all components. I think that make up a tech stack, a common tech stack, at least

Adam Conrad 00:12:18 At this, that there is like a decision tree that you use to evaluate, oh, if thinking about web choose possibly a monolith, you’re thinking about some sort of view layer that might be on mobile as well to consider native mobile applications at a very high level. What kind of decisions are you making for approaching technology?

Jason Meller 00:12:38 Yeah, so I think you have to think about the customer experience that you are really going for and work backwards. Like for instance, at collide, we knew that we were going to have a major slack app component to what we were building. And so it was really important to us that whatever technologies we chose at the hood, and they had a lot of maturity in interacting with the slack SDK. We don’t have any requirements for building a native app on either Mac S or things like that, or on iOS or Android. So it wasn’t really important for us to, you know, either garner a lot of experience in Java or objective C or swift. And if we needed to go that route, you know, we had some JavaScript experience so that we can leverage react data for the ionic framework. Instead in terms of the web application, we wanted to really think through, alright, how can we enable our engineers to build features all the way from backend to front end with relatively little front end experience, because we didn’t want to necessarily shell out for a large army of front end engineers that were really going to wait for these bespoke APIs to be built.

Jason Meller 00:13:45 So we really, uh, focused on server-side template rendering, which is a different choice than I think a lot of folks are making lately when they’re really thinking about building, you know, these cordoned off API APIs and then sending all that stuff to something like react. We chose a completely different route because it was really important for us to allow our three or four engineers that were working on the product to feel enabled, to actually build a feature from all the way from conception to the front end and actually get it out the door without having to pull in three or four different people that had a specialization in a particular area. So those are all things that, that really tied into the tech stack decisions that we made at collide, which are really optimized towards small teams, empowering our engineers to be as full stack as they possibly could.

Jason Meller 00:14:28 And if there are large gaps in our knowledge, we actually are using Heroku so that we don’t have to spend a lot of our time discussing, you know, operations in general. You know, we’re just trusting that Heroku is doing the right thing for us. And in general, they are now one thing that I think a lot of engineers Fred about and CTO’s as well is what is the customer impact going to be about these decisions? How much do customers really care about backend architecture and tech stacks? And this came up a lot when we were discussing what frameworks and choices that we wanted to make, especially on the operations side, really worried that, oh, if we couldn’t get this level of customer data segregation that we wanted, you know, people were going to really kind of, you know, be upset by that and that could impact sales.

Jason Meller 00:15:09 And the reality is that even for our security startup, where I think we have the most scrutiny out of the majority of SAS companies that are out there, there’s not a lot of scrutiny into a lot of those in the weeds decisions around data tenancy and how much of the operations are we actually handling? In fact, I think a lot of our customers felt at ease with the fact that we had offloaded that tool, existing organizations that have already passed their SOC two, they’ve already passed a variety of different compliance, uh, you know, achievements. And I think that at the end of the day, that’s actually what puts them at ease. That there’s a lot, that’s easy to predict about our stack and they don’t have to feel like they have to evaluate a lot of custom engineering, a lot of custom components that you might feel compelled to build

Adam Conrad 00:15:53 Probably the same decision that CEOs make too. Right. So it’s like the CEO cares about the recommendation engine. They don’t care about Python. Similarly, the customer cares about does this app work? Is it fast? And is it secure? And so then the text decision very much based on the solution you choose that enables high performance or high availability or high security, there are security plugins that are baked in to the application stack. So for example, you might want to choose rails because there are plenty of plugins out that the handle off for you. So you don’t have to build it yourself, which is a pretty common tenant for security. As you know, don’t roll your own off. I actually want to touch more on the team piece. I noticed that when you were talking about choosing technologies, a lot of it was focused around for you enabling small teams to work in the full stack experience, but how much do you also weigh into the tech stack in terms of right tool for the right job?

Adam Conrad 00:16:45 So for example, it’s really easy to choose JavaScript because it’s sort of like a one trick pony for a lot of things. However, there are some good reasons to use JavaScript on the back end for your particular use case. Like the slack example, I would think that a working with the slack API would involve a lot of events. So event based programming is probably a good tech stack for that. So regardless of your team makeup, choosing something like node, which is very much event based would be good. Also Earl Lang or elixir are very much event based. So how do you weigh in right tool for the right job while also weighing in the sort of team layout of how your team’s going to be set up?

Jason Meller 00:17:24 So I think in terms of prioritizing those, you want to optimize over team productivity and empowerment over anything else, because I think a lot of engineers in CTOs, they sit down and they try to dispassionately, you know, make these choices. Like it’s a scientific exercise where, you know, they’re not bringing in their own personal biases and we’re looking at the software engineering requirements and we’re going to make a very rational decision based objective on these requirements. But in practice that never happens. There’s so much bias from either previous experience with these technologies or actual desires that you end up making these arguments that are really at, if you distilled them down almost psychologically, they’re really you just advocating for the thing that you feel the most comfortable with. And so at collide, we try to shortcut a lot of that. And, you know, there’s engineers that, you know, are going to be the powerhouses in your organization.

Jason Meller 00:18:21 They’re going to be the ones that in essence are building the majority of the application and what you don’t want to do. And then there’s types of engineers that are really good at recognizing when those engineers are, you know, going off the rails, maybe they’re doing something that’s not going to scale, or they need to, you know, inject some computer science knowledge into the situation so that, you know, you’re building something with, uh, an efficient algorithm, those, those types of engineers as well, but I’ve always found that the powerhouse engineers you’re going to enable them to be so much more productive if you just choose the technologies that they’re most familiar with before you even get into, I think a lot of the software engineering goals when you have that latitude and that’s an important caveat, a good example of this when you don’t have that latitudes, when you’re looking at building software for platforms that just have a lingua franca, like I think a good example of this is iOS.

Jason Meller 00:19:12 Sure. There’s ionic, you know, there’s, you know, react native. There’s a bunch of ways that you can leverage existing JavaScript skillsets to build a pretty good iOS application. But if your main goal and what is special about your organization requires the best possible iOS app out there. You need to build it in objective C or swift or swift UI. Like that’s just, that’s just how the platform is designed. Like you’re going to get the best performance. You’re going to have access to the most native API APIs. Like you just need to choose those technologies and you don’t have that level of latitude there, if that’s what the core of your businesses, which is an iOS application, if that’s what your decision is. But if that isn’t the core of your business and you just need like a reader app, that’s when you can really start optimizing for the experience of the team and then start choosing some of those JavaScript frameworks and technologies that allow you to arrive at a pretty good application.

Jason Meller 00:20:02 And then over time, what’s nice about some of these decisions is that when those things become more important, you can start looking to hire an iOS engineer who can then start transforming some of these web view based screens and actually upgrading them into full native experiences. And you can do that piecemeal when it’s appropriate for your business. But I think a lot of engineers don’t take into their own skill set into account because they want to choose the best technologies for the best outcome. But the best outcome is the software actually gets written in a timely manner, you know, under our ad budget, you know, and it’s something that actually ends up working. And so if you choose the right technologies to produce the best outcome in theory, but in practice, it doesn’t get done on time. Or there’s a lot of bugs. Cause you’re inexperienced that technology, then you haven’t chosen the best option.

Jason Meller 00:20:50 So my advice to everybody out there is try to figure out, okay, we know at a high it’s team that you’ve worked with before, it’s going to be this selection of people that are going to be the most productive and let’s optimize for them to just get the code out the door, using the things that they’re most comfortable with. And then if you’re the type of person that can augment them, it’s likely that you’re going to be able to learn whatever language primitives are necessary for you to be able to apply your computer science knowledge, to make sure that their code is going to work at scale.

Adam Conrad 00:21:19 I did that make sense for the no-brainer tech stacks, like you mentioned with iOS, there’s sort of two follow up questions that I’m very curious about and we can tackle them one at a time, but it’s a high level. One is what if you’re a web developer and it’s you and your friend are co-founders and you realize that the solution is an iOS app and neither of you have iOS experience to your earlier point, you would probably hire a consulting firm, but you’re also both developers. So do you just kind of suck it up and try iOS? Or do you go well, we know JavaScript, so we’re going to try react native until we’re out of our league. How do you kind of approach that one, whether there’s sort of a tech mismatch, but you both fundamentally believe in the private,

Jason Meller 00:21:54 I think at that stage when you’re, it’s more of a proving ground, I think that it’s okay for you to have a sub optimal decision. I think if you’re two co-founders and you know how to code both of you, it would be, I think, foolish for you to choose a technology stack that you’re going to have to learn on the fly while you’re trying to test your idea. Even if that technology stack is the most optimal for building on that platform. And I think iOS, I mentioned you may not have that latitude there, but the reality is is that you may not have the latitude of time to actually learn the technology stack on the fly like that. Now, a lot of these languages and frameworks like swift is great. Like if you already can code in JavaScript, it’s likely you can pick up swept relatively well in fast.

Jason Meller 00:22:38 But the problem is is that you don’t really have time. Like there’s different levels of competency when you’re coding and you need to be able to get in the flow really fast when you’re building an entirely new idea, you need to be able to just get out of the mindset of every time that you need to do something. You’re trying to translate your old JavaScript knowledge into what is the language equivalent of this and swift, what is the best practice of this and swift and ends up disrupting that flow. And if you can get flow a lot faster, and it’s just the two of you and you need to prove out an idea having like 30 or 40 milliseconds, extra of latency on interactions, isn’t going to make or break, you know, your idea of success. You are going to create tech debt down the road, but that’s okay. You are going to create it anyway. Even if you knew swift, like you just, you don’t know what lies ahead of you in terms of how the product is going to change based on the initial feedback, what scalability you need to change. And so it’s really important that you get your idea out there and not worry about, I think a lot of micro optimizations that are going to be necessary way later in the business after the product is already somewhat successful.

Adam Conrad 00:23:42 Yeah. And if it’s you and a co-founder friend, and it’s a side project, you’re excited about learning swift and you already have some JavaScript experience, I think, yeah, it totally makes sense to go, okay, we’re willing to take this leap of faith. It’s probably the right move anyway. And it’s not as high of a barrier of entry is probably objective C and we’re willing to invest in that. But like you said, if it’s a critical business where you’ve just both quit your jobs and you really want to get this out the door. Yeah. Maybe it’s okay to make a suboptimal decision because pre optimization, as they say is the root of all evil. So it’s not, it’s a no good to pre optimize if your business is going to fall flat. Now, the other question I had was sort of more about a more established team.

Adam Conrad 00:24:17 And this is, I’ve seen this happen a couple of times before is I have like your reasoning behind choosing to optimize around team productivity, though. It might seem a little shortsighted because you have to hire folks. And if you hire folks, you have to look at a much longer term hiring path. So I think that also makes a decision there too, because what I’ve seen in this happens a couple of times is you’ve got a team who is all knowing gender really well. And they optimize around a technology that works, but it’s probably not, like you said, the lingua franca, the example of this would be using closure for the web or Haskell like Haskell has the Assad closure has luminous for web frameworks. You probably use functional programming languages, specifically Haskell, probably more in the pure math R and D world, but you’ve got a bunch of folks who just know Haskell really well, but then you have to hire folks to teach them Haskell. And you probably got be hyper performing team that writes the least amount of code, because that’s kind of how these functional languages work, but then your challenges while we all know this. So of course we’re going to choose Haskell, but what if you have to hire 10 more people in the next year? So how does that factor into evolving that team beyond what you have right now today?

Jason Meller 00:25:24 Uh, I think there’s a lot of anxiety about this one picking tech stacks, because I do think people try to choose check tech stacks that are really going to allow them a large selection of individuals, juniors, seniors, and, you know, staff, engineers that you know, of all different types of experiences. But I think that the fears around that are a little bit overblown. And what you find is that even if you pick a more obscure programming language, you don’t need thousands of people coming into your organization within a year. Like that’s pretty rare. Like Shopify is a good example of, you know, we need to do that because we’re growing at a huge pace and we need to get a lot of Ruby engineers and there’s just aren’t enough out there, but that’s a pretty, it’s a high class problem to have. If you look at some of the more obscure organizations that started off with like, I think a weird programming language, I think Reddit used lists as a good example of this early on in their Y Combinator days.

Jason Meller 00:26:20 And they originally were able to find a sufficient amount of engineers, even in something I think obscures lists for backend web engineering in order to meet that requirement. So I think that it’s going to change the pool of people that you have available to you, but oftentimes a lot of these popular languages and frameworks, you’re also competing against some of the largest, most well-funded organizations that are out there. You know, the things of the world that are looking for those same people and they’re willing to pay them 50% more in salary and benefits, then you’re going to be able to afford. And so if you go to the more obscure language that maybe isn’t in high demand, you might find some really passionate people that really love that language that are going to be very turnkey into your organization and all the different ways that you code today because they have the same stylistic preferences and they’re not their salary, isn’t obscene because you know, the Facebooks, the Googles of the world aren’t vying for those particular skillsets.

Adam Conrad 00:27:18 Right. So even though there’s probably more security tools around PHP and Laravel, if you chose something like closure script and the closure stack, you just might people who see the job description for closure and go, oh wow. I can actually get the work enclosure full-time I would be willing to take a salary cut if it meant that I got to develop in the tool set that I really like. So that’s an interesting trade-off would you trade a more robust, you know, say security framework or not having to roll your own off versus a stack where, you know, you can hire folks.

Jason Meller 00:27:51 Yes, absolutely. I think, well, I think that the men, I think it would be challenging to pick a stack today where you had no ability to hire anyone. Like, I think that there’s enough diversity out there, and this is something that I think people are trying to change about the web, which I’m not a big fan of. Like, I think one of the best parts about the web is that we can choose whatever language we want to build the backend and the, you know, the end-users really have no idea. As long as the HTML is served, served in an efficient manner. And my browser can render it. Of course, JavaScript has to be used on the front end, but I reject the notion that we want this monolithic language, just like we have with iOS, with swift and objective C on the web like that to me, I think is reducing the diversity of choice that’s out there.

Jason Meller 00:28:36 And I think that you’re going to see a lot of people who are really passionate about the languages they use just exit the job market, because they don’t necessarily want to code in JavaScript all day. I certainly am not a giant fan of JavaScript, but it’s something that I felt I had to learn in order to, uh, you know, build at least a competent front end for a web application. But if I’m going to choose a backend, I want to choose something that I’m going to get some level of enjoyment out everyday, and I can find others around me that that feel the same way. So I wouldn’t necessarily say that there are choices out there. I mean, I’m sure there are like, no one’s going to code. They’re like, you’re not going to get a lot of cobalt developers that are great. I web development, like that’s just not going to happen.

Jason Meller 00:29:14 But the reality is, is I think for the majority of choices out there, if you’ve in the past, been able to write a web app for that particular language, using that particular language, then I think that you’ll be in a position where you’re gonna be able hire people and it might be different types of people. They might come from different geographic locations. They might look different than you, but they’re going to be people nevertheless, that are willing to roll up their sleeves and help you. So I think you can optimize for both. I think you can optimize for a language that you’re comfortable with that has a degree of maturity around it. And it’s going to be suited towards the skillset of the current engineers. You will have a hiring pool guaranteed. It might take you a little bit longer. You might have to reach a little bit farther, but they’re out there, especially if you’re willing to embrace remote work.

Adam Conrad 00:29:54 Yeah. And honestly you could probably get away with not writing JavaScript at all because a lot of these languages have compiled to JavaScript. So you can still fundamentally write in that language without actually ever having to touch raw JavaScript yourself. So there’s still that benefit there to what other sort of, before we move on to the sort of the common tech stacks, what other heuristics do you look for that maybe we haven’t talked about so far in terms of evaluating criteria for choosing the right tech stack?

Jason Meller 00:30:17 Yeah. I think one thing that is okay to do, I mean, this is a correlation, not necessarily causal, but you should look at, you know, the top companies that are out there that you admire that are in your field and look at the tech stacks that they’ve been successful with. I think for a variety of reasons, one is they’ve proven that they can reach this incredible level of success with the tech stack. And that has proven that there isn’t just this giant limiter upstream, that’s going to prevent you from reaching this incredible goal that you, that you have in mind. So I think that’s important. And number two is they’ve probably invented a lot of libraries and frameworks that are going to be important for you as you build out either a competing solution or a complimentary solution in that field. So I would definitely take a look at it.

Jason Meller 00:31:00 I mean, a good example of this was I read an article by someone who follows the Y Combinator companies. I think they wrote it in like 2019, or maybe early 20, 20 and of the top 50. Why common or you add up their valuations in 2019? I think it was something like 175 or $176 billion in total valuation. And if you look at that over half 92 billion of it is from companies that said that they have one primary backend language and that language was Ruby. And I think that if you look at those startups and you look at Coinbase and you look at Stripe and you look at Airbnb and you see a lot of complimentary goals that you have, like maybe you want to build a killer API for, you know, helping ship products. Like you want to build the Stripe for ups and FedEx and DHL.

Jason Meller 00:31:47 Like you have the ability, maybe Ruby wouldn’t be a great programming language just there because Stripe has built such a great foundational set of libraries for building incredible API. Or maybe if you’re doing something in crypto or blockchain, Coinbase is proven out that you can build a significant portion of that in Ruby, obviously they’re using C plus plus as well and a number of other technologies, but in terms of the user experience and the majority of the application that customers actually see, a lot of that is in Ruby and it’s scaling. And I think since this article was written like the evaluations of the companies that I just mentioned is probably tripled. And so it’s a good example of it’s okay to look at who’s being successful. When I think the counter argument to that is all right, is that really a function of their success or is that really a function of when they were founded?

Jason Meller 00:32:31 Because Stripe was, I think founded in like 2010, that was when rails was really at its apex in terms of popularity. But I think Coinbase based is a good counter example of that. You know, they were founded much earlier. They still chose, I think a technology back then that a lot of people would have dismissed as you know, um, in their fall or winter in terms of the maturity level. And they’re going to be fading out soon and they’ve been able to revitalize it. So I think you can impact your own reality, especially if you end up being a really successful hyper-growth organization.

SE Radio 00:33:01 Today’s sponsor is spot by app, the cloud automation platform that makes it easy to deliver continuously optimized infrastructure at the lowest possible cost to get the most out of your cloud investments by automating cloud infrastructure, to ensure performance, reduce complexity and optimize costs there, machine learning and automation scale to exactly meet application needs using the most efficient mix of instances and pricing models, eliminating the risks of over provisioning and cloud waste, leverage spot with all leading cloud platform services and tools, check them out at spot.io/se radio, where you can find more information, request a demo, or even start a free trial.

Adam Conrad 00:33:40 So I’m looking at TOB, which is the software quality company they release every year, the top programming languages for each year. So what I want to do is actually want to look through from the highest to lowest. Again, I just based this solely on the TOB rankings, which is a lot, a lot of people use, I think stack overflow uses the same rankings roughly when they do their developer survey every year. And they just look at what are the most in-demand languages for software developers. So I kind of want to just go through the most popular ones and look at the tech stacks for those languages and just kind of get your opinion based on the heuristics. You’ve talked about how you would think about using these languages when building these software Greenfield projects. So, you know, from the very beginning, we’re looking at JavaScript, Java and Python. So starting with JavaScript, what are you looking at there in terms of tech stack? Yeah,

Jason Meller 00:34:25 Obviously a JavaScript is well-suited towards the web. I mean, it was a foundational web technology ECMAScript and I think that you’re going to want to choose JavaScript if you’re building, I think a rich client side application. And when I think about rich client side applications, I don’t mean the settings page of a SAS, right? Like that’s not something that really requires this level of reactivity where you need to pull in, you know, something like components and the react framework in general. Like I think of a companies like medium, where they spent like the, the core of their business is a Wiziwig editor and it has to be perfect. It has to not have a single issue. Has if you type a character and there’s even a little bit of latency, the user experience is broken, it’s dead. And I think that when the stakes are that high that’s when you want to reach for some of these incredibly performant, you know, front end frameworks like react now when it comes to TypeScript.

Jason Meller 00:35:21 I think that the really interesting thing about TypeScript in the web in general is that everything over HDP is like, it’s all strings. And then you do a lot of conversion of data into types. And I’ve always felt like, I, at least personally, for me, when I’m using technologies like TypeScript, I feel like I’m constantly fighting these implicit conversions because everything I’m getting over is essentially text like over the wire. And so I have a lot of work where I’m doing a lot of conversion there and then I don’t necessarily care about the type of this particular thing in the side of this Jason object. It’s like, I find myself when I’m writing TypeScript. Like I’m really glad that I have all these great IDE recommendations that I maybe I’m writing the wrong thing, or I’m assuming a nail when I know when I think I should have something there, but ultimately I feel like I’m constantly fighting the lack of standardization of the data that I’m getting over the wire when it comes to TypeScript versus what I really need typing. Like if I’m using something like go or I’m writing in swift, like that’s when types feel really helpful and useful when I’m really plugging into operating system APIs that have strong types already associated with them, because that’s how they were built.

Adam Conrad 00:36:28 You know, you bring up an interesting point about the application types. You know, the one I was thinking of that I thought you were going to go with was like dashboards. So companies like Salesforce blog, rocket heap, you know, the sort of like logging and analytics tools where you actually see dashboards in real time with graphics or D three, four, something like that. That’s where I would figure something like JavaScript is super useful because these languages and these frameworks like react or angular or view, they’re all very front end focused and clients focused, like you said, but they also have extensions for things like . So you can get rich visualizations in real time, but that sort of client feature rich updates that make it very compelling to focus on the front end. I actually didn’t consider that medium example. I think that’s a really good example of something that I would have never conventionally thought is very front and focused. But like you said, you should be able to click into the letter J and it instantly shows up in your editor without any sort of issues. And if you’re doing type, you know, I was about to say type tracking, but spell checking in the editor. You want to be able to see that it actually finds this spelling error immediately, right? Like you said, the DUI should be extremely responsive down to the millisecond. So that’s a good use case for that. That totally makes sense. Now,

Jason Meller 00:37:40 Another use case that I’ll bring up just to close this out a little bit is network latency. Cause I think a lot of people discount this when you are trying to ship products that aren’t necessarily where your customer base isn’t going to be necessarily in the continental us latency becomes a real issue. You know, people are farther away than CDNs than you might assume. And then the ability for you to really do that server roundtrip when they clicked, you know, the options dropped down in the settings menu. If it’s going to take now 500 milliseconds or a full second to do that, that is not going to be acceptable probably. And then you might want to reach for more of a client side JavaScript approach because you can offload a lot of that work in developing countries where just the network connectivity, isn’t going to be where it’s at.

Jason Meller 00:38:24 But what’s so funny is the opposite is true. Is once you start getting in over to Android, you really need to think about building Android apps, more natively using Java. And the why is Android JavaScript engine isn’t as good as iOS. So once you start loading everything in JavaScript in Chrome’s web browser, on Android or whatever web browser you choose, you’re just going to have a really subpar experience because VA does great on the desktop, but it’s not so great compared to what apple is doing with their built-in, you know, Silicon, like they just have a much better performance story there, and it may not be the right technology to choose. If you are really want to build a web app, that’s going to be primarily used on Android devices. You might want to go native.

Adam Conrad 00:39:09 So are you then anti node, if you wanted to go JavaScript the whole way through, it sounds like. Well, I think we talked about this earlier event based programming is probably a good use case for node, but it sounds like to you, if it’s very client heavy stick with the front end technologies for JavaScript, but are you saying don’t go JavaScript full bar down to the node layer?

Jason Meller 00:39:27 Yeah, I think if you have, unless you have teams that are super experienced in node, I would avoid it. I think there’s a lot better modern choices for event based programming today. We were making fun of it earlier around slack and like, we actually built all of our venting and rails and Ruby for all our slack events and we just have asynchronous processing and we have, it’s incredibly, uh, against like, I think the norms of the language, like there’s a vent machine in Ruby that allows you to some degree in venting, but like Ruby doesn’t really have really good parallel processing and things like that. It’s just missing these core features in the language that make it possible. I mean, it has a concept of threads, but they’re green threads and then know you have the global interpreter lock and all these other things that really just prevent you from really getting that multi-core performance maybe that you want to do.

Jason Meller 00:40:11 But in some ways when you have, uh, I think a lot of people abuse, those features like, you know, and go, it’s really easy to start reaching for threads. And I think a lot of parallelization of, of tasks. And then you end up with, I think a lot of timing issues and then something that maybe didn’t really need that level of optimization now has a lot of bugs in it that are really hard to tease out. And when it comes to something as simple as, you know, we need to receive some events like when someone changes their, like a web hook from Stripe or in essence, that’s what we’re getting from slack. This is pretty easy to process and we can do process-based parallelization on the Ruby side. And I don’t even have to think about it. And I don’t have to think about multithreading and like all these weird, you know, side effects from setting instance variables.

Jason Meller 00:40:51 Like I just don’t have to think about it. Like compute is really cheap. Like just if you can get away with paralyzing things, which is pure compute and spinning up 80 Ruby processes, it’s not going to be that expensive compared to the actual true costs, which are going to be really related to the people that are building it at least at first. And I think Shopify is a really great example of, you know, if they switched to a different technology stack, would they be saving a lot of money on the compute side? And I, I think that they did the exercise and the answer was maybe a little bit, but it would be such a huge, the switching cost would be so massive for them that it was nowhere near worth.

Adam Conrad 00:41:27 So I think you’ve pretty much sold people on Ruby. Cause you said you guys use it yourselves at collide. And then obviously a little bit at 92% of the value that was extracted from the Y Combinator companies, evaluations was around Ruby on rails. Is that right? Something like that.

Jason Meller 00:41:41 He was 92 billion out of 176 billion. So I got a 52% or so. Yeah.

Adam Conrad 00:41:46 So we know Ruby and rails rails is pretty much the big one for web there’s also Sinatra, which I think is kind of more of the lightweight version of that. I think that the analogy for Python is Django is to rails. That Sinatra is to flask just briefly. Do you have any rubrics that you use for deciding whether you should do something it’s an entre versus rails on Ruby?

Jason Meller 00:42:05 I actually have a very strong opinion about this because I see engineers all the time say, you know what? We don’t really need all the bells and whistles of rails or Django or whatever the framework is. And we can go with like the, the light, like we just need to be able to open up some routes and you know, like express lets you do. And just to find some functions that are going to return some HTML, like that’s what we need. And we don’t need that. Like this heaviness that comes with the framework. And I don’t understand where that mentality really comes from because yes, there is a degree of heaviness in terms of how much memory you’re using as these processes run. But in general, you’re free to not call API APIs that you don’t need. And I think a lot of these frameworks are very modular and they allow you to extract out or import only the things that you really need from them.

Jason Meller 00:42:52 And oftentimes what starts off as like a Sinatra app or an express app sometimes needs to graduate to something way more powerful than that. And now you’re looking at a total rewrite and I think that if you’re already working with a team that’s familiar with the, I think the beef, your framework go with that because I think the performance characteristics between these frameworks for the same language end up being pretty close. And it’s not like you have this order of magnitude performance increase with going with the lighter weight framework. Usually it just means you have to learn a completely different API for doing the same things. And I think a lot of the performance gains that you think are there are actually not there in real-world use cases. So I would put those to the side, unless you truly know, and you see all the way out five years from now that you’re not going to need 99% of the features of like a January rails.

Jason Meller 00:43:41 Then maybe it makes sense for you to write something in Sinatra. But I just don’t see that use case actually happening in reality often enough. And I try to shut down those conversations because if we can fit it in the model with an RN, we’re going to do that because it just gives us so many synergistic advantages in terms of productivity of putting everything into majestic model of today versus having like as soon as we create a separate microservices thing, like that opens up this whole can of worms of, alright, now we need to think about the communication infrastructure. How are we going to now containerize this stuff? How are we going to orchestrate all these containers are deployed at the same time? How are we going to release? As soon as you add one micro service, all those questions become relevant and then they start taking away from the things that, you know, might be more important at the time, which is validating your product.

Adam Conrad 00:44:23 One thing I might add to your heuristics, which I think, I guess we just didn’t cover, which you’ve sort of brought up in this example is developer community. I think also adds to the decision tree here because I think in the Ruby community rails is pretty much the standard, but I’ve found actually that in Python, more teams tend to lean towards flask instead of Django for some reason. So even though flask is probably a closer analogy to Sinatra, I found that more teams seemed to pivot towards flask in the Python community, whereas in the Ruby community, they’re very much still focused on rails. So do you think that plays a part into it as well too, because I think probably if you talked to Python folks, they’d probably choose flask over Django in 2021.

Jason Meller 00:45:04 Yeah. I would agree with that. And that’s generally true. And I think that when you do choose a specific language, you want to look toward the companies that you admire and you want to emulate and go on the well-trodden path because there’s just so many advantages of being the little minnow that gets to swim next to the shark and gets, I think a lot of the resources that in most of these companies, they have massive open source initiatives and they’re all MIT licensed and you have a great opportunity to take advantage of a lot of that stuff. I mean, that’s a big reason why I feel so confident in our decisions that we’ve made for our tech stack is, you know, we have GitHub on our side. We have Shopify, we have a number of other organizations out there that are running at a scale that I’d love to get to one day at collide, but I certainly know it’s going to be awhile before we get there.

Jason Meller 00:45:51 But I know that when we get there, they’ve been able to stay. They’ve been able to generate the tools necessary to run their preferred framework and language at the scale that they need. And we’re already experiencing a wealth of resources and able to, I think, solve problems more efficiently, like a great example of this is GitHub released a multi database add on to the, you know, the version of rails that came out, I think last year where essentially they have now moved on to sharding their database because they need to, at this point, like they’re starting to get tables that have, you know, hundreds of millions of rows in them. And now they really need to start thinking about sharding or they need to start thinking about Reid replication and those are challenging issues solve. And you need to be able to solve them in a way that, you know, is going to scale up, you know, 10 X to where you are today.

Jason Meller 00:46:37 And you know, these are now making their way into the framework and they’re just options that you can set. And you just have the benefit of all of that experience. There’s a, I think a type of engineer that’s out there that really looks forward to solving those problems more manually. But I think that if you’re doing the right thing for your business, you’re trying to set yourself up so that the things that you’re really applying your computer science knowledge towards are the really the unique problems that your organization differentiates itself in its ability to solve. Like I think good hubs would be, you know, what are the ways that they can translate, get features into great project management and source code management features and opportunities. And I think for collide, like we should be focusing on how we can take end point telemetry and really elevate and make it easy to understand by security teams. We shouldn’t really be focusing on how are we going to really, you know, combine, you know, fragments from elastic, with data Postgres and how that all kind of plays together. Like that’s interesting work, but it’s not necessarily work that we should have to do if we can avoid it.

Adam Conrad 00:47:37 Yeah. And that makes sense though, you actually bring up an interesting point and we’ve kind of hopped around the TOB index quite a bit. Actually. I think I’m referring to the stack overflow release, which we’ll put this in the show notes. I’ll post both the TOB index and the stack overflow developer survey to list the most popular languages, but we’ve kind of hopped around a bit. I think JavaScript was the first and then Ruby is actually sixth on the list, but I’m going to tie it back to Java here because one actually last thing I’d like to ask about Ruby is choosing the sub languages. So you might choose Ruby on rails, but there’s actually a lot of different variants of Ruby. So I think the original Ruby is written in C, but there’s also J Ruby, which was written, uh, you know, Ruby’s written on top of the JVM, which would then relate back to Java and I guess Scala as well too. So how do you think about choosing that specifics of the tech stack? You know, when do you find benefit from choosing J Ruby versus Ruby?

Jason Meller 00:48:26 Yeah, I think you bring up a really good point and I think this applies specifically to Java and Jay Ruby as well is when, at first at collide, we weren’t using Heroku. We were using Kubernetes and we were, you know, creating Docker containers, deploying things out to Kubernetes. And the first thing that we ran into was there was just a lot of friction between the SRE team and the team that was building the product because the sizes of these containers became astronomical. Like Ruby just is not, it’s a compiled language. You have a lot of bundled independencies and the container size can just get out of control and Jay Ruby and just Java in general, when you have these jar files, they’re even bigger and suddenly you now have an arbitrary infrastructure choice really now applying pressure on the foundational choices that you’re making to build your product.

Jason Meller 00:49:20 And I think that that’s backwards and you really need to ensure that if Jay Ruby, you really want like some of the performance characteristics of Java, obviously startup performance, isn’t great. But once you’re actually running a warmed up job application, you’re going to see a lot more performance and ability to use parallelization. Like you have access to things that just aren’t available to you in the MRI version, like the referenceable imitation Ruby that’s the most popular, but what I find so interesting about this is that good hub actually started on Shay Ruby. They were a huge shaver Ruby shop until about 2009, 2010. And I think that the, the maturity of J Ruby, they started to see, I think they were just unable to overcome. I think a lot of the language bugs, and I think some of the performance characteristics of things that just weren’t thought through for J Ruby at that scale, and they actually had to revert back to MRI, Ruby, and then start solving the performance challenges directly by investing in that.

Jason Meller 00:50:18 And I’ll have to do a little bit more research to understand the specifics as to why, but I think that the advice here is that you shouldn’t let the infrastructure dependencies, I think the underlying languages that are going to be the core parts of the application. And that was an example where we were shying away inadvertently from Ruby J Ruby, the JVM in general, because we were worried about how big these containers were going to meet in terms of how we had to deploy them out there. And that was the wrong thing. But I think if you want some of the performance characteristics of Java, you want the parallelization and you don’t want the Gill, or, you know, the global interpreter lock. She Ruby’s a fine choice, but you’re going to find a lot of incompatibilities there. And you’re often going to be solving a lot of bugs where you’re not on the well-trodden path anymore, you know, just reaching for any arbitrary gem isn’t necessarily going to be the thing that wins.

Jason Meller 00:51:07 And I think it’s useful to look at the folks out there and look at the decisions that they made and say, okay, maybe we want to stay away from this because they know something that I don’t counterexample though, is Twitter, where if you believe them in the, the hard time that they had around Ruby and rails, you know, growing into that, you know, you saw the fail whale all the time or early 2009, 2010, that would indicate that Ruby was a terrible choice in that it just doesn’t scale. Uh, luckily we have some good examples of how that proves that it isn’t true, but I think that was a big wake up call, the folks who were looking to invest early on in their product. And they were really worried about, oh, if I’m successful, I’m not gonna be able to get there. But the last thing I’ll cover just in relation to this topic is the ability to scale down.

Jason Meller 00:51:50 I think a lot of people worry about scaling up and they’re going to miss their shot, their opportunity to, to be viral or to, you know, I think grow and this’ll be a huge limiter to their business, but oftentimes your idea, your product is going to do adequately or below expectations. And so how can you actually scale down the product in terms of how many people are needed to run it and engineer it so they can actually lower the cost of goods sold and your cash burn in general, to actually retool the product, find different things to work on so that it’s actually successful in the market. And I think that’s something that engineered teams should really think about if this isn’t successful, are we sending ourselves for this is our only shot, or are we in a position where we can scale this down and run it as a slow burn, which has a skeleton staff? And if the answer is no, then you better be sure that you’re right. I mean, you’re really reducing the amount of chances that you have to make

Adam Conrad 00:52:41 The successful business. That makes sense. And I know you focus pretty heavily on web, but as it stands, I, the other two big languages I would cover in sort of this top five index include Java and the.net framework, which I’ll include really mostly C sharp, but it, I guess it includes F sharp and sort of the whole asp.net ecosystem. So the fact is that still a lot of people are writing Java and C sharp. So when are the good use cases for those, because we can’t avoid that they are very popular languages, but maybe they’re not specifically suited for web or, you know, they might be suited for web because there are plenty of frameworks for both of them, asp.net, spring, hibernate grills. So, you know, we can’t ignore that. So what’s your take on the JVM, the dotnet frameworks.

Jason Meller 00:53:25 So I think that stack overflow is a great example of a product that has proven that you can build highly scalable, successful web application in the.net stack and the creators of stack overflow blogged a lot about this, because I think there’s a bias in maybe my age group and a little bit younger than me around picking I think more corporate technologies. But if you pick these corporate technologies, I think that you have number one is like Microsoft is incredible, uh, documentation. You know, every facet of that language has been documented ad nauseum, and you just have that wealth of information available to you. And it’s tied in so well with visual studio and vs code is a great example of them really extending a lot of their ability to build IDs competently to other language communities. So I’m really bullish on Microsoft’s ability to build, I think, a compelling developer experience there.

Jason Meller 00:54:21 And then there’s companies out there today that proven you can absolutely build a scalable web application in those languages. I think where I don’t want to reach for those languages. And this is relevant to us at collide is we also have an end point agent that we run on your device. And that’s primarily written in a combination of C, C plus plus, and objective C and windows is still very much mired in like we hear our IP APIs, they’re all accessible in C or C plus plus. And yes, we have like bridges to be able to call the stuff using.net. But ultimately if you really want the real deal, you really need to start, you need to just call this in the C function or something like that. And I think if you’re really trying to build something where you’re getting telemetry about a device, or do you want to really interact with a native system API, those are still the languages that I would choose over something more abstract.

Jason Meller 00:55:12 Python is another example of, of where you might want to reach instead of writing objective C there’s like PI objective C, where if you were more familiar with Python, you could kind of wrap a lot of the stuff in there. What I really like about go is Sego, where you can just sort of in comments, write various C functions and then call them with go. I think that’s awesome. It’s a great way to kind of mix that. And we have a little bit of go in our end point agent as well. And it’s great when I can just write some objective C or C plus plus, and, and then be able to then call that directly in a GoFundMe is really neat. And I think that you can start applying a lot of these different languages and experiences together, and a lot of languages really allow you to tap into the knowledge that you’ve invested before. And I think if you’re doing anything with native operating system APIs, as you want to reach for those native languages, instead of going through

Adam Conrad 00:56:00 Now, you mentioned Python as well too. And we can’t ignore that one because that’s another big one in the top three. Is it simple to say that Python is a great choice for web as well as sort of the data science AI? Because I also find that Python is very similar to Ruby in terms of how it’s laid out. It’s a scripting language is very similar. Is do you have any criteria in evaluating between Python and Ruby and the similar you could evaluate between JVM and.net?

Jason Meller 00:56:25 You nailed it, right? Data sciences and artificial intelligence. There has been no credible efforts made on the Ruby side, or I think like an equivalently friendly language that compete with TensorFlow and the various other APIs that are available in Python, like Python is the obvious choice. And I think that the breadth of skill and availability of freq data science, people that are familiar with that language, they’ve been taught it in university. I think Python is a great choice for that. If you’re looking for those types of skillsets, I think you have a long road ahead of you. If you wanted to really do some incredible stuff in Ruby with AI like this, just the libraries just aren’t there. I mean, we having to do a lot of original research and it’s unfortunate that Ruby wasn’t in a position where they could really attract that community right away, because I think it’s the language itself.

Jason Meller 00:57:15 It’s nothing about Python or Ruby in particular, make it well-versed for that. It’s just the people that were more academically interested in these concepts tended to focus on writing their software and Python, and then things really spun up from there. So I think if you really want a monolithic stack and you’re doing something with AI, then you have to choose Python. Otherwise, if you’re doing something on the Ruby side, you’re going to have a really hard time integrating those technologies. And then you’re going to start reaching for microservices. And then you’re going to have a lot of complexity that gets baked into your web application there. And I think that those are the main criteria that I’m thinking about when I’m choosing Python over something like Ruby, at least personally.

Adam Conrad 00:57:52 Yep. So now w wrapping this up here in terms of all the different technologies to choose, you did mention that there’s a couple of that are just canonical, like for sequel pretty much PostgreSQL is the big one. I know my cul can be sort of a competitor as well as SQL server. So I think it probably just depends on what your stack is. If you’re using, dotnet probably a lot easier to use SQL server that Postgres with mobile, right? It’s either old school is Java new schools, Collin, whereas for iOS at old school is objective C and new school is swift. And again, same thing with dev ops. It’s like you could either sort of build it yourself with AWS or Kubernetes or Docker. And then on the sort of more managed solutions, you’ve got something like Heroku. The last one I want to cover though, there’s just, it’s cannot escape. The fold of the top five is PHB. Now my hunch is that with PHP, it’s, there’s so much grasp on it because Facebook employs a lot of people and WordPress employs a lot of people. So between Facebook and WordPress, you’ve got a bunch of PHP variants. Do you think that’s it? Or, and it’s just, it’s, it’s in the top five because a lot of people employ PHP developers or is there still space for building a new Greenfield project in a PHP framework like Laravel or symphony

Jason Meller 00:59:00 I’ve been so impressed by the level framework and the community around it. In fact, as someone who is invested in the majority of my time in the rails ecosystem, and we’re starting to actually take some of the ideas from Laravel and incorporate them into that framework into the rails framework, because they’re just so far ahead. I think the thing that really gets right is they’ve identified who their audiences, it’s mostly B2C and B2B SAS. People want to build SAS applications and they have distilled down the modules in there. Many of them are actually paid that’s their business model. And it’s like, here’s the best, most economical way to do off Laravel. Here’s how you’re going to store objects in S3. Like the things that you’re just going to need, regardless of what type of actor building, like, they’re just the table stakes, SAS capabilities that you’re going to need.

Jason Meller 00:59:51 Like everybody’s going to need to upload an avatar. Like you’re going to need to be able to put images in a bucket somewhere like, and you’re going to need to deal with cropping them and resizing them. And, you know, things like that. Like everybody has to do that at some point. It doesn’t matter what your web app is. They’ve just figured that out and they make PHP look good, like the syntax and the API they’re using. Like they’re still somewhat limited. I think by obviously the language itself and even the creator of PHB would be the first to admit that he knew nothing about language design when he was really creating it. And a lot of the things that you really need to write, I think competent could impeach. We were introduced after PHP five, like classes, like there’s just no concept of Peachtree was not even a full object oriented programming language until the late two thousands.

Jason Meller 01:00:35 So it’s crazy to see how much Facebook has, I think influenced the legitimacy of PHP. And then now I think there’s a lot of great frameworks based on that new influx of legitimacy and then proof of scale where I think it would be a fine choice. I think you’re right though. I think the majority, like I’ve read a stat, I think that’s at 76% of server side. Like if you were able to attack the server-side language of the majority of websites that are out there at PHP would be the one that would make them up to 76%. So, and I think a lot of that is gotta be WordPress or, you know, uh, similar types of content management systems that are out there. But I think that there is a strong passion of, of Laravel and other, I think cake PHB, like a that’s one that I remember back in the old days, I think that have been subsumed by like the Laravel community. So I would choose Laravel if you’re building a web SAS application and PHP, and I think you’re going to have a great time doing it. And I think you’re gonna find really passionate people to work for you. And I think it will be performing enough. And Facebook has proven that,

Adam Conrad 01:01:38 Well, Jason, this has been a great conversation talking about these Greenfield projects today, and I really appreciate you going through all these different tech stacks will be. So I want to close out with a kind of rapid fire set of questions here. I’m just going to ask you just personal recommendation and nothing else. Just, I’m going to ask you about a series of different kinds of apps that you would build and just kind of get your rapid fire. What language stack would you use for them? Ready? Okay. All right.

Jason Meller 01:02:00 Web app for me, Ruby on rails backend. And then I think front end, I really liked the Hotwire library, like actually putting HTML over the wire to build the front end, very similar to Phoenix live view. So Ruby on rails, obvious choice for me there

Adam Conrad 01:02:13 About a SAS product. It may not necessarily be, it could be on-prem installed doesn’t necessarily have to be web driven, like a standard web app. Yeah.

Jason Meller 01:02:20 I think that you’re gonna have a hard time building a SAS product that doesn’t have some kind of web component to it, but I think there are out there, I think, direct to app store. There’s good examples of that. So I think if you can carve off your audience to just, if you can start with just apple, if that’s where your audience is and you don’t need Android right out of the gate, go at swift swift UI, and then you have something like Firebase or something for know actually persisting data.

Adam Conrad 01:02:42 Okay. So I guess I probably answered my next one, which is mobile app would be iOS. So you would do swift.

Jason Meller 01:02:48 Yeah, definitely. I think if you asked me a year ago, I’d say it’s important to learn objective C cell and you’re going to need, I think a little bit more of UI kit swift UI has come a long way and I WWDC is right around the corner. I think it’s good for you. I think you can just learn to swift and swift UI now, and you’re going to be in good shape to build anything that you want within reason

Adam Conrad 01:03:07 Desktop app,

Jason Meller 01:03:08 Desktop app. So I’m a Mac user primarily I’m going to want to reach for me personally, swift swift UI again. And I think there’s a lot of great technologies that are coming out that allow you to maybe leverage that code and potentially use it in other like iPad, iOS and iOS itself when it comes to windows and Linux, I’m not the super expert there. And so in my opinion, if you need to have like a multi-platform story, that’s when you want to reach for something like electronic. And I wouldn’t feel ashamed of that vs code is coded in electron. It’s an incredible product that works relatively well. And when you have texts, when you’re building a text, editor, web browsers are great at texts. That’s what they’re designed to do. Don’t feel shame and using electronic. If you’re building like an IDE, you want a cross-platform, it’s a great choice. FinTech

Adam Conrad 01:03:56 Focus.

Jason Meller 01:03:57 Okay. FinTech. I think you’re going to want to look at become it’s in the space. And I think a lot of them have a lot of tech debt to work with. I think you’re gonna see a lot of Python and FinTech in terms of like the newer languages there. I don’t think you’re going to see a lot of Ruby, but I don’t know if you would consider. Yeah, I don’t know. Not authoritative enough. I think to give a good recommendation, their API is a really important, I would really think about choosing a language is going to allow you to build a lot of microservices based API APIs that are gonna be useful in the context of a greater organization. For me personally, that means reaching for things like Golang things that, again, I can just kind of get a nice performance, well typed API out the door.

Adam Conrad 01:04:37 Yeah. I’ve heard Python. Also the same reason for AI focus is because of its integer and floating point precision. That’s a big reason why it’s so successful in the data science community is because all the sort of linear algebra you have to use for the scikit-learn is because of the precision. That’s so high in Python with a 32 and 64 bit integers. And so I’m assuming that for AI, you would also choose Python.

Jason Meller 01:05:00 Absolutely. Yeah. That’s a no-brainer what about blockchain? Blockchain? I think Coinbase has proven it out. I’m a big fan of Ruby for blockchain. Obviously I’m not an expert on blockchain in general, but I think that you have a little bit more latitude there in terms of building something. Obviously if we’re talking about actually things out of a blockchain, then we’re talking about like very low level of GPU level stuff then, so that’s going to be more C, C plus plus, or, you know, you might actually want to understand like the actual micro code that’s actually used, uh, to build this GPU’s that we’re getting in the weeds

SE Radio 01:05:34 Call 42 is a new series of must-watch tech conferences. It’s online and free to attend with hybrid events coming next year, come 42 conferences, cover topics like cloud SRE, chaos engineering, machine learning, and quantum computing, as well as programming languages, including Python, Golang, rust, and JavaScript register for [email protected] slash se radio that’s C O N F number four, number two.com/s E radio. See you there for the ultimate answers.

Adam Conrad 01:06:07 All right. Very last question. What other framework would you consider for any other application that we haven’t covered?

Jason Meller 01:06:13 Any other framework? You know, I’m just going to put a shout out there, like I’m really impressed with the Earl Lang slash elixir community OTP in general. I think that they’ve gotten that mixture right. Of giving you enough productivity to build a kind of a bunch of backend services that kind of participate in work with a really great front end web application, which you can build in a framework called Phoenix. They have, I think a really good non JavaScript, heavy front-end story with like Phoenix live view. And I know that, you know, I think Erling and elixir are well-suited towards a number of different products, not necessarily just a web app discord, I think is a great example of a, of an organization that really is betting big on that community. And, uh, they’re doing a great job.

Adam Conrad 01:06:59 Perfect. Well, this was great. I’m glad to get all your feedback on this, Jason, thank you again so much for talking with us today about choosing tech stacks for your next Greenfield project.

Jason Meller 01:07:10 Thanks. Hopefully I was helpful everybody out there listening, trying to make some good decisions, remember optimized for your team first and then for the problem at hand. Great. Thank you so

Adam Conrad 01:07:18 Much.

SE Radio 01:07:20 Thanks for listening to se radio an educational program brought to you by either Billy software magazine or more about the podcast, including other episodes, visit our [email protected] to provide feedback. You can comment on each episode on the website or reach us on LinkedIn, Facebook, Twitter, or through our slack [email protected]. You can also email [email protected], this and all other episodes of se radio is licensed under creative commons license 2.5. Thanks for listening.

[End of Audio]

SE Radio theme: “Broken Reality” by Kevin MacLeod (incompetech.com — Licensed under Creative Commons: By Attribution 3.0)

Join the discussion

You must be logged in to post a comment.

1 comment

Austin Kim says:

August 8, 2021 at 12:21 am

“Optimize for your team first, and then for the problem ahead”
This has got to be the most underrated tech podcast episode of the year; mad props to Kolide CEO/CTO Jason Meller and SE-Radio host Adam Conrad for squeezing so many insights and so much valuable, specific, and concrete advice within a single hour 👍

SE Radio 471: Jason Meller on Choosing the Right Tech Stack for a Greenfield Project

Show Notes

Related Links

Transcript

Join the discussion

1 comment

More from this show

SE Radio 646: Matthew Skelton on Team Topologies

SE Radio 645: Vinay Tripathi on BGP Optimization

SE Radio 644: Tim McNamara on Error Handling in Rust

Menu

Recent posts

Search

Search

SE Radio 471: Jason Meller on Choosing the Right Tech Stack for a Greenfield Project

Show Notes

Related Links

Transcript

Join the discussion

1 comment

More from this show

SE Radio 646: Matthew Skelton on Team Topologies

SE Radio 645: Vinay Tripathi on BGP Optimization

SE Radio 644: Tim McNamara on Error Handling in Rust

Menu

Recent posts