go fix your stack allocations in preparation for TypeScript 7
This show is supported by you.
Jonathan Hall:This
Shay Nehmad:is a Cup o' Go for Friday, March 13, 2026. Keep up to date with the important happening in the Go community, in about twenty minutes per week. I'm Inamar, and I'm that's ten years shy.
Jonathan Hall:And I'm and that's shy.
Shay Nehmad:And I'm I'm feeling pretty bad at this.
Jonathan Hall:And I can't
Shay Nehmad:hear you, Jonathan. But yeah. Yeah. That worked great.
Jonathan Hall:That's good.
Shay Nehmad:We might include it in the in the bloopers. Mom, I'm on TV. Alright.
Jonathan Hall:So we're we're gonna keep this a minute. We we will keep this in the show, by the way, because that's a perfect segue. My son was on the radio this week, and he was so excited.
Shay Nehmad:Oh, wow. What did he do on the radio?
Jonathan Hall:His preschool class took a field trip across the street to the local radio station and they recorded a little, like the whole class sayings. I don't even know what they said because I couldn't understand it, but the whole class recorded a little thing. Son was so excited. He was on the radio. He doesn't know what the radio is.
Jonathan Hall:Like, he was like, what what's the radio pop up? I'm going to a radio station.
Shay Nehmad:That's so cool.
Jonathan Hall:Yeah. It was a fun time.
Shay Nehmad:Radio is fun technology. We should bring it back alongside blockbusters.
Jonathan Hall:We could maybe we can become radio DJs.
Shay Nehmad:Oh, I could definitely. I listened to my favorite San Jose station. Shout out to one zero seven dot seven, The Bone on the San Jose FM radio. You guys are awesome. I I highly doubt that any of the one zero seven dot seven FM The Bone are listening, but if you are, babe what's your name?
Shay Nehmad:Baby Zach or something like that? You guys are awesome. Woah.
Jonathan Hall:All right.
Shay Nehmad:Yes. So first of all, this show is supported by you and we'll get more into that in the ad break. Thanks a lot to all the new Patreons this week. We've done a big wave of support. We really appreciate it.
Shay Nehmad:But let's start talking about news. Usually, cover proposals, but I noticed they're they're lacking from our from our cards today. What's what's going on?
Jonathan Hall:There is a huge backlog of proposals that are almost accept. So I think next week, we'll have a lot to report on.
Shay Nehmad:Yeah. But we want to wait until they, like, cement so we don't, you know, cover them, like, 90%, and then, well, next week, we have to do errata fixes.
Jonathan Hall:Yeah. Yeah. We we we hate fixing our things. Hate we
Shay Nehmad:hate go to fix our things.
Jonathan Hall:Alright. What's up first?
Shay Nehmad:Foreshadowing. Foreshadowing. So first of all, wanted to follow-up, you know, we had an episode on Go vulnerability research. That was 05/03/2024. And yesterday, you know, someone pointed out that, you know, at the time of the interview, our interviewee, Bartek and Yarden Laifenfeld, that made it happen, you know, they talked about Go Vulnerability Research and how much is it worth and specifically how little the economy pays for a bug.
Jonathan Hall:Oh, yeah.
Shay Nehmad:And Yarden pointed out that governments buy zero days. And at the time of the interview, he thought they were buying them to fix them. But since then, has been made aware that the zero days are also on the market for exploitation, which I thought I don't know. To me, it was obvious, but I know, maybe to you it was surprising.
Jonathan Hall:I I never thought about it to to be surprised one way or the other, I guess. But
Shay Nehmad:Yeah. So, like, if there's a market for zero days and and governments are buying them, to me, makes sense that they might buy them for exploitation and not only for fixing just because Sure.
Jonathan Hall:You
Shay Nehmad:know, they have the same incentive as anybody else who's buying Either they wanna protect themselves or they wanna gain an advantage. So, you know, there are two articles here about it. It's not related to Ghost specifically, so, you know, we're not gonna talk about it too much. But if that episode interest interested you and that interview interest interested you, you can talk to Yanik about it here on the on the Slack thread. And it's a good opportunity to bring out an old episode.
Shay Nehmad:We usually don't do that, but episode number 61, that was a long time ago. But I
Jonathan Hall:still don't know. Tripper.
Shay Nehmad:Yeah. Well, yeah, it was 2024. So, episode number 61, we talked with, biotech no Nootarski, if I'm saying that correctly again, about Go Vulnerability Research. And now, like, there are more thoughts about it. So interesting.
Shay Nehmad:Cool. But under that, we have a few new blog posts on the Go Blog, which is always a nice resource.
Jonathan Hall:What's the what's the first one on this day?
Shay Nehmad:Nice. You know what? I'll put aside some space for for that one. Oh, but do you have another one?
Jonathan Hall:I I do have another one. Yeah.
Shay Nehmad:Oh, now I need to drop that list and create a new one because I I only had room for one, but I need room for two. Anyway, so the first post is about optimizing allocations. Generally, you know, one of the benefits of Go is that it's fast, right? Like when people think about programming languages, they're like, oh, Python's slow, Go fast. But that doesn't just happen, you know, because of intrinsic the intrinsic qualities of the language.
Shay Nehmad:It's like not all compiled languages are fast. You know what I mean? Mhmm. One of the things that I've seen the Go team do again and again is make very pragmatic decisions to make the language faster for the general case, right? Just for general audiences.
Shay Nehmad:For example, we covered a lot green tea, right? The new garbage collector. But green tea works on stuff that's on the heap, and sometimes it's faster to do stuff on the stack. I'm I'm not gonna explain what stack versus a heap is. I hope the listeners know.
Shay Nehmad:If you don't, maybe pause the episode, go learn about it if you're, like, just a student or whatever. But I assume our listeners know what stack and heap are.
Jonathan Hall:Is it just a student, like, that's some sort of lower class thing? Like, I'm I consider myself a student all the time.
Shay Nehmad:Yes. I mean, a student as in first year of a university or whatever. Maybe high schoolers. I don't know. Maybe we have, non adult listeners as well.
Shay Nehmad:Eat your, eat your homework. Do your vegetables. Anyway, the Go team has been working on ways to do more allocations on the stack, and actually their example in the blog post is really, really good. So let's assume we need to allocate a slice of tasks, right? And I wanna process them.
Shay Nehmad:So I'm getting a channel of tasks. I don't know ahead of time what's the size, right? Right. So it's kind of hard to optimize. And then I'm starting to range over the channel and collecting tasks from the channel until I'm done, and then I have a a slice of tasks.
Shay Nehmad:Is the is the workflow clear? I define var tasks, and then I range over the channel, and I just append whatever I'm getting from the channel into that list, into that slice, I mean. How big should I make the store for tasks in your opinion?
Jonathan Hall:Oh, it would depend on how much knowledge I have about tasks beforehand. And I would
Shay Nehmad:try So you have none, you just know If that there's a
Jonathan Hall:I have literally none, I mean like about the domain knowledge, not about the specific like runtime, like domain knowledge. Like if I know that tasks generally is between zero and three things, then I probably set a gap of like or a length of three. If I know that it's likely thousands, then I'm gonna do more.
Shay Nehmad:Yeah. That's the first thing the blog post says. Like, if you don't define anything, it starts with one and then jumps to two, and the old one is garbage, and then from two it jumps to four, and then the two is garbage, etcetera, and then it jumps to eight, and again, now there's a lot of it doubles the size of the allocation each time it fills up, and generally it causes a lot of overhead in the startup of this task. If this is a really hot part of the program, you might just like decide to switch out and just start with a bigger slice. So instead of just making a empty slice and then it starts with one, you call make and you're like, oh, it's probably like 10 items or whatever.
Shay Nehmad:That's a pretty reasonable optimization. Surprising thing about that optimization, we're like, okay, I'll I'll define, I don't know, size of 10 to get rid of that, like, startup cost, especially if So this is something, again, that happens a when I change it to make, how many allocations do you think I'll have? Assuming like usually there are at most like, I don't know, eight tasks or whatever. Before we had the first allocation, right? Yeah.
Shay Nehmad:When when we just allotted the stack, and then when it jumped to two, there was the second allocation. Then when it jumped to four, we had the third allocation. When it jumped to eight, we had the fourth allocation.
Jonathan Hall:Right.
Shay Nehmad:When I call make and say, oh, it's it's probably 10, and it is really, like, probably 10. How many allocations do you think I'll get?
Jonathan Hall:I guess I would expect one, but since since you're asking me the question, that must be the wrong answer.
Shay Nehmad:That is. The surprising thing is that if you benchmark this code, you didn't reduce the number of allocations to one, you reduced this to zero. Because it knows what size it's gonna be, the compiler can put it on the stack instead of the heap. And what they're doing in this blog post is going to through how Go 125 basically can optimize and know when to do stack allocation, even if you don't give it any information ahead of time. So even if you don't let it know, you know, how how much, you're gonna need, it figures out a way to do it automatically using a thing called move to heap.
Shay Nehmad:So it starts on the stack and then moves it to the heap before it returns it from the function. That's a Go 126 thing.
Jonathan Hall:Where's the limit? Like, what what size would it automatically go to the heap? Like, would it make with the size of 100 or 50 or 1,000 or something? Is it going to the heap correctly?
Shay Nehmad:So you don't need to, you know, add this like length guess. It does a speculative backing store on the stack until, I think until four. And then on the fourth iteration, the stack backing is full and now it's moved to the heap. Got it. So you don't do heap allocation for size one, two and four.
Shay Nehmad:And then that also means you don't create any of that garbage. So the garbage collector eventually will do a lot of work.
Jonathan Hall:So it's essentially And if most
Shay Nehmad:of your slices are small, maybe you'll never have a heap allocation.
Jonathan Hall:Yeah. So it's essentially free to do, like, mega size up to four, but it's kind of also automatic now anyway.
Shay Nehmad:Yes. Because what it does, it it creates the problem is, let's say you create this you know, you consume all the tasks from the channel, right? And again, tasks is just an example, it can be anything.
Jonathan Hall:But
Shay Nehmad:you put it on that slice of tasks, but that slice of tasks is on the heap and you're in a function and then you wanna return that slice of tasks, right? It's a super common operation. Take a channel, consume everything from the channel until you're done and then return it on a slice because I wanna do something with it. What's the problem now that it's happening on the stack?
Jonathan Hall:It's only accessible within that that local scope, right?
Shay Nehmad:Yeah. It can't be returned because it's on the stack. Then when I pop out of that function it's a little bit low level, but you pop out of the function, you lose the stack. That's how functions What they're saying is they, in 01/26, the compiler adds a runtime dot move to heap function right before you return, so you can return stuff that's on the heap, that's on the stack, and it'll happen automatically as well. So even if you return it from outside the function, it's not gonna start with the old method of doing it on the heap and creating all that garbage.
Shay Nehmad:It's gonna do it all on the stack speculatively. And if successfully you avoided all of it, you just move it to the heap once, which is, again, like, it's actually better than hand optimized code, because it doesn't need the extra allocation and copy, only if you've done a stack backed slice and you return it, which is really cool. These are compiler optimizations, so ideally you won't notice them at all, but we'll just get a blog post from the Go team, like saying, oh, we saw this improves that code base and this code base by x and y percent. I think for the normal use case of Go, normal, I mean, like the common of like, you know, network services, web services that deal with like network request in a highly concurrent way, this can actually be super big. And I wonder if this is gonna change the way I design Go programs to like, oh, maybe deal with smaller things almost by definition.
Shay Nehmad:Like try to not handle more than eight things at a time just to make everything go faster and never use the heap. Don't I know if it's actually a smart optimization or should I just program normally and assume it's gonna be okay?
Jonathan Hall:I I I mean, I think generally, you should just program normally and only optimize when you see a problem.
Shay Nehmad:Yeah. That's for sure anyway. So a super cool blog post. I I recommend you read it. It's very, very cool.
Shay Nehmad:If this one is causing negative performance issues for you, you can turn it off. There's a flag you can add to the compiler, but they do say if turning off this optimization if you turn it off and it helps your performance, they ask you to file an issue so they can figure out, like, why, because this is supposed to be strictly better. Yeah. Very cool blog post. What else is is on the docket for from the GoDev blog?
Jonathan Hall:Let's let's move on to Microsoft's blog post. Oh, actually, no. Before we do that, wanna talk about something else. Let me inline this this other topic first.
Shay Nehmad:Nice. Nice. Nice.
Jonathan Hall:Alright. So this was just published a couple days ago on the tenth from Alan Donovan. It's about GoFix. We've talked about briefly on the show before. And I think you brought up a concern about GoFix inline.
Jonathan Hall:The idea that you could like, you have a function you've defined in your library and it's now obsolete, you want to replace it with something else. You can put a go fix inline directive, especially if I'm writing a comment on that function. And if a person runs go fix, it will replace that function in their code with whatever's in your function. So it inlines that function into their code. And I think you brought up a concern about possible attack vectors here.
Jonathan Hall:Am I am I remembering correctly?
Shay Nehmad:I was concerned. Yes.
Jonathan Hall:I wonder if you could reiterate that concern because I'm I'm wondering if maybe this blog post addresses it.
Shay Nehmad:My concern was, you know, you add a GoFix, like, inline and you can introduce a supply chain problems through it. Right? Because I could say like, oh, inline a thing to my function and my function is like malicious or something like that.
Jonathan Hall:Right. Right.
Shay Nehmad:That was my that was my concern.
Jonathan Hall:Those are concerns. But I
Shay Nehmad:guess it's not a real concern because if library is malicious, you can add it anyway. You don't need the GoFix trick to do it.
Jonathan Hall:Since I this is
Shay Nehmad:guess it's not valid.
Jonathan Hall:Yeah. And since this is strictly inlining, it's already code you are already executing anyway. It's just being inlined, right? So, it does a lifted chip. Like, it takes the thing that you're already calling and executes it directly rather than calling it from a certain function.
Jonathan Hall:So, I don't think that's a particularly valid concern. But
Shay Nehmad:It's not, it's not.
Jonathan Hall:This blog post really, I kind of knew this existed and I've used it before through Go Please without realizing it was all the same mechanism. But what this blog post does is it talks about how source level inlining works with Go Please and Go Fix. And it is kind of cool. Mean, it's actually there's nothing earth shattering in here. It's just kind of nice to see it laid out in a way that makes sense.
Jonathan Hall:And I did learn something from this. You can do Go Fix inline on non functions as well. You can do it on constants, type aliases and so on.
Shay Nehmad:Why would I want to do it on a constant? Like if I rename the constant?
Jonathan Hall:If you rename it or you move it to a new package, for example.
Shay Nehmad:Oh, oh yeah, that makes sense.
Jonathan Hall:Then you don't have to like go through mechanically and change every color. You just put go colon fix inline right above your concept definition, which is go const x equals other package dot y or whatever, and and then run Go fix and boom, your whole code base is six forty. The other really cool thing about this blog post, and maybe I've just been sleeping, but this is the first one I've seen with color in it. There's some colored and there's like colored texts where it shows, like, old and new and look like green and and red, diff syntax. So it's kinda cool in that regard.
Jonathan Hall:So just go look at it. Even if don't read it, just go look at the pretty colors.
Shay Nehmad:I I like it. I think it's, I I'm glad that the back end team at GoFundly discovered CSS.
Jonathan Hall:Way to go, guys. So
Shay Nehmad:developer? Should I worry about this if I'm just a normal developer? Will this just work out of the box for me? Like how does that impact my day to day?
Jonathan Hall:Yeah, so I think there's two ways that you can look at this. The first is as a consumer, you can just maybe become accustomed to running GoFix occasionally. Maybe every time you upgrade to a new version of Go or a new major version of a library, run GoFix and it'll modernize your code.
Shay Nehmad:Would you add it as a pre commit or is that unnecessary I in your
Jonathan Hall:probably wouldn't, but maybe, what actually what I would probably do for my taste is maybe add it. Remember last week we talked about running your Go security updates every night, you're upgrading all your dependencies running it. I might do something like that maybe once a month or once a week, have a CI job that just runs and does a GoFix and reports if anything's changed. Maybe I'll do something like that.
Shay Nehmad:That's interesting. Like, yeah, just keep it on like the tip and whenever you do a release, bring in all these changes. Ideally, all these changes are a 100% harmless, right? Like
Jonathan Hall:just running GoFix
Shay Nehmad:shouldn't it's like Go format. It shouldn't really matter.
Jonathan Hall:Yeah, so they're virtually well, it's even safer than Go format in a sense because it's working at the AST level. I guess Go format does too, but Go format can mess up comments and stuff. But like if you ever in your IDE Versus Code or whatever, if you like right click and do inline function, you're doing the exact same thing. You're exercising the exact same code path, which is one thing I didn't realize before it was Post. So that capability is built into Go, please, and is exposed both through Versus Code and through now GoFix.
Jonathan Hall:The other answer to your question, like if you're a library maintainer, should you worry? I wouldn't call it worrying, but this is a new tool at your disposal for deprecation of old things. So, you've rewritten the function signature or something like that, this is one way you could encourage the users of your library to update to newer syntax.
Shay Nehmad:Cool. Well, generally, the more automated fixes we can do, the better in my opinion. Agreed. Anything that can make that easier is nice. Now, after you're in line, going back to the Microsoft thing, now that we're out of the in line, although it's not really inlining like compiler inlining.
Shay Nehmad:So I take take offense with your joke. A small non Go related release in a different language, but wait, bear with me. I promise it connects to Go at the end.
Jonathan Hall:I'm about to take offense at your other language. Go ahead. Don't worry.
Shay Nehmad:It's not Python. It's TypeScript.
Jonathan Hall:Oh, okay.
Shay Nehmad:It's not Python. The learning language was invented just to learn programming. It's TypeScript. The lipstick they put on a pig that is called JavaScript, which is a browser engine, which for some reason is the number one backend engine here in the Bay Area. Anyway, TypeScript six was released.
Shay Nehmad:TypeScript six is the newest version of TypeScript.
Jonathan Hall:RC. TypeScript six RC is released. Right?
Shay Nehmad:Yeah. Yeah. Yeah.
Jonathan Hall:So it's not officially done yet, but the first RC is.
Shay Nehmad:It is the last TypeScript compiler that is based on JavaScript. The TypeScript seven, which is already, I've tried to play it around with, it's not working that well, but for my project, which is a relatively complex, like real, you know, multi library, dependency heavy, a lot of typing, a lot of interfaces, a lot of edge cases sort of code base. But TypeScript seven is very interesting because TypeScript seven is 100% Go. We talked about this on the show when they started working on it, like almost a year ago, I think. But yeah, they're implementing the TypeScript compiler in Go.
Shay Nehmad:So what's why am I updating on TypeScript six if TypeScript seven is the Go release? Is because the whole reason they're releasing TypeScript six is just to make sure that it's compatible to seven. They wanna make their migration easy.
Jonathan Hall:So this is a Go compatibility
Shay Nehmad:Honestly, it is a Go compatibility shim release. Very, very cool. Actually, I mean, technically, working on this stuff, I think, is very cool, just writing all these compilers, transpilers, and whatever.
Jonathan Hall:That mean that TypeScript seven will not have new features? It will it will be feature compatible exactly with six, but just for okay.
Shay Nehmad:That's the idea of pushing forward. The the feature will be that it's it'll be so fast that the workflow of, you know, that I'm working with right now, which is like write some code, then run TSC, wait for a few seconds and see if you may if you did something wrong will completely change because you could compile the entire code base, you know, on every character type because it's just so fast. I think at least for my workflow where, you know, I'm sometimes still typing by hand, but a lot of the things I do are agent based. Like, I hope I would be able to connect the TypeScript seven LSP directly to my, like, cloud or whatever. And they, instead of generating a lot of plausible looking code and then seeing all the errors and then adding on top of it as unknown as to silence these errors and hoping I don't notice, you know, they would be able to get that feedback immediately.
Shay Nehmad:But it's just a way faster. I think it's like a 100 times faster compiler. So it's different. Again, not TypeScript six, TypeScript is still JavaScript, still super slow, but, you know, this is basically a foundation for TypeScript seven, and with TypeScript six being a precursor to it. I am planning, you know, not right now, but when TypeScript six becomes a little more stable, like not the RC, I'm planning to move to it at work, a 100%.
Shay Nehmad:I tried to move directly to TypeScript seven and being an early adopter, but it just sorta didn't work. It was still too early. Like, I actually did it the week we reported on it, so I think it was like six months ago or whatever. It wasn't ready yet. Hopefully, it'll be ready soon, but I think it's cool.
Jonathan Hall:Pretty cool.
Shay Nehmad:That's all the news items we have for this week. We have a lot more in the backlog, but you know how it is. We just don't have enough time. Maybe we can inline some of them next time.
Jonathan Hall:But I
Shay Nehmad:don't We
Jonathan Hall:can allocate our our backlog better.
Shay Nehmad:Yeah. For sure. I don't think that would make for a good listening experience. I think people actually like talking like hearing us talk about whatever. Let's move to a quick ad break.
Jonathan Hall:This week, we have a big shout out to three new Patreons. We'll get to that in just a second. First off, if you're not a Patreon yet, we'd love to have you. You can support the show financially to help pay for editing and hosting fees. You can also support the show less financially by just sharing the show with friends and colleagues and neighbors and anybody else.
Jonathan Hall:And maybe buying some swag. We have a swag shop. Head over to cup o' dev, there's a link there. You can buy mugs, you can buy t shirts, you can buy stickers, other fun things like that. We have a rating and review for the show.
Jonathan Hall:Thanks for listening. Join us on Slack. We're on the go for Slack in the Cup o' Go channel. Did I get through it fast enough?
Shay Nehmad:I think so. I think so.
Jonathan Hall:Alright. Alright. Tell us about the new Patreons.
Shay Nehmad:I'm sure Josh Bleecher Snyder appreciates us going through the head very quickly because I know he hates this part. But, Josh, listen. Filippo Valvassori Bolg, Alessandro Arzili, and Eric Tang. Man, folks, thanks a lot for joining our Patreon. You in very one week.
Shay Nehmad:I I don't know. For me, it's, very exciting.
Jonathan Hall:It might be a record.
Shay Nehmad:I think probably the week we released the Patreon, we had a big influx of people joining, but it might be a record other than the initial week. And we really appreciate all three of you for jumping on the show. If there's anything, you know, you'd like to let us know when you join on Patreon, you actually have a little survey thing that you can can tell us what you want, but you can also just tell us on the Slack channel. We really, really appreciate
Jonathan Hall:One last thing before we close out the episode, a reminder, Trey's gonna be out of town for a while. I'm still looking for co hosts.
Shay Nehmad:I really freaking hope so, because right now flights are not looking pretty.
Jonathan Hall:Fair. I I have enough volunteers, but some of them are repeat volunteers. So this isn't a guilt trip. Still have a show if you don't sign up. But if you would like to be a co host for the first time, reach out to me.
Jonathan Hall:I still have two slots to fill in April. So if that sounds interesting to you, don't hesitate, send me a message.
Shay Nehmad:Cool, cool.
Jonathan Hall:I think that's it.
Shay Nehmad:All right. Program exited y'all. Program exit up. Goodbye.
Creators and Guests
