📊 While we wait for Go 1.23, we discuss the latest Stack Overflow survey results
This show is community sponsored. We'd love to have you as a Patreon member. Stick around a little bit later to learn more about that. This is Cup of Go for August 9, 2024. Keep up to date with the important happenings in the Go community in about 15, 20, 30 minutes per week.
Speaker 1:I'm Jonathan Hall.
Speaker 2:And I'm Shayne Ahmad.
Speaker 1:Hey, Shayne.
Speaker 2:Hey, Jonathan. Welcome back.
Speaker 1:Missed you last week. We had our, some scheduling snafus.
Speaker 2:Summer do be like that. Indeed. This episode is also, not edited by our professional grade editor because they're taking a vacation, and we're totally here for that. They even won't hear us, talking about this because I assume they don't listen to the show if they don't have to edit it. So isn't this a good place to just, thank Filippo for all their hard work Thanks, Filippo.
Speaker 2:Editing the show.
Speaker 1:Hey, editor. Put in some platitudes.
Speaker 2:No. No. I did do this. So don't do any of this stuff. The whole editor is done.
Speaker 2:Alright. Right. So I think, you know, we're all excited for the go 123 to be here. Is it here yet?
Speaker 1:Did you refresh? It's not. I've been refreshing every 30 seconds. It's not
Speaker 2:here yet. But there are 2 minor releases.
Speaker 1:It might be here by the time the show is is edited, though, and and uploaded.
Speaker 2:It takes so long to edit. We might be at 124.
Speaker 1:Yeah. We do have a couple minor releases. Go 122.6 and 121.13 are out. I predict this is the final, edition of 121 and that 123 will be out very, very soon.
Speaker 2:And what like, why do these releases stand out to you?
Speaker 1:Because they're not a security fix. This wasn't a secret, you know, don't tell anybody what's happening. This was just a, oh, by the way, we fixed some things.
Speaker 2:So you think it's like a final, like, clearing the table before the next
Speaker 1:guest setting? Based on the pattern, I've started to notice for previous releases, They do one of these, and then a few days later, they do the the big one.
Speaker 2:So we'll see.
Speaker 1:I could be wrong, but we'll see.
Speaker 2:Today is at the time of the recording, it's, Peter Aronoff's birthday. Peter, happy birthday, man. But looks like the release team is not planning to get get you a gift. So you'll have to just get flowers from someone. I don't know.
Speaker 2:Funnily enough, Peter, I don't know if you meant this on purpose, but you said, my birthday is Friday, so if anyone from the release team is looking to, get me a nice gift, a nice gift is literally my name, tranahmad in Hebrew. So I I read that in English. I was I did a double take. So no gift for, Peter, but, a small, you know, patch release with no security issues, and the issues that are actually fixed are very minor. Right?
Speaker 2:It's like, oh, edge case, whatever, empty, profiles, sometimes on an edge case. But I do wanna discuss, the IPv4 backed IPv6 vulnerability. That wasn't fixed in this release, though. Right? It was a few releases back?
Speaker 1:Yeah. This is a, you know, a couple months old, I guess, but it was it came up on our Slack channel this last week, so it's worth talking about.
Speaker 2:Is it worth talking about? What makes a vulnerability worth talking about? What what do you look at? Because, you know, there are a lot of vulnerabilities. You can't talk about them all.
Speaker 1:That's true. I think this is worth talking about in our context in particular because our listeners were discussing it, but the broader question, is a security vulnerability worth looking at or talking about? Is it likely to affect me? That would be my
Speaker 2:first question. You need, like, some some metric to know, hey. Is this high importance, low importance? Is this critical? Right?
Speaker 2:Yep. So I've had a lot of discussions about that generally. So let's tackle the specific, issue first. Right? Do you know what is a loopback, IP address or a private IP address?
Speaker 1:Oh, yeah. Do I need to explain or or is it
Speaker 2:Just given it, like Yeah. We we IP addresses have some attributes. Right? Yeah. Yeah.
Speaker 2:They might be the loopback, address, and they might be private, which means they're on a private network. And then you might have rules, in your application that are different for, let's say, IP private IP addresses. Right? Sure. That makes sense.
Speaker 2:You're a server, and you have a public facing endpoint and a private facing endpoint, like towards the Internet with 1, network interface and towards your internal network with the other. Yeah. And for the internal request, you don't need to run authentication or whatever, so you skip it. The way you skip it is you call, is, private, or is loopback, or is, like, blah blah, from the Go code. Right?
Speaker 2:These methods do not work as expected, which usually vulnerabilities, that's how you, you know, it's a bug that can also be exploited for, some problematic stuff. The specific CVE we're talking about, 2024-247-90, I mean, is that various is whatever methods, like is private and is loopback, do not work as expected, not if you're looking at normal IPv4 addresses, but if you're looking at IPv4 mapped IPv6 addresses Okay. So I didn't know what these were. They they were news to me. Do do you know what these are?
Speaker 2:IPv4 mapped IPv6 addresses?
Speaker 1:IPV6 notation for an IPv4 address. Right?
Speaker 2:Yeah. So it's for some reason, there like, there was a small bug there where you look at, like, an address that's mapped to a different address, and if you're calling is whatever on that, like, mapping because you wanna just use IP v 4, let's say your software code only supports, IPv4, but in reality, the device, like, has IPv6, you know, outward, so your operating system allows it, which makes sense, you know, internally on the machine, like a symlink between IPv4 and IPv6. People told me the world is gonna run out of addresses when I started learning learning networking in, 2011. Didn't didn't happen yet.
Speaker 1:So,
Speaker 2:I'm not too worried, but there is IPv6, right, exactly for that, has a wider range of addresses. But if your program doesn't support it, then you have ipv4 mapped IPv6 addresses. Discussion on the channel, started by, Mihai, shout out, Mihai, long, long standing community member of the show Yeah. Is why is this critical? It got a critical, score, so 9.8.
Speaker 1:8. That that's almost the highest. Right? Isn't 10 the highest?
Speaker 2:Exactly. One louder. Why don't you just make 10 louder and make 10 be the top number and make that a little louder?
Speaker 1:These go to 11.
Speaker 2:So it it is almost the highest, but you know how, in school, we had some teachers where everybody got, you know I don't know what's the scoring, system, but when you grow up, was it, like, a, a plus? Like Yeah. Yeah. So a teacher that gives everybody a's and then someone sometimes gets an a plus, the a doesn't mean anything. Right?
Speaker 1:Right. Yeah.
Speaker 2:So I had a discussion at work because I I read this, and I was like, what's the exploit? Like, what can I do with it? And the description doesn't say anything, which is really annoying. Like, it doesn't really have good, you know, documentation on, on NVD, which is the national like, from NIST, the National Vulnerability Database, that gives it, again, a 9.8 and critical. You can look at the change log, but both, contributors who reported this, vulnerability, they don't have anything.
Speaker 2:Like, the issue is it doesn't contain any extra information. So I actually looked at the code and tried to think about how I would, like, exploit it. You know, you just see someone backporting the issue. You can take a look at the change, itself, like on Garrett. Right?
Speaker 2:Mhmm. And you need to just check if the address is a v 4 a v 6 map to v 4 address. I couldn't locate the, you know, the 2 original security researchers, Anzhi Wang and Jin Chan Chen. Like, they had, some Twitter, accounts, but they were all in Chinese, and I couldn't, like, greet them. It really bugged me.
Speaker 2:So I contacted, one of the security researchers from ORCA, like, someone who does it for a living. And, she basically said it was really just totally on the nose. Just to be fair, why is this a security issue in general? It might, might, emphasis on the might, allow an attacker to, like, connect to a service that is shielded with someone doing, like, is private. So you know how the case I mentioned before, you have a service that that has a public, endpoint and a private endpoint, and the private endpoint doesn't have it doesn't have authentication or something like that.
Speaker 2:Right? It's internal. Because of this issue, you might, I think it's like a 50% chance, like, if it's true or false, accidentally step into an endpoint that you shouldn't be able to access if the only protection is is private.
Speaker 1:Yeah. Okay.
Speaker 2:So I can't really see how someone does only IP level protections.
Speaker 1:And certainly, attacker couldn't engineer this, really. Like, if they're lucky, they might be in a situation where they could exploit it. Right?
Speaker 2:For sure. And even so, that means that these endpoints are, like, worth something. Okay. I wanna access this admin API, but it's only for private IPs to connect to it. I still imagine, like, you need a token or whatever, just for the system to work, not like you know what I mean?
Speaker 2:Yeah. So this seems super, impractical to me, and the score still didn't sit well even after I figured it out. And then I talked to Bal Kaduri Fomoca. She's, like, the head of research. She is just doing things in BlackHat right now, etcetera, etcetera.
Speaker 2:And she was like, I'll give you the short of it. CVSS V3 sucks, quote. There's a huge bias there towards the higher scores. And then she gave me a link, I shared it in the channel as well. We should probably put it in the show notes, to look at other vendors, because, you know, NVD is not the only place that gives scores to vulnerabilities.
Speaker 2:And when you open Snyk Security, for example, they give it a much more reasonable 6. Right?
Speaker 1:Out of 10?
Speaker 2:Yeah. 6.2, out of 10. So, you know, they they still say, hey, you should probably upgrade. And by the way, if you do wanna upgrade, it's upgrade, no problem. Upgrading the Go, patch version, which you should do anyway.
Speaker 2:Right? But this was just interesting to me to see this, disparity between the NVD, which marks it as critical just because it can be accessed and it can happen to, in my opinion, a lot more reasonable and less, panicky, Snyk, and Red Hat, and, like, a few other vendors that market it as as 6. And on CVSS V4, which, the NVD should be moving to anytime, anytime now, it should get a low score as well. So this was a whole, you know, storm in a teacup over nothing, really, which is very frustrating to to me as a security petitioner. Right?
Speaker 2:Yeah. Yeah. Like, we have real security issues to worry about that we need to fix. You don't need to mark is private for IPv6, IPv4 mapped addresses as critical. Anyways, this was just an interesting rabbit hole to fall down into.
Speaker 2:But in reality, if all you care about is how did it happen, you can just take a look at the change log. It's ipv4, ipv6. I assume anything that has ipv6 in it has some bugs. Right? Because who cares?
Speaker 2:You only test on IPv4 anyway. And the fix is trivial, and you can already upgrade and get it. So if you're worried about this specific thing, just upgrade to the less latest patch version, assuming you're on a supported Go version. Right?
Speaker 1:Very
Speaker 2:cool. So that does it for this CVE. Hopefully, no more shenanigans in CVE scores, but honestly, probably shenanigans, still await us for the next, like, I don't know, few years.
Speaker 1:Yeah. Let's talk about some proposals, or a proposal, at least. I think there's only one on the backlog for the week to talk about.
Speaker 2:Mhmm. Everybody's busy for 1 to 3.
Speaker 1:Yeah. Yeah. So this proposal is is has an interesting history, that goes back many years. This particular proposal was proposed in 2020, January of 2020. The proposal is to add the context method to testing dot t, so you can the idea is to be able to pass along cancellation signals to your test.
Speaker 1:The interesting thing about this is it was actually, proposed and accepted and implemented and then reverted back in 2016.
Speaker 2:Wow. So we're proposing it again.
Speaker 1:Yes. Alright. So, the, the the idea is simple enough. The idea is your tasks should, be able to, if you want to, honor a context and do some cleanup. So suppose you hit control c while your tests are running, you wanted to close-up your database connections or remove temporary files or those sorts of things.
Speaker 1:Right? So I think everybody agreed that that's a good idea to do that. The problem was, back in 2016 when this was implemented, there were some concerns that just passing along the cancellation signal isn't enough because there's no mechanism to actually wait for that cleanup to happen. So we could tell your test process, start cleaning up, and then the process ends before the cleanup has actually been done. So this has been reproposed now.
Speaker 1:Now that we have this new test dot cleanup capability that allows you easily to do cleanup, it is guaranteed to happen before the process exit, has been reproposed.
Speaker 2:I can get a context out of t in the same way that I can, like, do t dot logf or t dot fatal, and I can get a valid context for the test?
Speaker 1:Yep. I believe that is how it works. Yeah.
Speaker 2:There's a interesting point here. If you wanna test, things that actually use, things in the context. Right? You wanna, let's say, pass a trace ID within the context and then Yeah. Test that the logs contain the trace ID.
Speaker 2:You should probably generate your own context. Right? This is just in case you have external, dependencies that you wanna clean up, database connections, like you said, temporary files, changing into directories, stuff like that. Right?
Speaker 1:Oh, you mean, you you could you could, always wrap the context you get from the test with your Yeah.
Speaker 2:Yeah. That's what I mean. Like, you get the t dot context, and then you create a new one from it with your, needed key values for the test. Right. I'm wondering if I have a test today that just creates a context dot background, I'd probably want some linter to let me know that, hey, you should consider at least using t dot context.
Speaker 2:Because if I don't care what context I pass in, then I should like, it's cleaner code. Right? I just use something from t instead of just using, whatever, but instead of using that context dot to do. But on the other hand, I read the tests. I can't copy paste the code out of tests into main.
Speaker 2:Right? Because in main, I don't have, t. So the the the test as the commutation is becoming a bit worse. But for the actual use case of cleaning up stuff, it sounds like a pretty useful proposal.
Speaker 1:I can actually also see this being quite useful anytime I start a goroutine in a test. Like, say, for example, I'm running an HTTP server in a test, I could use this can't this context to shut that server down at the right time rather than having to do my own mechanic to to do that.
Speaker 2:Oh, that's that's interesting as well. But if you share it between, like, is the context test specific, or is it
Speaker 1:for the whole process? So the documentation in the in the accepted, comment says, context returns a context that's canceled just before t dot cleanup is called. So, the test is completed running. It's either it's either failed or passed. It doesn't matter for this.
Speaker 1:The test is completed running, but the cleanup functions have not been called yet.
Speaker 2:Oh, I I understand.
Speaker 1:This is on a on
Speaker 2:a very low level. This is really cool. I I imagine, the use cases with, you know, running on GitHub CI or whatever where the runners always crash, or if you're running on your CI on Kubernetes and, you know, your job is getting evicted in the middle, actually having confidence that, okay, the pod failed, but that doesn't mean all our resources are are borked now and, you know, someone's gonna have to go in and and reset the image. That that could be like reset the container resources. That that could be really useful, but it it does require your code to actually support, you know, getting a context and using the cancellation thing correctly.
Speaker 2:Right? So if you don't have cleanup, working well for you right now, this is not gonna help you. You need to have that set up first. Exactly. But a cool a good proposal.
Speaker 2:Is it in? No. It it's likely accept.
Speaker 1:It's likely accept. So maybe next week or the week after, we'll have a a final word on that one.
Speaker 2:I think this is also again, this I say this every time, and then I look at the change, list, and I'm like, oh, I'm stupid. This sounds like a super easy thing to implement. Right?
Speaker 1:It it sounds that way. Although, the the test internals are kinda complicated, so I don't know. I wouldn't I wouldn't place a big bet on that, until I look at the internals of the test code.
Speaker 2:Alright. I'm wondering if it was implemented in the past already. Right? So we can even take
Speaker 1:that previous step. Revert the revert and and you're done.
Speaker 2:I love these commits the most and, like, you know, look at the main branch of your, of your project, like, revert revert revert revert commit or whatever. Cool. So, likely accepted proposal in a pretty slow, proposal week, as we're, prepping for, you know, a a big release coming up. So, Jonathan, I'd like to get your opinion on something.
Speaker 1:I would love to get my opinion on something.
Speaker 2:What's your sentiment about AI?
Speaker 1:Thanks.
Speaker 2:How do how do you feel about AI? Answer. So the Stack Overflow, developer survey for 2024, the results are out. I think about 3 months ago, we told people, hey. You should probably fill in that survey, and it was pretty long.
Speaker 2:I filled it in. Did you, hand in, you know, your results?
Speaker 1:I I filled in so many surveys. I forget exactly which ones, one, but I'm pretty sure I did. So first of all, 2 weeks
Speaker 2:ago, we had a really good interview. Right? You had a I should say you had a pretty good interview. I listened to it on the car. It was pretty nice, With Alice from the Go team, the person who, designs the user experience for, like, Go, right, on the Go team?
Speaker 2:Yeah. User experience, please. And they're in charge of the Go survey.
Speaker 1:Mhmm.
Speaker 2:This isn't that. No. It's the general Stack Overflow developer survey, discussing things like, you know, developer profiles, which technologies they use. Obviously, AI is a is its own tab, how people work, like workplace trends, things about community, things like that. This is a, again, as usual, a pretty big survey with tons of data.
Speaker 2:I'm wondering what insights you picked up that were interesting to you.
Speaker 1:So, have you looked at the, top ten technologies part yet?
Speaker 2:I I try I tend to not, look at that too much, but the most popular technologies, that does, you know, meet my day to day. So you look at the professional developers, JavaScript is way up there. Right? Because you you have it both in back end and in front end, and the rich library, ecosystem. And you have, like, SQL, HTML, CSS, and unfortunately, Python is still on top, and I had to scroll down quite a lot to find Go at 14.4%, below PHP and below c plus plus below c sharp, below Java, and below Bash.
Speaker 2:Although, I I don't know how people, like, can list Bash in the same list, but whatever.
Speaker 1:Well, I I was looking at the, the most highly paid technologies, and I I I think that's a good one to look at because it can help us feel really smug when talking to Rusters because Go makes more money than Rust. On average, $131 more per year if you do do Go than Rust. On the other hand, if you learn Pearl or Ruby, you're gonna make a heck of a lot more than doing Go. So I don't know if you actually feel that spot.
Speaker 2:I always look at this, metric, and I'm, like, wondering how what's the relation of that metric? How much money you can earn as a software developer that that is specialized in x or y, versus my experience, which has been more of, like, pick up a bunch of technologies and use whatever fits. Yeah. Like, I can't imagine presenting myself as a as a Go developer, even though I'm pretty into Go, because I know Python, and when I have to use Python, I'll use Python. And I know Rust, and when Rust is a better fit, like, if you don't need to do async, because async rust is pain, and, you know, you really care about performance and correctness because, I don't know, you're running on you don't wanna crowd strike, you don't wanna pull a crowd strike, then it's a good fit.
Speaker 2:And when you just wanna be productive and have the language mood up move out of your way, and you can afford a garbage collector, sure, go. I I'd pick with go as my default. But what I've found is at some point of, like, like, your level or your journey as a software developer you know, if we if we're talking about, like, Google and things like that, you know, how they have, like, L5, software engineer, L6 software, like, more high level software engineering, jobs, more senior, the language sort of fades into the background. Like, you pick a good technology, you wouldn't work with a bad technology, but that's not defines, well, how you make money. So I don't understand how this how this, number works.
Speaker 1:So I I think they just asked, 2 questions, and this is sort of a a cross section of that. What languages do you use, and how much money do you make? So each person is likely in more than 1 bucket in this list, and and I think that's pretty clear when you consider that Bash is its own thing. Like, nobody's gonna call themselves a Bash developer. At least
Speaker 2:I don't know. Maybe some DevOps people mostly hack together, you know, Terraform and Helm using, Bash. You can you can make
Speaker 1:it work. Maybe so.
Speaker 2:We have a a Bash script at work, that, one of my team members developed, that evolved to the point of, like, working with dictionaries in Bash.
Speaker 1:Oh, yeah.
Speaker 2:And I'm I'm horrified to see that it still somehow holds up, and we haven't migrated to Go yet. There's obviously the admired and desired, chart, which you can, you know, see every now and then. It's very confusing. I'll try to explain it.
Speaker 1:It's very confusing.
Speaker 2:The the the desired number means which language have you done extensive development work over the past year, and you wanna continue next year. Right? So, it's how much I, like it now, basically, and how much I wanna continue working in it in the future. And what you see is, first of all, a really in a in a glaring statement about the human condition, the admired, is always always higher than the, desired. Like, people say, oh, I really, really love Rust, but only, 82% of people say they really, really love Rust.
Speaker 2:Only 28, percent use it. So it's like a or or desire to use it, I guess.
Speaker 1:I have to interject. I I think this labeling is completely wrong. Desired is fine, or I'm sorry, admired is fine. I don't know. These labels are just so confusing.
Speaker 1:The actual questions that are asked are, which of these languages have you done extensive development work in over the past year, and which ones do you want to do next year? So, like, the lower one, I I guess that's that's called desired. That's really more like have used, and then admired is want to use.
Speaker 2:This is sort of reminding me of your rant about, what's the, NPS? Like, you should just ask, have you used, and are you planning to continue using and then not label it any more confusingly? But anyways, as usual, Rust is really high up on that list because I think many people used it, but not for async work, and then like, or a really big project. So they're just familiar they're right before the huge, learning curve slash the wall. Go has a pretty good score here as well.
Speaker 2:Right? It's, top 10 on the list, 23% desired and 67% admired, which, you know, if you compare it to, let's say, JavaScript, JavaScript is, more desired but less admired. So people use it more but like it less. And it's really funny also to go down the list and see some very niche languages, and then just see some things that people don't like. Right?
Speaker 2:Visual Basic, just people don't admire it and don't desire to work in it more.
Speaker 1:What what I wanna see on this chart, which this chart does not demonstrate, is which languages do people use but not want to use? I wanna see the ones that have like, people are forced to use them, but wish they didn't have to, if you know what I mean.
Speaker 2:Yeah. So, obviously, there's the language, bashing, you know, there's, the IDE wars, right, with the Visual Studio Code, by the way, being the clear victor in this race.
Speaker 1:Is it though? I've been having so many problems with that lately. We'll save that conversation for another time. Yeah.
Speaker 2:Well, we can do editor wars on another time. And, again, with a really good case of, close desired and admired, you have a Jira on top of, like Jira and Confluence on top of the async tools. You know, every time people try to use it, they're like, oh, I hate Jira. I don't like it. The Discharge shows it.
Speaker 2:But people like monday.com less or Asana or ClickUp. I don't know, by the way, what these companies have done. They probably bugged my house or something, but every single YouTube ad that I get is like, oh, sick of Jira? Check out ClickUp. What if funnily enough, you know, everything, old is new again, and we're rediscovering everything.
Speaker 2:Do you wanna venture a guess of what Async Tool, got the highest admired score?
Speaker 1:I have to even know what that means.
Speaker 2:The Jira, Notion, Obsidian, Trello, Wikis Okay. So we're
Speaker 1:talking like like under the broad umbrella of, like, project management stuff.
Speaker 2:Yeah.
Speaker 1:Which one got the what, the best score?
Speaker 2:The highest, admired score. So, you know, equivalent to, like, oh, I wanna work in Rust is I wanna
Speaker 1:Okay.
Speaker 2:For Async Tools.
Speaker 1:I don't I have no idea.
Speaker 2:Markdown files.
Speaker 1:Markdown files.
Speaker 2:Everything old is new again. Yeah. Awesome. Next up on the news, we have discovered networking. Like, I don't there's a really complicated and beautiful, visualization here, which I don't understand, by the way, which is, worked with versus wanna work with.
Speaker 2:So, you know, it says basically that 6 I don't know. Let's look at SQL, for example. Right? 10,000 people who worked with SQL want to work with Python, and here, you know, this is really weird because you have SQL and Python, and people are like, oh, I really, really wanna work in a ton of different languages. JavaScript has the biggest slice, and, you know, they wanna work in in many, many different languages.
Speaker 2:There's a big, highway, between JavaScript and TypeScript, like, people wanna move to TypeScript. But if you look at Rust and Go, people who work in Rust and Go don't wanna change languages. The it's like, in this graph, when you hover over Go, there's no way to change to another language, same with Rust. So, you know, people, once they get to Go over Rust, they tend to stay there.
Speaker 1:Oh. We had some technical difficulties, but we're back again to round out the episode. What?
Speaker 2:So overall, the Dhirv survey, you know, it has a lot of responses. Right? Many people answered. I don't know if I gained any new insight from looking at the the results, though. They're pretty similar to previous years.
Speaker 2:I think super surprised me. Honestly, you know, I think maybe salary information could be useful if you're hunting for a job right now, because the market had a pretty rough reset. So it could give you a good ballpark of what, salaries to to ask for or something like that, but I don't I haven't found any, immense value in the, in the insights. You know, JavaScript is popular. Like, alright.
Speaker 2:Jira is still top of, of the list. Okay. The one thing, you know, that's different this year is all about AI. Right? AI search and developer tools and and using chat gpt and tab9, and people like it.
Speaker 2:And, you know, what's the top end technologies? Okay. It may like, Erlang is is highly paid, and many people plan to use AI tools. So, you know, these are just things that are sort of in the I I feel like I I knew already. I don't wanna have on the survey.
Speaker 2:Like, if the survey is saying true things, that's at least good, but I I don't understand what's the value in it, at least for me when when looking at it.
Speaker 1:Well, I I think that I mean, like you said, I haven't learned anything earth shattering from this, but I think I see a trend that Go has reached a type cycle and is on it, and is entering the mainstream language phase of its of its life. You know, 4 or 5 years ago, it was at the top of the everybody wants to learn Go. Nobody's tried it yet. It sounds super exciting. Rust is kind of in that spot right now, and and there's always a Zig is probably gonna jump to that point in the next couple years.
Speaker 1:So there there's a hype cycle around languages, and I think Go is on a downward trend. That's not a bad thing. It's a more mature language now. More people are using it, so there's fewer people who are in this sort of aspirational phase. But it's interesting to watch that happen.
Speaker 2:Yeah. I think once you're in a hype cycle, you sort of need to, reach escape velocity. Right? You know, to Yeah. Actually turn into a, a mainstream language, because you can be in the hype cycle and then, like, burn out and do just crash and burn.
Speaker 2:Again, the the different thing about, the results here are mostly about AI tooling and things like that. One of the one of the things I I like is that most professional developers do not perceive AI as a threat to their job. I am firmly in that camp. It is a sometimes useful, tool right now. And I I'm I'm wondering, like, if AI safety regulations and things like that are
Speaker 1:gonna pretty much keep it at the current level that it's at, for the next, like, few years. I'm not an expert in AI. My my my personal feeling is that we kinda with with, chat gpt and and that whole, generation of new tools, we kind of made it over a bump, but I don't I I I think we're I think it's a bump, and I think that's it. I don't think we're gonna, like, soaring off into the into the sky with new AI stuff that's gonna revolutionize. Right?
Speaker 1:I think we've already seen the big the big change, and
Speaker 2:There is one. Yeah. Yeah. For sure. I I I definitely I haven't heard of anyone who's getting replaced a 100%, like, a professional software developer.
Speaker 2:I think it is harder to be be a junior right now. Right? Because 1 or 2 projects on your GitHub page that can be immediately generated with AI, that's not good enough. There is, satisfaction and job satisfaction, by the way. So if you're, in a leadership position, like, you're a team lead like myself or a group manager or whatever and you're listening, I think the, like, product activity impacts and developer experience part of the survey is interesting.
Speaker 2:Like, I'm the the team lead for developer experience. So that particular tab, you know, I'm gonna be sharing in Slack and talking about. This survey is by, Stack Overflow. Right? And the only actionable clickable button on the survey is their product page, where you can buy, soft Stack Overflow for teams.
Speaker 2:So, you know, when they look at productivity impacts, and then, the first question is ability to find knowledge and information within their organization, that doesn't track with the things that, you know, I've learned about developer experience and things that the Dura research team shows and things like that that are, like usually, this is this is not the top, contributor, driver, or predictor of, productivity in an organization. To see that, look if you're using Python or Go, and then you'll, you'll have a pretty good idea. So that's the dev survey. You can, But I think that's a program. Yeah.
Speaker 2:We can you can squabble about the results and, you know, is Versus Code actually good or bad and, you know, come fight Jonathan in our Slack channel. So I think it's a good chance to sort of let people know where they can reach us. So where can they reach us?
Speaker 1:Yeah. The Slack channel is a great place. Capago.dev is also a great place. It has links to all of the other places you can find us, our social media accounts. Email, I think, is even there.
Speaker 1:If you wanna email us, you can do that. Mhmm. News@capago.dev. Yeah. Yeah.
Speaker 1:You can become a Patreon, supporter and provide a little financial support to help cover the cost of the show, or you can share the link with your friends and colleagues.
Speaker 2:Yeah. I really wanna highlight our Patreon support as a a way to make the show sustainable and actually take a part in the community. If you can kick, $8 a month and you think, it's worth it, this is just the most direct way to, support us making the show. Kicking in $8 a month to make sure that, we can continue doing this, and not worry too much about costs, that's the best way to support us.
Speaker 1:Don't tell me next time.
Speaker 2:That, that's the show. Program exited. Bye. Program exited. Goodbye.
Creators and Guests
