CppCast - Go

Episode Date: August 6, 2020

Rob and Jason are joined by Ian Lance Taylor from Google. They first discuss an announcement from Conan and a blog post about embedding files into C++ applications using string literals. Then they talk to Ian Lance Taylor about the Go programming language. News Join the new Conan 2.0 Tribe C++ 70x faster file embeds using string literals Online meetups Links Go Go's GitHub repository Sponsors Clang Power Tools

Episode 259 of CppCast with guest Ian Taylor recorded August 5th, 2020. This episode of CppCast is sponsored by Clang Power Tools, the open-source Visual Studio extension on a mission to bring Clang LLVM magic to C++ developers on Windows. Increase your productivity and automatically modernize your code now. Get ahead of bugs by using LLVM static analyzers and CppCore guidelines checks from the comfort of your IDE.

Start today at clangpowertools.com. In this episode, we discuss embedding with string literals. Then we talk to Ian Taylor from Google. Ian talks to us about the Go programming language. Welcome to episode 259 of CppCast, the first podcast for C++ developers by C++ developers. I'm your host, Rob Irving, joined by my co-host, Jason Turner. Jason, how are you doing today? I'm okay, Rob. How are you doing? I'm doing okay.

Yeah, not too much to share on my end. We had some nasty weather here this week, but we're fine. How about you? We just had a minor hurricane blow over. Yeah, just a minor hurricane. It didn't really affect us here at all. It wasn't even still a Category 1 when it hit by you guys, was it? I don't think so. I don't think so either.

It's funny. I mean, I may have mentioned this already on the podcast before, but every single time that they predict that a hurricane is going to make landfall near Cocoa Beach, Merritt Island area, which is where Cape Canaveral is, you know that it's wrong. Because a hurricane has never made landfall on Cape Canaveral. It would have destroyed Kennedy Space Center 50 years ago if it had.

It never does. So I'm like, oh, well, my parents live right around there. I guess they'll be fine since it's predicted to hit them. It just always bounces off. I think there's something about the shape of the island, honestly, that might affect it because it juts it out right there. Hopefully you're not jinxing them by pointing this out, though. No, it's been several years I've been pointing it out.

Okay. Well, at the top of our episode, I'd like to read a piece of feedback. This week we got a tweet about, just listening top of episode, I'd like to read a piece of feedback. This week, we got a tweet about just listening to episode 256. Appreciated the discussion around LLVM modules, C++ modules, and precompiled headers. I've been working with PCH support via CMake and have been really pleased. It's letting me give thought to how I will organize my C++ modules when I get them. That's from Bowie on Twitter. Yeah, and the recent PCH support that's built

into CMake is actually really good. Having hand rolled that stuff in CMake scripts in the past, it's so much nicer to just be able to turn it on. Nice. Is it pretty similar to the way PCHs have worked in Visual Studio for a while now? Yeah, I mean, it's all the same idea. It's just with CMake having it built in, you just get to say, enable PCH for this project and have these four header files included or whatever. And it just does it regardless of platform. Okay. Well, we'd love to hear your thoughts about the show.

You can always reach out to us on Facebook, Twitter, or email us at feedback at cpcast.com. And don't forget to leave us a review on iTunes or subscribe on YouTube. Joining us today is Ian Taylor. Ian has been writing free software since 1990. He is the main author of Taylor UUCP, The Gold Linker, and the Go Front End GCC. He is a member of the GCC Steering Committee. He joined Google in 2006, and since 2008 has been working on the Go programming language. Ian, welcome to the show. Yeah, glad to be here. Thanks for having me. Wow, The Gold Linker, that made quite the splash when it was first announced. I remember lots of people talking about it.

Yeah, that was a while ago now. That was around 2007, I guess. But yeah, just a much faster linking speed. It's still being used today. There's also LLD now, which is even faster. But I don't know. Gold still has its place. I didn't realize LLD was still faster. I always kind of found it surprising that gold didn't just become the de facto standard

because it was so much faster. Yeah. I didn't push it as hard once I switched to working as Go. So I don't know. Okay. All right. That's, I don't know. Okay. All right. That's cool, anyhow. Yeah.

Okay. Well, Ian, we'll start talking more about what you've worked on in the past, including working on the Go language. But first, we've got a couple of news articles to discuss, so feel free to comment on any of these, okay? Sure. Okay. So, this first one is, join the new conan 2.0 tribe and this is on

the conan blog and this is kind of interesting i guess they're they're working towards a 2.0 version of conan and they're basically inviting you know power users of conan to give them lots of feedback on the direction of 2.0. Yes, that sounds right. Yeah, and they're also doing some online classes, which is cool, because they were planning on having a conference in Madrid, but that's been postponed, obviously. Yeah, it sounds like their online sessions sell out, sell out. I think they're free.

No, maybe they're not free, but regardless, they sell out really fast. So if you see one announced and you're interested sign up as soon as you can yeah you're still using conan right yeah yeah it's used on uh i mean besides my personal projects two projects that i'm paid to work on at the moment nice i can save us a lot of effort when you're like oh i just need speed log real quick i'm just going to add it to the conan script and it's good. That's pretty handy. Yeah. You have any experience with working with some of the C++ package managers, Ian? I don't really. Sorry to say. I've mostly, I usually, most of my work's been pretty low level in the stack. So I don't need to pull in a lot of packages beyond the pretty extensive C++

standard library. Just out of curiosity, I mean, maybe it's a slight diversion, but does Go have a package manager that's a standard package manager? Go does have a package manager. It has a whole module system, and there's a website, package.go.dev, which handles packages for you. Okay. have, which handles packages for you.

Next thing we have is a blog post, C++ 70 times faster file embeds using string literals. This is a tool that you can check out to embed content into your C++ binaries.

He did some performance testing comparing it to XXDD and it is significantly faster and uses much less RAM so it's definitely worth checking out although the whole time I'm reading this I just keep thinking about Jean-Huidh's work to try to get Stood in Bed into the language. Of course yes. Which hopefully is gonna you know make some more progress. Well this is actually really interesting because many of us who have done this in the past have done it with like binhex or something like that and embedded, you know, whatever, all kinds of other options.

I'm a little disappointed that this is using escaped bytes instead of using raw string literals because I'd be very curious to see if that made a difference also. But yeah. Yeah, I would definitely go with raw string literals for something like that, but it may not make that much made a difference also. But, yeah. Yeah, I would definitely go with rostering literals for something like that, but it may not make that much of a difference. I would expect that the time taken with just bytes

is just allocating all the memory to store all the information for each individual byte, which it turns out you don't need, but it kind of does it automatically. Yeah, that's a good point. Rostering literals probably wouldn't make much of a difference. I'm wondering if it would make your editor choke that much harder, seeing all these non-printable characters in the middle and stuff.

Okay, and then the last thing we have here is a list of all the online C++ user group meetings in August, and this is on Meeting C++'s blog. And yeah, lots of good user groups that are going online. And you don't have to live anywhere near some of these cities to attend as long as you can log on at the right time. Yeah, mine is tomorrow, so it's too late for anyone listening to this. Right.

But it's been interesting because I can't recall if I've mentioned this on the show or not. We've had people from, like, Thailand come to our meetup. It's got to be hard to do, but good for them. Well, for them, it's this guy. It was, like, early in the morning as he's, you know, just getting his day started. For people, people from Europe have also come, and it's like 2 o'clock in the morning, and I'm like, why aren't you sleeping? Okay, Ian.

So I don't think we've ever really talked about the Go language on the show before. Could you start off with just giving us a description of Go for listeners who aren't familiar with it? Yeah, sure. So Go is a programming language. It's an open source language that was originally developed at Google. It's in the C family of languages for sure. It's got a syntax that would be familiar to anybody who uses C++,

you know, curly braces and all that. It's designed to be a simple language with a small number of constructs, a small number of keywords, very easy to pick up and learn, especially for anyone who knows C++. It's designed to work well for multi-threaded environments. It has multi-threading support built into the language directly without needing any library calls.

So you can start a new thread of execution, which in Go is called a Go routine. Go routines are actually not threads in the C++ sense, but Go routines are multiplexed onto threads. So you can have many, many Go routines. And the runtime also handles the stack for you, so you never run out of stack space until you run out of memory. It's also a garbage-collected language,

so the runtime manages all memory for you, and you don't have to track it yourself. It's a simple language. It's designed mostly for writing networking servers. It can be used, but people use it for all kinds of things. Obviously, it's Turing-complete. It can be used, but people use it for all kinds of things. I mean, obviously, it's Turing Complete, can be used for anything, and it's still steadily gaining in popularity, much to my surprise.

It's doing well at an ecosystem out there. It's used for a lot of cloud services. It's what Docker was written in, and if you're in the cloud space, Kubernetes was written in Go Go and many similar tools. I had no idea, honestly. Never stopped to think about it. So you just mentioned how it's used in some of these cloud tools and networking services. Could you maybe tell us a little bit about the history of Go, why it was created and, you know, why they felt this new language was necessary?

Yeah, absolutely. It was started in 2007 by Rob Pike, Ken Thompson, and Robert Griesemer, so some pretty well-known names there in the computer science field. And the main reason for starting it, I mean, there were various reasons for starting it, but one of them was just slow build times. At the time, they were all three at Google, and they still are. It could take half an hour to build a program, a big C++ program. And they also were looking at the changes coming in C++, the new features added, and it seemed clear the language was on a path of increased complexity, completely understandably. But they thought that there might be room, there might be space in the ecosystem for a language with a different perspective,

a language that aimed more at simplicity and ease of use rather than getting the very last possible execution time improvement in a language that would build much faster for Google-scale C++ programs, and in general, a language that would scale to support Google servers. So we started, you know, as an experiment, really.

I mean, what can we do with this language? And, you know, hoping to generate ideas that might get pulled into other languages. But it turned out that it kind of caught on. I joined the project in 2008, along with Russ Cox, who's the current lead. And then in 2009, it went open source. It was announced to the world. And in 2012, version 1.0 was released.

And we've just carried on since there. We're about to release 1.0 was released. And, you know, we've just carried on since there. We're about to release 1.15. And I should add that there's, when I say 1.15, I mean sort of the main Go installation. But, you know, it's a language that's defined by a specification. There's multiple Go compilers, both GCC and LLVM support Go. And there's also TinyGo, which is aimed more at embedded systems. But, you know, there is one main Go compiler, which is aimed more at embedded systems. But there is one main Go compiler,

which is the one that most people use, and that's the one that is about to have a 1.15 release, and the one that kind of drives development of the language in libraries. So, it sounds like you were involved in the project before it was made official. You were also working at Google at the time? That's right. I still work at Google. Okay.

So, yeah, I joined the project when people at Google started talking about it, but before it had been publicly announced. Now I'm honestly kind of curious because some of the most interesting projects that I've been involved in at work is things that I just volunteered for and kind of weaseled my way into that project. Did you do the same thing here? That's pretty much what happened, actually. I found out about Go, and I had been thinking about, you know, what's a good way. You know, I've been thinking about multi-threading issues at the time. You know, that was back when it was becoming really obvious that we weren't going to get better clock speed in our processors, but we were going to get more and more cores in our machines.

So we needed ways to write programs to take advantage of those more and more cores. And I've been thinking about that in the context of C++. I was a C++ programmer. I still am a C++ programmer. But then I heard about this new language, Go, and I saw that it's built-in support for concurrency, which, by the way, was based on ideas that started with Tony Hoare in the 70s

called Communicating Sequential Processes, which Rod Pike had experimented on with various languages when he was at Bell Labs. So anyhow, I heard about this language, and I thought, this is an interesting language. I should try it out. And so I wrote a front-end for GCC to support that language, and then I went to the Go team with just the three of them at the time, and I said, hey, I've got this extra Go compiler.

And they invited me to join the project and I've been there ever since. And I think I'm reading between the lines here, the Go compiler for GCC, the Go front-end must also be written in C++. That's correct, yes. The main Go compiler is written in Go, but the front-end for GCC be written in C++. That's correct, yes. The main Go compiler is written in Go, but the front-end for GCC is written in C++.

One question I have, we've had several developers from Google on the show over the years working on various C++ projects at Google, and obviously there's room for lots of different programming languages in the company as large as Google, but what are some of the projects that are using Go internally at Google that you could tell us about? Sure. Well, I already mentioned Kubernetes, for example. Quite a large project all written in Go.

There's a lot of smaller projects at Google written in Go. A lot of the sort of infrastructure for the company, a lot of the internal tools are written in Go. A lot of the sort of infrastructure for the company, a lot of the internal tools are written in Go. The download server that you contact whenever you download a new version of Chrome or whatever, that's all written in Go. A lot of the logs processing done

within Google, and there's a lot of logs processing done in Google that's almost entirely written in Go. Those are some of the examples. I don't even know all the ways it's used in the company. As you say, there's a lot of languages used in the company. Go is not dominant by any means, but it's quite popular. As you're working on this front end in C++ to write the Go language, how often do you find yourself going,

oh, I wish I had this feature in Go, or I wish I had this feature in C++, or whatever? You know, they're different languages. I mean, when I program in Go, I get used to garbage collection. And then when I go back to C++, it's like, oh, now I have to track all my memory again. But not so often, I guess, is the truth. I guess I just adopt a different mindset for each one. They have different goals and purposes and uses.

Interpreting. Okay. Does Go interrupt well with C and C++? It's not great. It interrupts fairly well, yeah, with C, I should say. It interrupts fairly well with C. Go has a built-in support for, you can sort of, you do, in Go, you bring in other packages with an import statement, which is, you know, sort of similar to the C++ sharp include. And so you can literally import C. And then there's a way to say, when I import C, I want these headers, I want to be able to call these functions.

And then, you know, in your Go code, you can just call them directly. So it's actually quite easy to use. The main disadvantage is it's somewhat slow. Go actually uses a different calling convention, so you have to call the conventions, and you also have to tell the scheduler, okay, now I'm leaving the Go routine world and I'm entering the C++ world. So it's like every function call takes like 10 times longer than it really ought to. So it's hard to do very quick. It's hard to call just a very tiny function and see it and come back. I mean, it's easy to do it,

but it'll slow down your program more than it ought to. And then there's also direct support for calling C++ via SWIG. If you're familiar with SWIG, it's a general tool for calling C++ from other languages, and it supports Go as well. It seems interesting to me that, you know, basically a language cannot succeed if there's no way to call a C function from it. I think that's absolutely true. C has kind of become the lingua franca that every other language has to support.

It puts us, it's good, you know, lets other languages call through C to any other language. Yeah. So do you want to maybe go into some more detail on some of the major features of Go? We already talked a little bit about Go routines. Are there any other kind of major highlights we should discuss? Go routines and channels are the big ones.

So a Go routine lets you start a new execution thread. Let's say it's not the same as a thread in C++. And then channels are a way to communicate between Go routines. You can say I have a channel of int or whatever type, and then you can just, you know, one Go routine can write a value to the channel, and another Go routine can read from the channel. Not that exciting. The nice thing is that it's built into the language.

And then the other main feature there is the select statement, which lets you select on a whole set of channels and say, whichever one of these is ready first, you know, that's the one I want. And so a select is like a switch statement, except you're switching on a set of channels. It'll just sit there until some channel gets some data written to it. Then you'll pick it up, and you'll execute that block of code. These are sort of the core features of the core aspects of the multi-threaded support

in Go. But beyond that, as I say, Go is quite a simple language. It doesn't have very much in the way of exotic language features, unless you consider garbage collection exotic. But beyond those, it's intended

to be a language you can, you know, an experienced programmer can literally learn the whole language in a day or two. You just know everything there is about it. It's got, I think, 25 keywords, maybe 15 built-in types. It does have, I guess I should say, you know, unusually compared to a language like C++, it has maps built into the language.

And so should we start talking about generics now? Sure. Joe does not have generics right now. And one of the original developers of the language, and many other people to try to figure out a way to have the generic capabilities while keeping it, you know, as I say, simple and easy to use and true to the spirit of whatever that is. Okay, so that's interesting, because I was looking at, I think, Go's frequently asked questions page, and it has a note there about you know deliberately not including features from some other languages and generics

is one of the ones mentioned there but you're saying you are trying to add generics you're just trying to do it in kind of a way that fits in with Go. That's right exactly I mean there are clear uses for generics in Go just as there are in any other language, but we haven't had them. And some people miss them badly. Some people say, well, we really don't need them. I mean, since maps are built into the language, I can do almost anything I need to. I just write the specific type I want instead of having a general-purpose data structure or a general purpose function.

But there are many people who want them, and we're trying to figure out how to add them in a clean way. We've got a design draft out there that I think is doing pretty well with the Go community. I think there's still a lot of discussion about it, but I think most people are in favor of it. That's my sense of it. And so we're hoping to, I mean, the most optimistic possible would be that we can have ad generics around the Go 117 release, which would be about a year from now. Is it possible to describe what these look like maybe to listeners who are familiar with C++ templates? It's not dissimilar from templates.

It's a form of polymorphic parameters. Each function or type can have a set of type arguments, which is, you know, they can have their type arguments, and then a function can also have its regular arguments. The type arguments can just be, you know, any type, and then you can use the type within the function. Each type argument has what we call a constraint, which some other languages call a bound, and it's in the same space as what C++ calls concepts.

You can say this type argument has to implement these, any type argument for this type parameter has to implement these, you know, any type argument for this type parameter has to implement these features. It has to have these characteristics, which in Go, we would say it has to have these methods. And then within the body of the function, you can only use methods that the type parameter is required to have. And there's another way to handle operators like plus and less than and so on. So the idea being that you can compile the generic code with a constraint and then you can call it with some type

argument. I mean, there's various different implementation strategies, but you can call it with some type argument and you can know that the type argument is guaranteed to work. I was specifically trying to avoid the problem that C++ compilers used to have in the past where you'd make some mistake in the type you passed to a

template and you'd spit out 30 rare messages. I mean, they're a lot better now, but now you had always. Now you have to describe in the function exactly what kind of type you accept. And then we can check that at the instantiation. We can check right at the top, so to speak. Oh, this type doesn't meet the requirements so we can reject it right there instead of finding out 20 calls

down that the type argument doesn't quite work. And then there's details about syntax, which of course gets a lot of discussion because syntax is easy to talk about. And there's other details about exactly how to fit it into specific aspects of Go. But that's the basic idea. As I say, it's not dissimilar from templates. But I should say one way it's different from templates is we don't have any specialization in this design um so you know c++ has this really cool feature that you can use the templates themselves are a touring

complete language um so you can so c++ is like i'd like to think of it it's like two languages wrapped in one there's the regular language and then there's the compile time language which unfortunately uses a completely different syntax but but it's still quite powerful. But that's not the kind, as I say, Go aims for simplicity. That's not the kind of power we want to have in Go. That's not the kind of complexity we want to have in Go. So there's

no support for specialization. There's no support for sort of substitution failure. It doesn't exist in Go. So it's much simpler than the C++ approach in those ways. So if it meets the constraint, then it'll compile. If it doesn't, then it won't, kind of. Exactly.

So we haven't explicitly said this, but it sounds like Go is a strongly typed, statically typed language. Everything's known to compile time. That's right. I should have mentioned that. It is statically typed language. It is a statically typed language with sort of... It has dynamic components

in that it has what Go calls interface types, which are similar to what C++ would call an abstract base class. An abstract base class in which none of the virtual... in which all the virtual methods had an equal zero after them. Like a Java interface. Like a Java interface.

Like a Java interface, that's right. And it also has type reflection that's available at runtime. Nice. For any type. So it has those dynamic layers over it, but it is hard. It's a statically typed stat, and it's statically compiled language. Yeah, it compiles to a machine executable, just like C++ does. So you can do

function overloading type kind of things as well? Well, except that Go doesn't have function overloading in the C++ sense. Oh, okay. In Go, every function, you know, you can only define a function name once. Oh. It has exactly

those types. And if you want to overload it, you've got to give it a different name. Okay. That, again, is a great feature in C++, but it's the kind of complexity that we wanted to avoid in Go. And while we're at it, I should mention that another aspect of Go is that it doesn't have implicit type conversion. I was just going to ask. Yeah, that was a deliberate omission by the original language developers.

They're like, we've seen bugs over the years, especially as we migrate from one platform to another. We've seen bugs and implicit type conversion in C and C++. So it just doesn't exist. You always have to explicitly convert your types. Yeah, I'm close to saying that if I could remove something from C++, it would be implicit type conversions. It's rare that it's actually what I want. It's more likely that it caused some performance overhead or bug that I didn't want. Yeah, it can definitely surprise me. powered by Clang Tidy. Find subtle latent bugs by using LLVM Static Analyzer and CPP Core Guidelines checks.

Don't fiddle with command line switches or learn hundreds of compiler flags. Clang Power Tools comes with a powerful user interface to help you manage the complexity directly from the comfort of your IDE. Never miss a potential issue by integrating Clang Power Tools into your workflows with a configurable PowerShell script for CI-CD automation.

Start experimenting on your code today. Check it out at clangpowertools.com. What are some other features that were deliberately omitted? We talked about generics that is going to change in the future, implicit type conversion. I think I also saw assertions. Yeah, assertions were omitted. As you know, it was that was more of an attitude of we wanted people we'd seen that test suites at Google had kind of developed this almost another language

which was written for which described your test you'd say like assert equals this and that and your test would just turn into a whole set of assertion statements with function calls embedded in the assertion statements. And it just felt like Rob Pike was a big person who pushes this.

He was like, let's not put another language in here. Let's write your test using the existing language, which does mean, you know, more if statements. But the benefit, the benefit, the perceived benefit, at least, is first, you don't have to learn this whole assertion language. But secondly, you tend to get better error messages when you're forced to actually write out those error messages. And that leads me to another thing, which is that Go is a language which is OK with verbosity. Let me put it that way. Go doesn't mind making you write something out explicitly, even if you wind up writing the same thing, you know, multiple times. It's always easy to read, but there is more writing required sometimes. And then there's error handling.

Go doesn't really have exceptions. I mean, there's a sense in which it does, but in practice it doesn't. So error handling is almost always done with an explicit error check. You call a function, it returns an error. You say, did I get an error? If I did get an error, let's do something. And so, you know, let's handle that error. Let's return the modification of the error.

Let's just return that error itself up to my caller. There's none of this skip levels of flow of control via exceptions. There's no catching exceptions, not in ordinary Go code, at least. And so that adds a lot of boilerplate to Go programs. It's absolutely true, and it's one of the big criticisms people have about Go. But, and, you know, there have been many discussions about how to simplify it, although none of them have really caught on so far. But it's just part of the approach of Go, as I say.

It's okay to be a little verbose to make your program really explicitly clear. So then when you go back and read it, when you read your own program a year later, or when someone else reads your program, there's no, it minimizes confusion. So Go is willing to make that trade-off. When you return an error code, is there any way of telling the compiler this is an error code so that it can at least alert if you ignore it in some way or anything like that? The compiler doesn't do that, but there are linters that can do that kind of thing for you. Go has a pretty sophisticated set of VAT programs and link programs to examine code for all kinds of different checks. Because Go is a simple language, it's quite easy to add new linters.

It's very easy to parse Go programs. So there's a pretty sophisticated set of those tools. In general, Go tries to leave those kind of checks out of the compiler proper just to make sure we speed up the, you know, we keep the compiler as fast as possible and run checks as a, you know, we keep the compiler as fast as possible and run checks as a, you know, in a separate tool on a separate process. I feel like the languages that I am more familiar with, because I haven't programmed an Indigo at all, just for the record, like Lua and Lisp that are like, we are simple languages. They end up being simple in a way that makes the code impossible,

from my perspective, because in Lua, everything's a table. In Lisp, everything's a parenthesis, right? I mean, I'm exaggerating here, but it seems like a very fine line to walk to try to keep the language functional and relevant and usable and constrain this complexity. I totally hear you. You're right. Go is trying to walk a pretty fine line.

And I mean, there are many days when I'm surprised how popular the language has gotten. So, you know, I feel like, I mean, people, some people at least are voting for it. So, you know, that's great. And I don't know how long it's going to continue that way. But I mean, I hope indefinitely I like the language a lot. Part of what happened is, I mean, I'm stressing kind of the simplicity and so on. But I should also mention the development methodology, which the original language designers used, which was they said, you know, OK, we're going to write a language. You know, and they laid down some basic features pretty early on. But then every time they wanted to add a feature to a

language, they did it by writing code in Go. They wrote real programs in Go to see how it felt to them and to see what problems they encountered. And then they would say, you know, like, I just keep running into this wall right here. It's so painful to write this kind of code in Go. We've got to figure out how to address this. And then they would talk about it and figure out some way to handle it. They wouldn't add a feature unless all three of them agreed that it was required to make the language better. So I think, you know, perhaps a little, I'm less familiar with Lua, but Lisp kind of developed from a kind of a vision. Go developed from a practical programming steps to see what was needed and what, you know,

and only added what was needed. So I think that's part of what's helped it be fairly successful, that it really developed out of, you know, what people really do need as they're writing real code. What's the development of the Go language look like today? Is it still these three core developers who are kind of approving new features, or is it more of an open process now?

It's an open process now. I mean, it's an open source language, although I should say that the real core developers do still work at Google. We get a lot of contributions from outside as far as. But, you know, a lot of those are, of course, to the libraries. As far as the language itself goes, there is a proposal process that we go through to see what we're going to add to the language. But the language does not change very much. It's fairly stable.

And that's intentional. There's not a goal of adding a lot of things to the language or continuing to experiment. No, the language is meant to be pretty stable at this point. So aside from, you know, big features like generics, most of the changes to the language are more small things, more things where we sort of see that people are running into little problems here. We can make it just a little bit smoother. There isn't an expectation of adding any big new features or any radical changes to the language at this point.

Standard library? Does it have one? Yeah, it has quite an extensive standard library. Since it was designed to be a language that works with network servers, it has full HTTP and HTML support in the standard library that comes with every Go installation. It has a wide range of cryptographic protocols because they are not to be required for talking to all kinds of different places on the net. It's got, I mean, it's got echo expressions.

It's got all the basics, of course. Yeah, I mean, it's got other stuff that I'm not thinking of. But yeah, it's a pretty big standard library. And then there's a whole lot of third-party packages available out there for all kinds of different uses. Hopefully by 2023, we'll have networking in the C++ standard library. So are you familiar enough with C++20's coroutines to give us a comparison for how they compare to goroutines? Unfortunately, I'm not. I have seen the coroutine support. I think, you know, I'm kind of guessing here,

but one nice feature of goroutines is that the runtime handles the stack for you. So if you can do a deeply recursive call, you can use up, you know, megabytes or theoretically even gigabytes of stack, and the runtime will just allocate that for you. And then as you return out, if you don't need that stack for a while, the runtime will say, well, you. And then as you return out, if you don't need that stack for a while, the runtime will say, well, you're not using the stack anymore

and it'll take it away and make it available to some other Go routines. So, I mean, obviously all of this costs a little bit of execution time efficiency, but it makes it very easy for the programmer. You don't have to think about stack usage at all. So do C++ coroutines have that feature, or do you have to say how big the stack is going to be?

I know that the C++ 20 coroutines are heap allocated, but aside from that, I don't know how it deals with its own stack on that portion of heap space that's been allocated to it. I have a lot to learn still. Yeah, that's how you don't do coroutines,

but I suspect that other than that, they're probably pretty similar, except that in Go, it's just built into the language directly. You don't have to make a library call. Right. So I feel like, just maybe to clarify here, if you hear that Go is a deliberately simple language with few features, you immediately want to maybe jump to the conclusion of, oh, okay, well, the language is stagnant, but it sounds like it's really not stagnant. You are continuing to develop on it. We are continuing to develop on it. That's right. And we're continuing to develop the libraries quite actively. So yeah, I wouldn't say it's stagnant, but I would say it's a language that moves at a deliberate pace. And it sounds like the front end that you work on, the GCC one,

is kind of the secondary one. Is that right? That's right. Yeah. It is a secondary one. But it does work well. And it does support many more targets than the standard Go compiler because it's just a front end for GCC. So it automatically supports every architecture that GCC supports, which of course is quite a few. Yeah, and GCC's architecture supports still wider than LLVM's too, even. I believe that's true, yeah.

I was leading somewhere with that question now, and I forget what it was. Shoot. Oh, is there a published language specification? Yeah, absolutely. Okay. golang.org slash ref slash spec will bring it up to you. Yeah, one of the big advantages we've had from having multiple compilers is ensuring that the language specification describes the language. We definitely wanted to avoid the problem where the implementation defines the language,

like in early versions of Perl or whatever. So we wanted to make it very clear, this is the language. And I mean, this written down spec is a language, not whatever we happen to implement. And it's helped us a lot over the years to say, oh, this turns out like this spec is unclear, because suddenly we'd see the two implementations. I mean, now there's more than two, but at the time we see the two implementations were doing something different. And we're like, okay, we better clarify that. Yeah, that's actually where I was hoping to get to there, because it seems like the work, it's easy to undervalue the work that you're doing.

The work that you're doing is incredibly important to making sure that this language does what they think that it does. Yeah, absolutely. More than we're aware of that but yeah it's a good point thank you for pointing it out okay uh is there anything else that you want to talk about with go before we move on anything we haven't discussed already about features i encourage people to try it out you know i mean when thinking about c++ versus Go, C++ is, of course, a more complex language. But C++ will give you the ability to get that last little bit of execution time. C++ programs, you know, a well-tuned C++ program is always going to be faster than a well-tuned Go program.

I think there's no doubt about that. But, you know, if you're writing networking code where your program actually is almost always just waiting for the network, who cares? So I'd encourage people to give Go a try. As I say, it's a very easy language to pick up. Hopefully the Go routine support in particular will give you some ideas

of how to write your C++ code and, you know, see what you think. See if you like it. I might have to check that out. Yeah. You've mentioned UUCP, GoldLinker, and GCC, and you said you've been working on open-source software since 1990. Are there any other projects you're involved in right now besides Go?

No. Go is definitely the big one. I mean, I have some tiny little projects of my own, like a backtrace library that's gotten pretty popular, but nothing substantial. What is the backtrace library. It's gotten pretty popular, but nothing substantial. What is the backtrace library? It's a little library that you can link in. It's written in C, and so you can link it into your program and you can get a stack backtrace at runtime.

It's mainly designed so that if your program crashes, it can print out a stack backtrace when it crashes, but then it's also used, people wind up using it for various other purposes as well. It's used by the Rust toolchain, for example. What is the name of that? That's definitely a view of some interest. It's just called libbacktrace. Okay, so that one, if it's what I'm thinking of, it's been around you've been in development for a while, right? Yeah, maybe five years.

Okay. That's pretty cool. Yeah, I mean, that's awesome. Does it work cross-platform? Yeah. I didn't write it, but it supports Windows and Mac OS, as well as pretty much all Unix systems. Oh, and the other cool thing is you can run it from a signal handler and get a correct backtrace out of a signal handler. Awesome. Okay. Well, it's been great having you on the show today, Ian. Is there anything else you want to let us know before we let you go?

Where can listeners find you online, too? I have a blog, but I haven't updated it in years. So you can find me on the Go mailing list, basically. That's emt.golang.org. I'm not really a social media user, sorry to say. But yeah, shoot me an email. Thanks for having me. It's been great chatting.

Thanks for coming on the show. Awesome. Thanks so much for listening in as we chat about C++. We'd love to hear what you think on the show. CppCast on Facebook, and follow CppCast on Twitter. You can also follow me at Rob W. Irving and Jason at Lefticus on Twitter. We'd also like to thank all our patrons who help support the show through Patreon. If you'd like to support us on Patreon, you can do so at patreon.com slash CppCast. And of course, you can find all that info and the show notes on the podcast website at cppcast.com. Theme music for this episode was provided by podcastthemes.com.