Cup o' Go

★ Support this podcast on Patreon ★

Creators & Guests

Host
Jonathan Hall
Freelance Gopher, Continuous Delivery consultant, and host of the Boldly Go YouTube channel.
Host
Shay Nehmad
Engineering Enablement Architect @ Orca
Editor
Filippo Valvassori Bolgè
Sound Designer / Audio Editor based in Milan

What is Cup o' Go?

Stay up to date with the Go community in about 15 minutes per week

Speaker 1:

This show is supported by you. Stick around to the ad break to hear more. By me. This is Kafka Go for March 1, 2024. Keep up to date with the important happenings in the Go community in about 15 minutes per week.

Speaker 1:

I'm Shayne Ahmad. I'm Jonathan Hall. Let's jump into it. I have nothing funny to say and we have a ton of news.

Speaker 2:

Let's go. Go 1.22.1 and 1.21.8 have been preannounced. They're coming out on Tuesday. Security releases, we don't know what they are yet.

Speaker 1:

We'll tell you next week. In related news, protobuf also had a preannouncement, but the CV is withheld. So there there is a security fix, but we don't know what it is yet. So we promise we'll try to follow-up. We don't actually promise that we'll follow-up because who knows if we'll remember it.

Speaker 1:

I'll put it in our backlog so we remember, but we might forget we got If only we had some sort

Speaker 2:

of data storage device that could keep this information for us for a week.

Speaker 1:

Yeah. But if I don't know if how to make an efficient one. Do you know of any efficient one?

Speaker 2:

I've heard of this thing called Swiss table that might work.

Speaker 1:

Yeah. So I'm lactose intolerant, so probably not relevant to me. Cool. So there's a really interesting issue which just says runtime colon use Swiss table. It's from the ByteDance programming language team, which is interesting.

Speaker 1:

They basically say let's use let's replace the implementation of a hash map, which sounds like the scariest thing you can do in a language. Like take the most basic of the advanced data structures and the most advanced of the basic data structures and mess around with that. Mhmm.

Speaker 2:

Let's do it.

Speaker 1:

But what's a Swiss table? Why like, why would we even need that? What's the problem with the original HashMap?

Speaker 2:

So I can't tell you the difference of the, like, memory layouts and stuff. But, the motivations I can tell you about because I read the proposal. At at ByteDance, where you said this came from, they found that their Go services consume about 4% of their CPU on hash mapping. So the the goal is to improve that. I mean, 4% does seem like a lot for something so kind of basic and seemingly trivial.

Speaker 2:

Right?

Speaker 1:

So Swiss table is used by default in Rust and which is a c plus plus library thing, that I don't know. And the bite test team already borrowed like many ideas for the implementation from there. So it's not like a totally new thing that's like out of nowhere. Now this issue was posted in 2022 but it's super actively worked on. Like I just jumped to the bottom and it's like 15 hours ago, 12 hours ago, 6 hours ago, 3 hours ago.

Speaker 1:

Like people are really really working on it, trying to run benchmarks and for sure the Swiss option is running a lot faster. So there might be some cases that are slower, but overall it definitely looks faster and there's some bench stat results here that are super interesting to dig into. But, yeah, it it looks like it's in active development. So, you know, we might, we might see it's not in this version, of course. It's not a minor change.

Speaker 1:

It's it's definitely gonna be like, it's not a patch. It's it's a minor. Mhmm. But hopefully, you know, we'll know nothing from the outside. And from the inside, the language is gonna be a lot faster.

Speaker 1:

The link to the issue is in the show notes if you wanna dig into the details. They are interesting, especially if you're right now, you know, learning like data structures or something like that, maybe in university or maybe at your work. This could be a really good way to get hands on. Right? Jump on the poll request, add a test or something, improve the documentation.

Speaker 1:

Why not? I'm sure they they would love it. It's one of the more interesting proposals that I've ever read. It's too technical to go into in a podcast though. Like I can't start describing the memory layout in audio form.

Speaker 1:

I think even our most hardcore fans would be like, yeah, no. So if you're looking for an interesting read, the link is in the show notes. Let's talk about some releases.

Speaker 2:

Let's talk about some releases. So we have 2 projects that are, like, spiritual cousins, I guess. They're almost brothers that were both released this last week. The first is one that I'm a co maintainer of, Go for JS, which transpiles Go code into JavaScript. And be sure to stick around for an interview because we're interviewing the person who made this release I'm about to talk about possible.

Speaker 1:

It's one of one of our better interviews, I think. Super, radiophonic voice, thanks to COVID. You know it's a minor release of a library that I or like you know a whole model a whole package that I personally use like twice, but I'm not like Gofer. Js is not like a daily driver for me. And it's sometimes easy to forget how much work and like the the people behind these like, oh it's a patch release and something or a minor release and something.

Speaker 1:

So it was re it's really interesting. You'll you'll learn about like the entire momentum and the entire energy that was behind this release which looks small but it's actually a really really big one. Right?

Speaker 2:

This is a big release. So, a little bit of history. Go for JS versions follow Go versions, basically. So the latest stable release of Go for JS is 1.17, which implements Go 1.17. So you can compile Go 1.17 code to JavaScript.

Speaker 1:

But 1 17 is ancient.

Speaker 2:

It is. And the reason is because Go 1.18 is what added generics, and that has been a big chore getting that to work in Gopher JS. We're getting close, but we're not there yet. Meanwhile, we have released like, 2 years ago, we released Gopher JS 1.18 beta, which included all of the Go standard library support for 1.18 and all the new language features except for generics. Well, we just recently had in the last couple of months, somebody came along, Grant, who you'll be hearing about in the interview hearing from in the interview.

Speaker 2:

His company uses Go for JS regularly, so they have a vested interest in making it work. They asked him on his work time to update it to Go 1.19. So we now have Go 1.19 support in Go for JS, except for generics, which are still coming. Stick around for the interview for all those details. The related release is another project called tiny go, which you might have heard of.

Speaker 2:

It's it, compiles go, and its target is like embedded systems or systems with really limited CPU or limited, memory. And they just released version 0.31, which includes 1 Go 1.22 support. So I think it's really cool. If if you use Go in a sort of nonstandard environment, both of these releases, might be either or both of these might be relevant to you. If you use either these projects, come talk about it on our Slack channel.

Speaker 2:

I'd love to hear about your experience. There's any gotchas you have using either tiny Go or gopher. Js or any other implementations of Go out there. There are a few others that are maybe more partial or or less popular. Love to hear about those.

Speaker 1:

So the reason you say these, releases are related or these projects are related is?

Speaker 2:

Because they are alternative implementations of Go, and they target some of the same sort of use cases. And and in fact, tiny Go, and Go for JS have have some common code. Some of the same contributors contribute to both and have patched thing or, ported things from tiny go to gopherjs or vice versa.

Speaker 1:

Cool. Intertwined. Well, the new tiny go release does support 122. So it's it's, like, more advanced. Right?

Speaker 1:

But its runtime requirements are easier. Right? Because it's it's not supposed to run

Speaker 2:

It's not running in JavaScript. It I do believe it can compile to WASM, same as the official Go compiler can.

Speaker 1:

For sure.

Speaker 2:

But I think it's a smaller, tighter WASM. There are some limitations of tiny Go. It doesn't have all of the runtime features that Go has. It's not as optimized in terms of, like, performance because it it has a very specific focus of being tiny, thus the name. Tiny as in compatible or tiny as in, compiled binary size and memory requirements and stuff like that.

Speaker 1:

I guess if you're it's a trade off you're willing to make. If you wanna use tiny go, then you're probably running it on, like, embedded systems or, like, tiny emulators or just using it to, like, bootstrap other larger software, then it's a good trade off. If you're at the point where you're struggling against tiny go, you should probably just use regular go and perhaps get stronger, hardware.

Speaker 2:

Yeah. Yeah.

Speaker 1:

Alright. So we did official releases. We did one the one interesting proposal we found, we did, releases. Now let's do some community stuff, starting with meetups. Before Jonathan tells about his Amsterdam meetup at least the highlights from there I wanna mention quickly that next week is the Orca go Israel meetup.

Speaker 1:

I'm I'm super excited because it's in my company and I feel like I arranged large part of it. I'm also working on the slides and I haven't done them yet, but they'll be done this afternoon. I promise. Do do if you listen, I promise I'll work with it. But, yeah, the slides are looking great.

Speaker 1:

There are 2 really interesting talks. 1 from, Leo Yacoviano works at the ORCA about some Go tools we use, Rego and Go Releaser, stuff we use like in production, you know, not just, things that are relevant for, enterprise context in Go and not just how to make the another HTTP server. And then there's someone who's gonna come, Nashon is gonna come and talk about intro to Kubernetes operators in Go. Which I think, you know, a lot of people whether they want to or not, need to learn more about Kubernetes. So I think that could be useful as well.

Speaker 1:

So if you're in Israel on Tuesday 6 PM at Orca Security, come along. Should be fun.

Speaker 2:

Awesome. How

Speaker 1:

was your meetup?

Speaker 2:

It was good. We had a a full house. We were hosted by, Creative Fabrica, as I mentioned last week. And they of course, they had the floor for one of the presentations, and they talked about how they use Go or how they optimize some image manipulation stuff in Go, comparing a c library with a Go library. It was an interesting talk about performance and and parallel computing and stuff like that.

Speaker 2:

But they ended the talk with an announcement of a a website, a tool. Is it a tool? A toy that I wanna mention. It's called tech.creatifabrica.com. Tech.creatifabrica.com is the Creative Fabrica Gopher verse.

Speaker 2:

It will let you create AI generated gopher images. It's been trained on a bunch of Go mascots and the official gopher, like, style guidelines, whatever those are. So you can, like, type in I I just did one. A go for listening to a podcast and drinking coffee, of course. And it created 3 or 4 little, they're not nearly as cute as Brewster, but they're cute.

Speaker 1:

Yeah. They're like Brewster's, cousins.

Speaker 2:

Yeah. Yeah. So go check that out. Go for verse, at tech.creatofabrica.com. Of course, link in the show notes, And send us your favorite gopher creation on the Slack channel.

Speaker 1:

They're cute. I really like the crochet amigurumumi. I don't know exactly how to pronounce it, but it's like a tiny doll, crocheted. Mhmm. AI is really good at generating this, like, texture of, like, someone, crocheted it.

Speaker 1:

So they're really cool. There's some interesting ones here. Recursive loop cartoon gopher, recursive gopher inside a gopher inside a gopher, Batman gopher. There's some interesting options here, especially the motorcycle one. They gave a specific model and I guess the underlying L.

Speaker 1:

O. M. Took it a little bit too far because it's just a guy riding a motorcycle with the go colors.

Speaker 2:

There's a lot of cool stuff here, though.

Speaker 1:

Yeah. For sure. That's a really fun thing

Speaker 3:

for

Speaker 1:

a meetup. Sort of digital swag toy thing.

Speaker 2:

And And and they were giving out stickers that were generated from this. So that was cool too.

Speaker 1:

So Less cool than our stickers, though.

Speaker 2:

Less cool than ours, but still cool. Yeah.

Speaker 1:

And there was go for watch you wanted to mention as well right

Speaker 2:

yeah so one of our other maintainers actually we've had them on the show before on an early episode Michel, who, authored, mock, the the mail server. I've linked to that episode if you're interested. But he's released a new tool called gopher watch, which lets you subscribe to sort of a a feed of Go module updates. So if you don't like Dependabot or its alternatives, and you'd rather get an email, you can just go to the gopherwatch.org, and you can subscribe to you have to log in, and then you can subscribe to, basically, notifications. And it watches the Go some database, the Go check some database.

Speaker 2:

So it gives you an update very quickly whenever a new version of your module comes out.

Speaker 1:

It's really cool. I really like the no CSS site. Yeah. That's more stylish than working on style at this point. It's just saying, like, I'm not gonna write a single line of CSS, deal with it.

Speaker 1:

Good stuff. Alright. So we wanna mention 2 blog posts. One of them is an official Go blog blog post. So as usual our recommendation is it's not that long and just go read it.

Speaker 1:

It's called robust generic functions on slices. And the blog post is a good intro to the new, slices package with, you know, the helpers like clone, sort, compact, equal. And if you haven't played around with those yet, then it's a good intro. It also goes into the internals. It shows how a slice is just a pointer to an array and the length and the capacity and what does deleting something do and how does it work with, like, these nice drawings of arrows pointing to memory.

Speaker 1:

If you came from CC plus plus background, you're probably gonna really like it. And they also talk about how the big change that happened, in the, slices package and the slices in general, which is you clear the memory that was left after the slice if you delete something. This is a good change you know not leaving garbage around in the memory especially if you do funky stuff with slices you're like trying to optimize performance remember where a pointer is stuff like that this is gonna make your life a lot easier because when you delete stuff with the new slices package or when you call compact or delete func or replace something like that basically clears the garbage like clears the tail of the slice and it's explained here in the blog post, you know, very, with like nice drawings or whatever. So if you're interested in new slices package you should go read it. I think if you're just starting to learn go I would put this blog post in, the onboarding document.

Speaker 1:

Like if you have a new developer they're coming in from a different language, I would get them to read this because it's internals, but it's very simple internals. And it just shows how simple Go really is. Like you can explain standard library functions by literally sharing the code itself and like a single whiteboard drawing with 2 boxes and an arrow and you're good. So it might demystify slices for people if they're used to arrays or vectors from other languages.

Speaker 2:

I also have to say, just as a small addendum, that I find that the slices package is the way that I most use generics now in the language. It has made it's been my introduction to generics, because it has some sorting functions and stuff like that that are really handy. So if you're if you're interested in learning generics, this is a great place start. Go update some existing code, switch from sort the sort package to the slices package, for example. And that would be a nice gentle introduction into generics and the language.

Speaker 1:

There's interesting discussion about this blog post on Reddit as well. I found some interesting, comments there. A quote from Rob Pike as one does, you know, quoting Buddha, simplicity is complicated. Imagine Rob Pike sitting on a mountain like people coming up to. Totally.

Speaker 1:

But people are really appreciative of the thing that delete, compact and stuff like that are zeroing out the hidden parts of the array. And there are some other cool functions here that people are mentioning like contains, index func, binary search. Like, there's some, other good options that you can find in that, package that aren't mentioned in the blog post. It's definitely not an exhaustive list of all the features. It's more of an internals, thing if you wanna learn more.

Speaker 1:

And another thing I found on Reddit and I'm interesting to hear, your take on it. As I often do on the show, I rag on Python a lot.

Speaker 2:

Yes. You do. What has Python ever done to you, man?

Speaker 1:

Stolen hours and hours and hours of every month of every week of every of my life since I was 18. Oh my gosh. But, someone on the Golang, subreddit posted, you know, how they migrated their CLI from Python, to Golang. It's a CLI called the Gli, for rendering websites and and, like, publish it's a blogging setup basically from markdown into a website. They use Go Releaser, which is nice.

Speaker 1:

And they basically wrote their entire journey in in a blog post called faster blogging, a developer's dream setup. And, you know, they they basically say why Python was kind of hard for them to use. You know, they wanna publish binaries for people to use and it takes 20 minutes to like compile the the binaries and then stuff like that. Then they share two difficulties they had working in Go, working with the dependencies. Like, they had a lot of dependencies in Python and they needed to find the right ones in Go.

Speaker 1:

Stuff like Beautiful Soup, for example, but they just use the standard library, XNET HTML. Well, not the standard send library, the x library.

Speaker 2:

Okay. Yeah. Yeah.

Speaker 1:

And like compatibility issues, they just used Go release action. But they're they're really happy with the transformation, and they're sort of inviting people to contribute to their platform so they want more people to work using Glee and also on Glee and the Reddit, thread was really positive. People were like, I'm so glad that there are positive stories of migrating from Python to Go. I really wanna do it. Or I also did it and it was beautiful.

Speaker 1:

I'm wondering if you ever had a place where you came, they used one language, and you convinced them to convert an existing thing to Go and it went well.

Speaker 2:

I haven't convinced anyone to switch to go. I I learned go to switch to go from pearl, and I was nearly done implementing a new feature when I I left that job. I don't think that feature ever got implement got got deployed. I interviewed at a company that was switching from Haskell to Go, but they ended up not hiring me, which was fine. I didn't wanna work for that company.

Speaker 2:

There was it was a dating website or something that it wasn't really my my interest. But, no, I haven't I haven't had to convince anybody. I've been involved into the switch, but I haven't had to do the convincing.

Speaker 1:

I'm I'm really wondering if after this is really new right it's their first draft and I hope to hear an update from them I really hope that they could come back with an roi report right Like, we spent 20 minutes on each build. Now it takes, I don't know, 5 seconds. Over the last 5 months, we build it, like, 10 times, and now it's a lot faster. So I really hope that works out. Yep.

Speaker 1:

Alright.

Speaker 2:

And here we are after the news. Thanks for listening. I'm here alone. Shai had to run to pick up his kids. So, sorry.

Speaker 2:

You're gonna hear just my voice. No amazing banter during this short ad break before we get to our interview with Grant about gopher. Js. If you're new to the podcast, thanks for listening. We hope you'll share it with a friend, with a colleague, share it with your work Slack, let your other gophers in your life know about the podcast.

Speaker 2:

We've been getting some great feedback. If you wanna give us some feedback, we'd love to hear a review from you or see a review from you on iTunes. Is it even called iTunes anymore? On Apple Music, I think. On Spotify, anywhere, wherever you listen to your podcast, leave a review, leave a rating.

Speaker 2:

Even if it's a negative one, negative feedback is also valuable. You can also interact with us directly if you want to. You can find our contact details over at cupago.dev. That's where all of our show notes are found. That's where you can find links to our personal bios, to social media links, and our swag store.

Speaker 2:

If you wanna buy a t shirt or a mug with our Brewster cupogo logo, you can do that there too. And the best place possibly to talk to us is on our Slack channel. We are on the go for Slack in the Cupogo channel, cup dashodashgo. We have a growing community, 331 people at the moment, and it's increasing every week. Come join us there.

Speaker 2:

Talk about the show. Talk about the questions we asked in the show. Share your own news items that we sometimes share on the show, and just talk about Go and related topics. And finally, as we mentioned at the top of the program, this show is sponsored by you, our listener. If you are not already a Patreon member, you can become a Patreon member either for free or paid to help cover the cost of production.

Speaker 2:

We have an editor. We have some hosting fees. It's not a cheap hobby. So if you want to be a sponsor, again, cupago.dev is the place to go and become a member on Patreon. And we will do a shout out of your name, when you become a member.

Speaker 2:

So if that's you next week, your name will be in the same spot on that episode. Well, I have come to the bottom of my notes. So I'll stop talking now, and we'll head over to our interview with Grant.

Speaker 1:

So, John, have you read Animal Farm?

Speaker 2:

I've watched the a movie version. I haven't read the book.

Speaker 1:

Yeah. So do you remember the, like, most interesting sentence?

Speaker 2:

Probably not.

Speaker 1:

All animals are equal. But some animals are more equal than others. Do you know how they mark more equal? I don't know. We need to figure out a way.

Speaker 1:

Maybe 2 equal signs? But if you really wanna go hard, you can use 3 equal signs. That would be insane. So nobody would do something like that. Enter JavaScript where it's the only way to actually do comparisons.

Speaker 1:

Okay. So let's talk about JavaScript. I wish someone could help us with it.

Speaker 2:

I wish somebody could help us escape JavaScript. Yeah.

Speaker 1:

Like, but not escape with backslashes. Right.

Speaker 2:

Yeah. Like, you don't worry. Run away. Run away. Run away.

Speaker 2:

Hey, Grant. Hey, Grant. Hello. Tell us about your love for JavaScript.

Speaker 3:

Oh, I avoid it as much as possible.

Speaker 2:

Do you

Speaker 1:

know that meme? That's where I would put my love for JavaScript if I had any.

Speaker 3:

So I use Type Script, Dart, and Go, and all of those transpile into JavaScript. So that's how I use it.

Speaker 2:

There you go. Well, Grant, before we dive into this fuzzy topic of JavaScript and things that aren't it, why don't you tell us about who you are, what you do, where you work, anything else of relevance or interest that you wanna share about yourself?

Speaker 3:

Yeah. Sure. So I'm Grant Nelson in Montana. I've lived here almost my whole life. Went to, MSU and took a long break for a while, and now I'm back working on my PhD.

Speaker 2:

Okay.

Speaker 3:

I prefer to be a teacher, but I ran out of money. So I had to, go get a real job. And I've worked I've worked for a lot of embedded software companies. So I've written embedded stuff for satellites and for self driving ag vehicles. And then I got picked up by Workiva to help build their second version of their rich text editor And, been doing that for the last 10 years.

Speaker 2:

Interesting. So Workiva has, recently asked you, as I understand, to do some, not JavaScript. Although, I suppose you have to do some JavaScript. But let's talk about this project. Go for JS 1.19 was just released, and you did most of the work, I think.

Speaker 2:

Tell us why. Well, maybe maybe first you can tell us what Go for JS is. I mean, I think we've been toying around it long enough now. We can we can explain what gopher. Js is and and why it's an interesting project.

Speaker 3:

Yeah. So when we started going back to, like, Work Evo doing a rich text editor, we wanted to make it collaborative, and we wanted to be able to write the code once and have the same code that's doing the layout running on the server and on the client. We didn't want to have to sort of write it twice. The first version actually did that where they had duplicate code, and we had a lot of bugs that didn't match up. So we kept on looking for languages where we could run it on the server and run it on the client.

Speaker 3:

And since we already talked about our love for JavaScript, we did not wanna run Node on our server. So 10 years ago, we found, we're at, I think it was Go 1.2 or 1.3, and this little project by a guy named Richard called Gopher JS appeared on our radar that let us take our data structures that we use on the server and compile them into JavaScript so we could run them on the front end on the clients. The distributed data, they're called CRDTs, commutative replica data types that we use for all of the collaborative part of the rich text editor needed to have identical code running on all these different locations. And so that just saved us a lot of time Mhmm. A lot of effort.

Speaker 3:

And so we've been using it from long time ago.

Speaker 2:

I actually, gopher. Js is one of the reasons I started using Go in the first place because I was looking for a similar sort of, you know, language. What language can I do both places? And came across Go for JS. And so I was already interested in Go, but I hadn't really invested in it yet.

Speaker 2:

So when I saw that, I'm like, okay. Now it's time to really invest in Go. So I'm curious, Go for JS has has been stuck kind of like GCC Go on Go 117 for a long time. Because in Go 118, they added this magical thing called generics that really complicates the code. And we're working on adding generic support to gopher.

Speaker 2:

Js. Full disclosure, I'm one of the co maintainers of gopher. Js. So that's why I say we. I mean, we the project, that I'm part of.

Speaker 2:

But it's not there yet. And so go go for js, the last full stable release is go go for JS 1 17. We've had Go 1 18 out for a while without generic support. So the standard library has been ported. You recently ported it to Go 1.19.

Speaker 2:

I'm curious your motivation to do this.

Speaker 3:

So since we are a large public company, one of the things that we have to do is called an SBOM. So it's a a software bill of materials, and it shows all the different versions of all the different things that we are using so that you can then run analysis for vulnerabilities. We also maintain the code. Obviously, we are updating stuff as much as we can periodically to keep it, not falling apart. And, when Go for Jazz hit that limit at 117, all of the transpiled code that runs on both server and client kinda came to a stop.

Speaker 3:

And there's been some CVEs, some, vulnerabilities in Go that have been detected. And even though none of those get into gopher. Js, they still show up in vulnerability tests. Mhmm. And since we're the Workiva deals with, SEC end of year filing documents, some big corporation things.

Speaker 3:

We are very interested in security and making sure that we have no vulnerabilities.

Speaker 2:

Right.

Speaker 3:

So just having that version forward helps us there. It also gives us the ability to update. Some of our large data structures to make them run fast, we had to build our own stacks for every single individual type, and they're practically copy and paste versions of the same code. Mhmm. So when we saw generics, we were like, yes.

Speaker 3:

Finally, we'll be able to update to all these, these new tools, these new constructs. And, it kind of stopped. Since we had been using gopher. Js for the last 10 years, and, like I said at the beginning, I wanted to be a teacher. I've always liked giving back to the community.

Speaker 3:

The CRDT that we're we built was based off of a paper from Victor Kuchenko. As soon as we took the next step, we published a white paper on the the next level. It's now pretty old white paper for CRDTs. But it was that whole, like, giving back to the community, trying to make sure that we're not just putting in patents and putting up a wall. So when Gopher.

Speaker 3:

Js got stuck at 117, I kept on being like, hey. I got an idea for how to give back to the community. So we helped move this forward.

Speaker 1:

Mhmm.

Speaker 3:

Eventually, they said yes.

Speaker 2:

That's really cool.

Speaker 1:

I think that, you know, the it's really fun to have the, like, corporate reason or the, like, financial reason to work on an open source project. You're like at the beginning. Yeah. There's this thing called SBOM for vulnerabilities. It's it's important.

Speaker 1:

The my customers care about it. And then, but I wanna give back and I really care about it and I wanna nerd out about it. It's good when these incentives align in open source. You know what I mean? You can find someone who's willing to pay money for to do for you to do something you, like, care about.

Speaker 3:

Oh, yeah. It's great.

Speaker 2:

So I'm I'm curious how this will help you at work to have Go 1 19 without generics because you you can't you still can't deduplicate all that code you were talking about. And you probably can't even pull in new dependencies because they're gonna start pulling in generics and stuff like that.

Speaker 3:

Yeah. We are going to continue helping with gopher. Js to get it up to 120 with generics.

Speaker 2:

Mhmm.

Speaker 3:

I've already been talking to, Alex, one of the maintainers. I haven't talked to you yet about this, to go up to 120 and get generics and keep it moving forward. Once we reach I I think 120 is our main goal. Once we reach that point, we're then going to be able to do a lot of the maintenance that's been sort of lacking in the last 4 years

Speaker 2:

Yeah.

Speaker 3:

On our core that's transpiled.

Speaker 2:

Okay.

Speaker 1:

And the just as, as a newbie, I like to gopher. Js. Now usually when you do interop, you have some ugly code in between. That's just how it looks. Right?

Speaker 1:

Because it's ugly just because the the it's not like the one language. It's even worth when it's even worse when, like, both languages are ugly. But in our case, it's only one language that's looking at. And all of us here in the room know which language I'm talking about. But it's more than just making the interop pretty.

Speaker 1:

Right? It's and it's about making it more maintainable. It's about actually missing features and libraries that you would want to use, right? Like this is a problem that's getting worse as time moves along. It's not frozen in time.

Speaker 1:

It's not just like a bug that you you're unhappy with. Yeah. Can you give an example of like a limitation that's stopping you from doing something right now? Because this is, or, you know, forcing you at least, like, forcing you to have some non fun workarounds.

Speaker 3:

We have several non fun workarounds specifically around some of the, panic recover features. Because we're running in minified JavaScript on the front end, which hooks into a Dart layer, and we have bindings that combines the 2 of them, our stack traces are horrible in the front end. So what we ended up doing in a lot of our Go is we either return an error or we panic an error and catch and then, add to it and then pass it up, add to it, pass it up. And we as we're doing this, we're building up what's similar to a stack trace with some detailed information about how the error occurred. Originally, that was all done with panics, and we had to refork all the code to make it use the full, normal standard go return an error, which unfortunately added a lot of extra lines of code.

Speaker 3:

That actually got fixed a bit ago, and we haven't done maintenance on that. Like I said, we have stacks that are duplicate that we'd like to produce down to just one generic type stack. There's, well, there's a bunch of different things that we wanted to do. Some of them I'm I'm trying to think of how to explain them because I don't wanna get too deep into, CRDTs and how the data structures work together.

Speaker 1:

But but I think from what I'm hearing, it's you have some, very nasty workarounds. But end of the day, you can write all the, like, cases you wanna use instead of using generics and stuff like that. Is it a problem pulling in dependencies as well?

Speaker 3:

Yeah. We do have, we have a bunch of dependency checkers built into our product, that will keep us from using certain, Go libraries because we have to keep our JavaScript small. So, like, we are never allowed to pull in format. Or, at one point, we weren't allowed to pull in sort, but I think, Dimitri, or it could have been you, Jonathan, fixed what was wrong with sword. And, somebody fixed it.

Speaker 3:

And so we are then able to do, start using the sort that's built into Go instead of having our own version. But we have a lot of tools to just kinda check to make sure that we're staying within certain dependency ranges. And, for most of this code, we don't have any third party, Go code that's transpiled. It's all in house.

Speaker 1:

And that's to keep, like, the JavaScript small or also for security reasons?

Speaker 3:

Both, but mostly to keep JavaScript small. Because right now already, our product is a it's like Microsoft 360 or Google Docs, but massive because that's end of these end of year reports. So just starting up the document sometimes takes 30 minutes to load. Or, say, it's 30 seconds.

Speaker 1:

30 seconds. Oh. Sorry.

Speaker 3:

I was

Speaker 2:

about to have a heart attack. Wrong

Speaker 3:

wrong, time scale there. So it takes 30 seconds to load, which is kinda a long time when you're just trying to find a document, and it's not very fun for our customers. So the smaller the code is, the better it it'll load up and faster it will run.

Speaker 2:

I'm curious to hear a little bit about your experience doing this. When you decided to do it, I imagine it was exciting. Was it intimidating? Were you scared of, you know, what what were your expectations going in?

Speaker 3:

It was very intimidating because we we had made a few changes before as Workiva. There's been, 3 people, if you look through the commits, there's, Tom and Ben Echols, our log algorithm, and, 3rd one that I can't remember that their name ends with the dash w f. So you can find them in the commits. They have made very small changes to improve different things, like the speed of maps or, how parsing works so that it runs faster. They had a very pleasant experience.

Speaker 3:

Every time we've tried to work on this code, the maintainers have always been very nice and open and welcoming. It's kind of always gonna be intimidating working on an open source code because we don't know if we're gonna be breaking other companies. Mhmm. We can only check the code with the test that it has and then run it on our own stuff to make sure it's going to work with our own stuff, but we don't wanna we don't wanna be the ones that break everything.

Speaker 2:

Right. Right.

Speaker 3:

So when I started and was like, alright. I'm gonna do something that's even bigger than the others people. It was the same sort of thing of how do I enter into this without just completely ruining everything, the whole history?

Speaker 2:

Yeah. Alright. So it was a little bit intimidating going in, more from, like, like a social aspect, I would guess, than a technical one. It sounds like Yeah. Like, you know, the the the that's the pressure of maybe doing something that would affect other people negatively.

Speaker 2:

What was your experience then doing the the port of 1 19 to gopher. Js? Mainly the standard library. Right? And what what did you do any language changes?

Speaker 2:

I don't even know if there were language changes in Go 119.

Speaker 3:

There's, a little bit. They added some tooling or some parts to the AST to allow parameter types Mhmm. Into the different structures. So Gopher Jazz had a few tools that when they would hit those spots, they weren't expecting the parameter type to show up, and so it would crash. Yeah.

Speaker 3:

So that was the first thing I did was go through and try to remove some of those crashing spots. Mhmm. The the two parts that were the most difficult in the new libraries was, async had a new generic pointer, and I had to figure out every time they use that how to work around it in each of the different locations. Unfortunately, it wasn't used too often. Most of them were using the hard coded versions.

Speaker 2:

K.

Speaker 3:

And the other one was, Cryptology in the very center of the crypto package. They had used a generic to make it so that the Elliptic points could work, and I'm not a cryptologist. I and I am. That's where it's scary because if you break cryptology, especially as a security company that Yeah. Thrives on security and reliability, breaking cryptology is a horrible thing.

Speaker 3:

Yeah. So coming up with a way where I wasn't rewriting any of the mathematics and just changing the way that the code is compiled was interesting and

Speaker 2:

difficult. Uh-huh. Were you able to rely on the tests that that existed to, you know was that enough confidence you did things the right way?

Speaker 3:

The gopher. Js is fascinating the way it runs tests because it doesn't only run its own tests. It runs all the tests that Go does on itself.

Speaker 2:

Yeah. Almost all. There's a few exceptions. But yeah.

Speaker 3:

Yeah. That's right. There's there's a a list of them. I had to add a few to that list, and I removed 1.

Speaker 2:

Oh, good.

Speaker 3:

Going to 119, got one of them taken care of.

Speaker 2:

Nice. Cool. So, you're planning to to help also with go 120. Are you starting on that right away, or are you waiting for generics to land? Are you helping with generics?

Speaker 2:

What what's your plan with with regard to 120?

Speaker 3:

So discussing with Alex, the only, he said I could help him with generics. There's a lot of stuff that needs to be done. Mhmm. But I could also start the non generic upgrades for 120, and there are a bunch of different little upgrades. I mean, I had to do that for 119, stuff that had no relation to generics.

Speaker 3:

Like, I don't remember. It was some sort of weird debugging tool was using pointers in the same footprint of memory, but they were just switching the pointers.

Speaker 2:

Mhmm.

Speaker 3:

That doesn't work in JavaScript because you it doesn't matter to the same footprint.

Speaker 2:

Yeah.

Speaker 1:

So I

Speaker 3:

had to come up with workarounds for that sort of stuff. And Alex was saying I could do that for 120 before we got generics.

Speaker 2:

Mhmm.

Speaker 3:

And if I get done with that, then I can help with generics and

Speaker 2:

Yeah.

Speaker 3:

Help all that move forward.

Speaker 1:

Really cool. The work you're you're planning to do on the project, it sounds I would call it unpredictable because you might have like, oh, there's 2 places. The fix is super easy and nobody else, like, no problem. And it can be the case that, oh my god, this is something very core. This is a a really big change.

Speaker 1:

It it has a lot of like surface area that I need to go over and polish before I feel comfortable, you know, shipping it. How does that fit within, you know, you wanna ship stuff for your company and they're asking you, like, how many story points it is it is is it to, like, add generic support to, transpiler between Go and and JavaScript? Sounds kind of hard to, you know, estimate, I would say.

Speaker 3:

Yeah. Very much so. The team that I'm working on is a bunch of the the old dogs. We're random collection of people from all over the company who helped build the foundation for all of the stuff that's running right now. So when it started, there's when we started version 2, there's about 18 people that were doing, like, something similar to spreadsheets, something similar to rich text.

Speaker 3:

And out of there, there ended up being only 6 that are still in the company after 10 years. And they put us all together, and we go around helping do maintenance. We help with different teams. We coordinate between different groups, Try not to cause problems. And occasionally, but very rarely, we'll actually pick up some features.

Speaker 3:

Mainly, it's for prototyping, like, adding a new type of API. Our team went and figured out prototype for that until we got to a certain point, and then we handed it off to a bigger team. So because of that, we don't have features with deadlines. Our team is a little more just getting things done as quickly as possible.

Speaker 1:

That sounds beneficial to work that's, like, nonlinear, like contributing to big open source projects or or enabling work that's not, like, just another feature. Do you have any other, like, open source cool stuff, going on at Workiva that's Go related? Or are you, like, Go for Jess is more than enough and then thanks you. Thank you very much.

Speaker 3:

We have contributed to OpenAPI a little bit. Some fixes to their Go client side and glow Go server, whatever they're called, generators. We have contributed a little to, I think, wolfSSL and open SSL.

Speaker 1:

Damn. You're not a crypto guy, but you contributed to No.

Speaker 3:

It's not me. That's that's Workiva. Yeah. Yeah. You did that.

Speaker 3:

Yeah.

Speaker 1:

Very cool. So API, SSL, the browser. Where the and obviously the back end. Where don't you live? Just in my, like, smart fridge?

Speaker 1:

Maybe desktop apps? We need to put you in contact with Andy.

Speaker 3:

Part of the reason we built the API is because we wanted to go mobile.

Speaker 2:

Yeah. For sure. So one question I can imagine most of our listeners are are asking themselves is why would you bother with gopherjs? We have WASM support now. Why don't you just use that in the browser?

Speaker 2:

What and and I I know of some answers to that, but what's your answer to that?

Speaker 3:

Firstly, if we were going to use WASM, Go doesn't quite do everything we need in WASM. It's not fully supported in all of its ways. WASM itself isn't fully supported in connecting to things running in JavaScript, so we have a lot of stuff running in Dart. And those the Dart to WASM connection isn't fast enough for most of the stuff that we do. Since we're doing large layouts of huge documents, most of the data is stored in Go and that are transpiled Go with gopher.

Speaker 3:

Js. But the actual SVGs that are rendering on the screen are all done in Dart, So we're sending massive amounts of data between those 2. If we were to go to WASM, we'd have to move a lot of that back into WASM so that we weren't trying to communicate through the current way that WASM can communicate. We did consider using Rust and Wasm 10 years ago when we were starting this. And, Rust was pretty new at the time, and Wasm was pretty new, and they just weren't mature enough.

Speaker 3:

But, Go was a little bit further along, and Go for JS was actually really already there. So it just seemed like the obvious choice. Now that we're using it, we we have, I think, like, 7,000,000 lines of code in our product. It would just take a lot to

Speaker 2:

Yeah. Now you have a vested interest in in in maintaining that. Makes sense. So if you were to start now with the tools available now, do you think you would still make the Go for JS choice or would you Rust has come a long way, Wasm has come a long way, and there's a 1,000 other tools out there too. And you probably don't know them all, so you may not know the answer.

Speaker 2:

But I'm just curious, you know, if you were to start again or if somebody listening is thinking of starting a project, should they consider Go for JS or should they look at WASM or should they look at Rust or something else?

Speaker 3:

I'm not sure. It it kinda depends. If you if you need a lot of communication between JavaScript and Dart or, TypeScript and the transpiled code, Go for JS is the best way to do that because it ends up in the same memory space. It is JavaScript at the end of the day, so it can communicate with the DOM and with everything else very, very smoothly. It makes it great for debugging and inspection.

Speaker 3:

I haven't tried debugging Wasm. I don't know how you could do it from the browser when you're running JavaScript.

Speaker 1:

Yeah. It's not great.

Speaker 3:

Yeah. Okay. Well, that's that's good to know. That's kinda what I assumed.

Speaker 1:

You always wanna get the the first class, citizen, treatment. You know what I mean? And in many of these projects, the technical POC is the is the main achievement and the developer experience is an after thought. Like, oh, debugging, logging, hot reloading, stuff like that is is usually added on and then it takes a long while to to work on it. I tried doing, Rust in the front end with, like, a a project called the u, like, y e w, tried to develop a single page, no fetch APIs, no nothing.

Speaker 1:

I managed to set it up, but it was such an it was a struggle. So I don't know. I would definitely recommend anyone who's trying to do, you know, cross language, stuff like that to optimize. Just stop for a second and and think if they really wanna do it before even committing to one framework or another.

Speaker 3:

Yeah. I mean, our case was very we had to.

Speaker 1:

You are the edge case. Yeah.

Speaker 3:

Our export system has to be able to layout and we have to layout on the client. And there's we don't wanna do export on the client's machine. I mean, we're already putting a lot of strain on their memory and CPU. We didn't wanna put more by having them do the exports. So

Speaker 2:

So, Grant, thanks again for your contribution. If anybody's interested in following your contributions on Gopher. Js or getting in touch with you, are you online? How do people get in touch with you?

Speaker 3:

Most of my Gopher. Js contributions have been under grant nelson dash w f, on GitHub. Mhmm. Because that's my work account. Yep.

Speaker 3:

Most of my open source work, that's not work related is under GitHub grant hyphen nelson.

Speaker 2:

Okay. Great. We have one last question we ask all of our guests. I gave you a little bit of prep ahead of time, so you wouldn't be too much of a surprise. We haven't talked a lot about your your history with Go.

Speaker 2:

I don't know when you started using Go for the first time, but it's been a while at least since you've been using Go for JS for a while. And I don't know what languages you used before or even continue to use to these to this day. But when you started learning Go, what was the biggest surprise or the biggest challenge for you when when picking up the new language?

Speaker 3:

The two biggest surprises to me, they were more of gotchas because, like, a lot of the other stuff was just smooth and, like, really cool. But there were things I could do like, my my background is c plus plus and c sharp and then, yeah, from the the embedded world.

Speaker 1:

Mhmm.

Speaker 3:

So a lot of the Go stuff like threading, just perfectly smooth.

Speaker 2:

Mhmm.

Speaker 3:

The gotchas was that an interface is an object. So you can have a null object inside a non null interface.

Speaker 2:

Mhmm. And so

Speaker 3:

there would be places where you check to see if an object's null before returning a null. So that which seems weird, but it's because you're returning a null interface for a null object instead of wrapping a non null object in an interface. I'm confused. Yeah. As soon as you get your head around that, it's really quick.

Speaker 3:

It makes a lot more sense on how, Go functions. It's actually kinda nice. That's why it's it's nil or instead of null. Actually, it's, the nil still has the type wherein, like, c plus plus, a lot of times you're if you have a null, you have no clue what type it is. Yep.

Speaker 3:

So there's some pretty cool tricks you can do with that as well. The other gotcha that messed with us for a while until we figured out what was happening is if you create a a slice with capacity and you send the slice into 2 different threads or even on the same thread and you add to it, it's adding into the same capacity even though it's returning a new slight or a slice. It'll use up all the capacity before returning a brand new slice. So we added a whole bunch of things into our code after we figured this out that squeeze down all of the slices down to the smallest amount. So if we send them to different threads, we're not overriding a value from 1 thread with a different thread.

Speaker 1:

Right. Right. Right.

Speaker 3:

Stuff like that.

Speaker 2:

So you wanted a copy, and you you got essentially a shallow copy, and you wanted a deep copy.

Speaker 3:

Right. Yeah.

Speaker 2:

Yeah. Right. Okay.

Speaker 3:

And when you do an append and you have no, capacity, it will do a deep copy to make the array bigger.

Speaker 2:

Yeah. Exactly. Exactly. Yeah. There's a lot of sort of smoke and mirrors behind the way slices and arrays work.

Speaker 2:

Once you understand it, it it's powerful, but it it could definitely trip you up at the beginning.

Speaker 1:

So Oh, now you don't need to know anything about it because we're, wrapping it all up with the iterators, which are even easier to understand. Oh, yeah.

Speaker 3:

Well, at

Speaker 2:

least we don't have a triple equals, to worry about.

Speaker 1:

We have a, we had smoke and mirrors, and now we have smoke and mirrors and that the guy from wizard of Oz, like, behind the curtain, behind him smoke and mirrors, behind that turtles all the way down, and somewhere below that there's, like, 2 lines of sea actually doing all the work in the world.

Speaker 2:

Alright. Great. Well, is there anything you'd like to add before we wrap up?

Speaker 3:

No. It's great coming out, and, thank you for interviewing and setting this all up.

Speaker 2:

Yeah. Thank you, man. Thanks for all your work. Thanks for chatting to us about it.

Speaker 1:

Well, all your work that doesn't have bugs, let's wait until the new version has some more, road timing.

Speaker 3:

Yeah. If it works, great. It's mine. If it has bugs

Speaker 2:

It's my fault for not repeating it closely then.

Speaker 3:

Yeah. Exactly.

Speaker 1:

Thanks, Grant.