diff --git a/gotime/go-time-339.md b/gotime/go-time-339.md index 3cfc131c..a4e3b3af 100644 --- a/gotime/go-time-339.md +++ b/gotime/go-time-339.md @@ -20,7 +20,7 @@ But to give some context for folks, actually, Christian, you submitted a request So I wanted to go ahead and create a POC just using Go, where we could get the same API -- because these APIs are very simple. It was basically grab something -- I worked for an airline. So it was basically grab something from Amadeus or Sabre, which is like a reservation system, do something to the data, and then return it in like a nice REST form. So it was very, very simple. And so there was no need for the whole MuleSoft abstraction to just do that API. -\[00:07:56.16\] As I created the POC, my boss and my boss's boss was very excited. But then there is the issue of "Is the enterprise ready for it or not?" Everyone was really locked into MuleSoft. And MuleSoft comes with like a lot of great things as far as platform. The security, the pipelines... Everything is already included inside the box. And if you want to get out of that, especially in an enterprise setting, you have to figure out a good way of doing that, using like Kubernetes, and all this good stuff. And it was just too much work, and they weren't willing to commit to it... Which is understandable. +\[07:56\] As I created the POC, my boss and my boss's boss was very excited. But then there is the issue of "Is the enterprise ready for it or not?" Everyone was really locked into MuleSoft. And MuleSoft comes with like a lot of great things as far as platform. The security, the pipelines... Everything is already included inside the box. And if you want to get out of that, especially in an enterprise setting, you have to figure out a good way of doing that, using like Kubernetes, and all this good stuff. And it was just too much work, and they weren't willing to commit to it... Which is understandable. **Johnny Boursiquot:** So if I understand correctly, there was already an adoption or a comfort with an existing platform, an incumbent, where Go, or it sounds like really it could have been anything new, any language, did not have enough momentum to dissuade the people who are already comfortable with the tech, that they know and use to try something perhaps new or different. Basically, it took too much effort to try and adopt something new. Would that be fair? @@ -40,7 +40,7 @@ So I wanted to go ahead and create a POC just using Go, where we could get the s In other cases - you know, I came to go particularly in an organization where we were deep into a node deployment. And this was pre-promises, this is 2014, and we were in callback hell. We were doing some really sophisticated logic that was almost impossible for normal human beings to process, because we were trying to deal with 17 layers of callbacks. And it was a mess. And one weekend I read about go and said "Wait a minute..." and decided to sit down and try and recreate one of our services. We were kind of a microservices model. And I recreated an entire service in Go over the weekend, and came in on Monday and said "How about we switch to Go?" At least for the backend stuff. I mean, obviously not for the frontend stuff, but for some of the backend services... Because it was just so much easier to think about. And this was this was Go 1.6, or 1.7... Or 1.9. I mean, I don't remember exactly which version. But it was a while back. But even then, the things that I still think make it a good choice were the choices we were making. -\[00:11:53.12\] But back to the larger question, every time -- the company I work for now, we are doing observability in the cloud, Honeycomb, and we are trying to replace our competitors in the marketplace. We go in and we're fighting with people who already are using some big competitor. And we're saying "Hey, we can do it better. We can do it cheaper. We can do it faster." Whatever we're saying about that particular thing. And then those companies have to say "Well, okay, yes, but I've got a sunk cost." And the question is, can you talk them out of -- can give them a future that is looking better than the future they can see with the current thing, even given the cost of transition? You have to take it into account. But sometimes you have to say "Yeah, it's worth it." +\[11:53\] But back to the larger question, every time -- the company I work for now, we are doing observability in the cloud, Honeycomb, and we are trying to replace our competitors in the marketplace. We go in and we're fighting with people who already are using some big competitor. And we're saying "Hey, we can do it better. We can do it cheaper. We can do it faster." Whatever we're saying about that particular thing. And then those companies have to say "Well, okay, yes, but I've got a sunk cost." And the question is, can you talk them out of -- can give them a future that is looking better than the future they can see with the current thing, even given the cost of transition? You have to take it into account. But sometimes you have to say "Yeah, it's worth it." **Johnny Boursiquot:** So the definition of better... For a lot of companies, there's a correlation with increased revenue, or profit, or something... There's got to be an impetus. Simply, as a technologist, going in and saying "Hey, we should switch to language X, or framework Y", there's a cost to that. And while every engineer might be excited about the new shiny, businesses are not in the business of adopting languages or frameworks every other year. So there's going to be a case that must be made... And I'm thinking in Christian's case, where the company has tied their fate, for better or worse, to MuleSoft. And now here comes an engineer, with a solution which arguably could be better, by some definition, some technical definition, better than the status quo... But then the friction you're running up against is not one of technology, it's one of business. @@ -50,7 +50,7 @@ So back to you, Kent - today I know Honeycomb uses a ton of Go, in all kinds of Actually, I'm pretty involved in open telemetry, and one of the things that happened with open telemetry was like most of the underlying things like the collector and stuff is written in Go... It was kind of the first language of open telemetry. There's many things and other things, but now what happened is there's one major piece that's being created, and somebody said "I want to try to do this one in Rust." And so we've got this processing tool that is being written in Rust, rather than Go... Which has its own social issues, because a bunch of the people who've been working in Go for the last decade aren't qualified to actually even review code in Rust. So you have to make that whole team transition. There are benefits to doing that stuff. But that's the expense. And like I said, when I switched a team from JavaScript to Go back in the day, we were still pre-launch. We didn't have a constrained thing. We were still building all the pieces before we could get it out the door, and we decided that actually we would save time by converting our services to Go, because at that time we didn't have that much to do. -\[00:15:51.26\] Now, for Honeycomb it would take a major act of Congress or something to cause Honeycomb to switch away from Go, simply because there's just so much code, and there's so much stuff that works well, and is in production, that switching it out for just because there might be a benefit someday... +\[15:51\] Now, for Honeycomb it would take a major act of Congress or something to cause Honeycomb to switch away from Go, simply because there's just so much code, and there's so much stuff that works well, and is in production, that switching it out for just because there might be a benefit someday... **Johnny Boursiquot:** Yeah, it's a hard sell. So Christian, you mentioned you've been -- relatively, at least, to Kent and I on this podcast, you're relatively new to software engineering overall. I think you mentioned something like four or five years. Is that right? @@ -66,13 +66,13 @@ Actually, I'm pretty involved in open telemetry, and one of the things that happ **Johnny Boursiquot:** Yeah. Can you explain a little bit about what -- I think you mentioned Python. What is that technology, framework, or stack? -**Christian Gabrielsson:** Yeah, so Airflow is for data pipelines. So it's like an orchestration tool. It was originally an Airbnb, then they open-sourced it, and now it's in the Apache Foundation. So it's Apache Airflow. So it's used for -- in American Express, they use it for a lot of things, but I work in finance, so it's used for reporting, for like the federal requirements, for like financing, with banks. So that's what I do now. But previously, I was doing Go. Previously, I was using MuleSoft, so Java, and then previously I was on the frontend, so Angular. +**Christian Gabrielsson:** Yeah, so Airflow is for data pipelines. So it's like an orchestration tool. It was originally an Airbnb, then they open sourced it, and now it's in the Apache Foundation. So it's Apache Airflow. So it's used for -- in American Express, they use it for a lot of things, but I work in finance, so it's used for reporting, for like the federal requirements, for like financing, with banks. So that's what I do now. But previously, I was doing Go. Previously, I was using MuleSoft, so Java, and then previously I was on the frontend, so Angular. There's so many different languages, tools, and frameworks that you consistently use... And I think one thing that I've learned just in my short term is that you have to be continually a) learning, and b) being able to switch between languages. Because I think that that is the future. **Johnny Boursiquot:** So the ld adage of every tool for the -- the right tool for the job, kind of thing... Which, interestingly enough, in my experience that typically means -- like, very seldomly am I on a team where people will say "Use the right tool for the job", and it doesn't end up being the tool they know the best. \[laughter\] In some cultures, in some team cultures, perhaps everybody kind of accepts that, and they'll be like "Well, we picked this language, or we did the due diligence, we identified this language as the thing we all love and want to use", and so that implicitly becomes, "Well, why not use the thing we all said we were going to use?" -**Kent Quirk:** \[00:20:08.15\] I mean, that drove an awful lot of Node adoption, because people are like "I've been coding in frontend in JavaScript, so why can't I code the backend in JavaScript?" And that was in large part why the team that I had worked on was using it. And once you realize that there is a bright line separation between those two, there's no particular reason that doesn't justify, in my view, wanting one language. The languages are pretty fungible. You can you can switch between different languages and get the thing done. It's the systems around those languages and what they give you, and that's one of the big benefits of Go. I think, from my point of view, the most enormous benefit of Go is the fact that if I went back to the code I wrote in 2014, I could even compile it with the current Go compiler. I can read it, I can maintain it. And Go, beyond -- like, the JavaScript code we had at that time wouldn't even run today. And it would be considered five generations old. And one of the major, major, I think, advantages of Go is its long-term maintainability. +**Kent Quirk:** \[20:08\] I mean, that drove an awful lot of Node adoption, because people are like "I've been coding in frontend in JavaScript, so why can't I code the backend in JavaScript?" And that was in large part why the team that I had worked on was using it. And once you realize that there is a bright line separation between those two, there's no particular reason that doesn't justify, in my view, wanting one language. The languages are pretty fungible. You can you can switch between different languages and get the thing done. It's the systems around those languages and what they give you, and that's one of the big benefits of Go. I think, from my point of view, the most enormous benefit of Go is the fact that if I went back to the code I wrote in 2014, I could even compile it with the current Go compiler. I can read it, I can maintain it. And Go, beyond -- like, the JavaScript code we had at that time wouldn't even run today. And it would be considered five generations old. And one of the major, major, I think, advantages of Go is its long-term maintainability. The Go 1.0 compatibility promise has been really, really important. And the fact that that code - I can still read and write the same code, in the same styles, for a decade... It turns out software lives a long freaking time; a lot longer than you wanted it to. I've got stories about that too, but man, you've got to be able to keep working on it. And the pain of -- you know, we just watched the team switch from React 16 to 18... That was a painful multi-month effort, by multiple people. @@ -82,7 +82,7 @@ The Go 1.0 compatibility promise has been really, really important. And the fact But yes, dependency hell is a problem. Just people going "Well, we're going to make a breaking change. It's time to make a breaking change." And the acceptance of breaking changes, if you're always staying current... Or your model is "I write new frontends all the time, and I don't go back and fix the old ones." I mean, that's the kind of thing that happens with mobile apps. You build a mobile app once, and you maintain it for a few weeks, and then it stops selling, and then you go on to the next mobile app. You don't really need 10 years worth of maintainability. But when you're working on backend code, that stuff lives forever. -**Break**: \[00:23:16.13\] +**Break**: \[23:16\] **Johnny Boursiquot:** So at some point -- or rather, I keep thinking that folks that are sort of comparing the fine tooth comb languages, or whatever camp of your favorite language is today, at some point I think ultimately, at least for me, it became clear that... I think you touched on this earlier, Kent - ultimately, the language may not matter. Once you have a sound foundation for a choice of a language or technology, whatever the case may be, at some point that choice doesn't matter, in the sense that once the business, once it's in production and the business is making money on it, there's a certain threshold where whatever gains, whatever changes you want to make, they have to be additive. You can't go back and change something that is working, by some definition, you can't go back and change that. Whatever new thing you want to add is going to have to be a new thing that you add on top. It has to be additive to increase revenue, reduce costs, whatever the case may be. When I say it doesn't matter, your attention, perhaps as you sort of came to understand very vividly, Christian - there was no way the organization or even the team was going to move away from Java and MuleSoft in a sense, because those decisions had been made and cemented. You kind of had to pick your battle -- in this one you kind of picked the wrong battle, if you will. @@ -96,7 +96,7 @@ But yes, dependency hell is a problem. Just people going "Well, we're going to m Heck, last night I was -- I never used Tailwind, and I needed to quickly come up with a static website, and I'm like "Hey, you know what? Tailwind seems to be the new hotness, at least for a much improved experience from dealing with plain vanilla CSS", at least from how I remember it, from a couple of decades ago. So I used Tailwind, and I asked ChatGPT to generate some CSS for me. "Give me a template, give me a -- whatever it is", and I was able to copy-paste, make some tweaks, and then I was done by the end of the night. My job was done. I had a solution, it got shipped, and I moved on in my life. -\[00:29:56.28\] Now, am I going to be doing Tailwind all day, every day? No. I had a specific problem, and I solved it using these new tools. So I'd like to hear from both of you, are you sensing this tug away from the fanaticism, if you want to call it that, around specific languages or technologies, now that we have these AI tools that are entrenching themselves in our lives as software engineers, as professionals? Are you sensing this tug as well, that these things ultimately don't matter that much? +\[29:56\] Now, am I going to be doing Tailwind all day, every day? No. I had a specific problem, and I solved it using these new tools. So I'd like to hear from both of you, are you sensing this tug away from the fanaticism, if you want to call it that, around specific languages or technologies, now that we have these AI tools that are entrenching themselves in our lives as software engineers, as professionals? Are you sensing this tug as well, that these things ultimately don't matter that much? **Kent Quirk:** I think the world is open to more solutions than it used to be, I think because, as the internet has exploded, and like you said, with the ChatGPT and all the other Copilot, that kind of stuff, it's easier to switch tools and platforms. I think there's a difference though between "I need to solve some little problem, and I've just got to get in, get out, and I don't care what language I use to do it, I just need a solution" and "I'm going to build my business on this, and hire engineers to work on it. And it's going to run for the next umpty-ump years, possibly at really significant scale." And those decisions require more thought. And you need to think about what are the strengths and weaknesses of the solutions you're considering. @@ -112,7 +112,7 @@ So yeah, I think there are languages you can choose that will make your life eas **Johnny Boursiquot:** Christian, how's your life impacted as an engineer in light of these new toolings and access to all this new fangled stuff? -**Christian Gabrielsson:** \[00:34:00.19\] You mean the AI assisted tools? +**Christian Gabrielsson:** \[34:00\] You mean the AI assisted tools? **Johnny Boursiquot:** Yeah, exactly. Well, perhaps a more specific question - given that you didn't start out as an Airflow expert, perhaps not a Python expert... How did you ramp up, to be effective enough to get the job done? Did you use those Copilots and ChatGPTs, these new tools to help you ramp up? @@ -132,7 +132,7 @@ So yeah, I think there are languages you can choose that will make your life eas **Johnny Boursiquot:** 1.0... \[laughs\] -**Kent Quirk:** \[00:37:49.20\] ...and the stuff I was trying to do was all being marked by Deno 2 as "Hey, that's obsolete. You should do it this other way." Except there wasn't any example I could find in the other way... And it was like, it's really an interesting thing what Christian has pointed out - you need to use your brain to decide if the thing that the AI bot is telling you is actually useful. And so in this case, it wasn't. \[laughs\] So that kind of touches on this whole thing of technology choices, and all that kind of stuff. I mean, it looks to me like Deno 2 was going to be really cool, but I'm going to come back in a few months and see where it is. +**Kent Quirk:** \[37:49\] ...and the stuff I was trying to do was all being marked by Deno 2 as "Hey, that's obsolete. You should do it this other way." Except there wasn't any example I could find in the other way... And it was like, it's really an interesting thing what Christian has pointed out - you need to use your brain to decide if the thing that the AI bot is telling you is actually useful. And so in this case, it wasn't. \[laughs\] So that kind of touches on this whole thing of technology choices, and all that kind of stuff. I mean, it looks to me like Deno 2 was going to be really cool, but I'm going to come back in a few months and see where it is. **Johnny Boursiquot:** Right. Until the dust settles. @@ -148,7 +148,7 @@ I don't think it's going to. I think it's going to help. I don't think software **Kent Quirk:** It really isn't. I mean, I enjoy ranting about AI, but I find that AI is not solving the problems I'm being asked to solve. I saw a quote the other day that was something like "Junior engineers write code, senior engineers delete code, and staff-level engineers eliminate the system, or redefine the problem." So I think we're at the point where AIs can write a fair amount of code, but they can't write good code, and they don't know if they're writing the code that is actually useful or. -\[00:42:00.17\] If you can describe the problem clearly enough, you can probably get the AI to kind of mostly write a lot of it for you... So they can be a helpful additional productivity tool. But I don't think they're even close to replacing people at the level of staff engineers in scalable organizations. So I'm not worried about it. +\[42:00\] If you can describe the problem clearly enough, you can probably get the AI to kind of mostly write a lot of it for you... So they can be a helpful additional productivity tool. But I don't think they're even close to replacing people at the level of staff engineers in scalable organizations. So I'm not worried about it. **Johnny Boursiquot:** Right. It's interesting to to know -- and Christian, I know you want to chime in here... It's interesting to know that in the beginning I think folks were saying similar things, but they were saying, "Hm, I don't think this is good enough to to replace a junior engineer." Then it became "Hm, I don't think this is good enough to replace a senior engineer." Now we're saying, "Hm, I don't think it's good enough to replace a staff engineer." @@ -168,7 +168,7 @@ I don't think it's going to. I think it's going to help. I don't think software So I think at some point Go, like everything else - and this is the cycle of life. Something comes in, it's popular, lots of mind share, people want to learn and people want to use it... And then it gets replaced eventually by the new hotness. So I don't think we're at the stage yet for Go to be replaced by the new hotness. I don't even know what that would be. I think the problem is going to get redefined, to borrow Kent's staff engineer analogy. So we're going to stop defining the problem as we always have, and then now we're going to try and solve the problems with new tools, in different ways, because we're asking different questions. But until then, Go's fit for the future, or basically the current market we are in now... How do you see -- are you using the same metrics that you used to pick Go 10 years ago, 12 years ago, or in your case, Christian, when you first came across it and you saw it three, four years ago, like "Wow, this is amazing..." Are you all still using the same criteria to pick or to stick with Go? Or is that changing, or should it change? -**Christian Gabrielsson:** \[00:46:19.27\] I think fundamentally it's always using the right tool in the toolbox, is what I'll say. Java is known for this. The JVM cold boots takes a few seconds... So if you need a process that works right away, honestly, don't use Java. But in that case, obviously, use something that's more performant right out of the box, like Go, that doesn't have that cold boot sequence. +**Christian Gabrielsson:** \[46:19\] I think fundamentally it's always using the right tool in the toolbox, is what I'll say. Java is known for this. The JVM cold boots takes a few seconds... So if you need a process that works right away, honestly, don't use Java. But in that case, obviously, use something that's more performant right out of the box, like Go, that doesn't have that cold boot sequence. Similarly to -- I know not everyone is a big fan of Python, but for data sciences, all the libraries and everything, you might as well use Python. For frontend, JavaScript. I don't think these these things change very often. I think one thing that Go has, that not many languages have done well so far, is that backwards compatibility. And I think that is going to be -- for like the next 10, maybe even 15 years, is what makes it still very relevant, is the fact that it is backwards compatible. Like what Kent said, you can have a project in Go from like 5, 10 years ago, and it will still run, versus if I were to boot up one of my old JavaScript projects I did like three years ago... I guarantee you it won't work. And that is for maintainability, in large teams, that's everything, I think, personally. @@ -178,9 +178,9 @@ So choosing your languages - I think the interesting question is like... Okay, s So I think Go will still be around. I mean, it definitely will still be around in 10, 15 years. The question is how popular is it, and does somebody else invent a slightly different paradigm, or a more important paradigm, or whatever? And the answer is I don't know. But whatever it is, we'll be there to play with it, right? -**Break**: \[00:49:03.20\] +**Break**: \[49:03\] -**Jingle:** \[00:52:24.19\] +**Jingle:** \[52:24\] **Johnny Boursiquot:** Alright, who brought the heat? @@ -196,7 +196,7 @@ So I think Go will still be around. I mean, it definitely will still be around i **Johnny Boursiquot:** My unpop is one I've arrived to recently. If you recall back in the day a lot of folks didn't -- some of the gripes against Go was like "Well, it doesn't have generics" or "It doesn't have -" insert my favorite feature, from my favorite language. Blah, blah, blah. Or I don't like how it does error handling. The typical set of things... Some of those things you don't hear anymore, because the language has added those things as features. But I'm of the opinion that unless you have a very specific use case for some of those language features - I'm talking like generics, or iterators, or things of that nature. If you find yourself not reaching for those things on a regular basis, despite the hype and the fanfare around them, you're not doing anything wrong. You're not using Go wrong because you're not using iterators. -\[00:55:55.00\] I think those things, those features are very useful for a very specific kind of problem. You're going to find great use for these things if you're trying to create abstractions, or a general-purpose utility for certain things. If it's something you want to be able to work with different kinds of data types, and things of that nature. These generic - using the term loosely here... These generic approaches, they solve a particular kind of problem, a particular class of problems, that for your day to day writing line of business code to move data from here to there, if you don't find yourself reaching for those things constantly, or even thinking about them, that's okay. It just means that your use case doesn't call for them. Just because a feature is in the language doesn't mean you have to use it. That's perfectly fine. It's perfectly okay. It's okay if you never use generics in your code, if you don't ever need it. And it's okay if you go the long way on certain things. It's okay if you never use iterators. It's okay if you never use fuzz testing. It's okay if you don't use those things, because not every feature of the language needs to be used. +\[55:55\] I think those things, those features are very useful for a very specific kind of problem. You're going to find great use for these things if you're trying to create abstractions, or a general-purpose utility for certain things. If it's something you want to be able to work with different kinds of data types, and things of that nature. These generic - using the term loosely here... These generic approaches, they solve a particular kind of problem, a particular class of problems, that for your day to day writing line of business code to move data from here to there, if you don't find yourself reaching for those things constantly, or even thinking about them, that's okay. It just means that your use case doesn't call for them. Just because a feature is in the language doesn't mean you have to use it. That's perfectly fine. It's perfectly okay. It's okay if you never use generics in your code, if you don't ever need it. And it's okay if you go the long way on certain things. It's okay if you never use iterators. It's okay if you never use fuzz testing. It's okay if you don't use those things, because not every feature of the language needs to be used. Again, this is for me using the right tool for the job. I'm thankful and I'm grateful that Go has so many tools that I can reach within that one tool belt, and then pick out the one thing that I need to use for this particular instance. I'm grateful for that. But just because I don't reach for that specialized \[unintelligible 00:57:14.19\] in my toolbox, because I rarely have use for it, that doesn't mean -- me knowing that the tool is there in case I ever do want to use it, knowing that it's there is sufficient. But I'm not going to think "Oh, I'm not using the language to its full potential because I don't reach for this specialized tool."