Meet the Authors – Go Language (Cloud Next ’19)

am Megan Sanicki. I’m an open source
strategist for Google Cloud. And I am really excited to
be here to lead this panel, where you can meet
the authors of Go. Well why, don’t I first just
let them introduce themselves to you? IAN TAYLOR: Hi. My name’s Ian Taylor. I’ve been working on Go since
2008, before it became public. I’m a Google employee. And I work on the
tools and the libraries and many other things. ROBERT VAN GENT: My
name is Robert Van Gent. I am not actually one
of the inventors of Go. But I started programming
Go about five years ago, working on machine management
tools inside Google. I converted a bunch of machine
management applications from Python to Go. And I joined the
Go team last year. And since then, I’ve been
working on the Go Cloud development kit, a set
of tools for making Cloud application in Go awesome. ROBERT GRIESEMER: Hi. I’m Robert Griesemer. I’ve been with the Go team
since 2007 when it was started, which is 12 years ago, which
seems like a crazy long time. I’ve written a bunch of
tools that some of you guys might be using, like gofmt. So if you’re not happy with
that, you can complain with me. It may not help, though. And more recently,
I’ve been working on trying to get Go
into the Go 2 phase. BRAD FITZPATRICK: I
am Brad Fitzpatrick. I’ve been working
on Go since 2010. And I work on the
standard library a lot, things like the HTTP packages
and the build system. I wrote goimports. I bounce around to
lots of little places. TYLER BUI-PALSULICH: Hi. My name is Tyler Bui-Palsulich. I work on Go on Google Cloud. So my goal is to make
it as easy as possible to use Go with and on GCP. So it’s like Robert said. If you have problems
with Go on GCP, you can maybe be annoyed at me. That might help. MEGAN SANICKI: Excellent. So these are our wonderful Go
experts, will be the panelists. And I just want to get
a sense for the room before we get going. Can you raise your hand if
you have never used Go before? All right. Well, welcome. We’re excited to start
teaching you more about Go. Can you raise your
hand if you’ve started using it a little bit? All right. And then raise your hand
if you’re using it a lot. All right. Excellent. We love that. Good. So we’ll have a little bit
of answers for each stage that you’re in. And as it was
mentioned before, this is going to be interactive. We have some questions that I’m
going to ask that have come in. But we also are going to take
questions from the audience. So if you do have
a question, you can just start making your
way down to the sides. Both of these team
members are going to have microphones where
you could ask your questions. So you can just queue up. So why don’t we just get
started with a nice, easy one? So tell me, what is
Go best at doing? What are all the great ways
that you should be using Go? IAN TAYLOR: Go is good
for everything, of course. MEGAN SANICKI: Of course. IAN TAYLOR: It’s
very good for Cloud. It’s a simple language. It’s easy to write code. It’s easy to write code
that runs very efficiently. It’s easy to write code
that runs very concurrently. A lot of the core
infrastructure of the Cloud is written in Go itself. Kubernetes is an easy example. It’s well-designed
for web servers. It’s good for a lot of things. MEGAN SANICKI: That’s great. Anything else you
want to add, or where you’ve been seeing Go
being used really well? ROBERT VAN GENT: I
was just going to say, like I said, I started
using Go when I converted a bunch of large
Python applications, where they were pretty
performance-sensitive and the scale of
Google’s machines was just getting so large that
Python wasn’t working anymore. And Go was really great
for concurrency and also for just managing a
large application, having a type-safe language
was a lot easier to manage than Python. ROBERT GRIESEMER: Something
that we hear a lot from people is how easy it is to learn Go. So it’s probably
not an exaggeration that if you know how to
program, within a week, you can be productive in Go. BRAD FITZPATRICK: It’s
been a number of years since I was super
religious about Go. But at the time, I was
always telling people how I hated the trade-offs
of all the other programming languages, where if
you wanted to write performance-sensitive
code, you would have to write a tedious language. And if you wanted to
write in a fun language, then you would have to deal
with bad concurrency, or lots of callbacks, or
bad performance, or runtime failures due to
missing type information. So it was really nice
to write in a language that was both fun and fast and
that would let you get going and write code right away. So I’m still in love with it. And I haven’t found
anything that’s as fun and just productive. MEGAN SANICKI: That’s great. One more. TYLER BUI-PALSULICH: I think
one other thing I’ll call out is, one of the goals
of designing Go was to make it easy to
develop in large teams over large amounts of time
or long amounts of time. So stuff like gofmt and
goimports, and standardizing the language and how
it’s used makes it so that when you’re
looking at Go code in one spot, made by one
person, it looks very similar and hopefully, easy to
understand, as Go code you’ve seen somewhere else. MEGAN SANICKI: Excellent. Good. So do we have any other
questions from the audience? Just to remind you to come down. Yeah. Go on over. AUDIENCE: Hi. My name is Pablo. I have a question for you. What do you think about the
Bazel build system for Go? IAN TAYLOR: What do I
think about the Bazel build system for Go? I think it’s very good
for complicated programs. Go comes with its
own build system, in the sense that it’s
easy to build pure Go programs with the tools
that are provided by Go. But if you want to work on
a multi-language program with many different
parts, also if you want to deal with a
lot of generated code, then I think Bazel works
really effectively. It does have full support
for Go these days. And lots of people use it. We use it internally. We use Google’s
internal version of it. So yeah. It’s a good system. BRAD FITZPATRICK: You
say it has full support, but there’s a lot of
things in X-tools, like the package loader and
stuff, that’s in development. So a lot of the tools that
exist in the Go ecosystem historically assumed that you
laid out your code on disk, the way that Go’s built-in
build system works. And so there’s an
increasing amount of work recently about making
our tools agnostic, about whether you’re using Bazel
or you’re using the Go tool. So it’s getting better,
only in the last maybe year. IAN TAYLOR: That’s a good point,
especially for generated code. MEGAN SANICKI: OK, great. And I see we have another
question coming in AUDIENCE: Adding to what
Tyler was talking about, the benefits of Go, or
what it is good for, I think it’s very good for
collaborative development, where it’s so easy to import
somebody else’s GitHub repo and their libraries. And Cobra is something
that almost everybody who develops some CLI or
the other might have used. So that’s one thing that
I wanted to point out. My specific question
that I had was, is there plans of importing
commonly-used GitHub repos into the standard library? BRAD FITZPATRICK:
On the contrary. We want to get rid of things
in the standard library. We even have a FAQ
entry about it. Right now, stuff exists
in the standard library, just because initially,
there was no GoGet. And so if we wanted to
put some code somewhere, it had to be in the
standard library. There used to be
a Space Wars game. There was an NTP Usenet client. There was like tons of crap
in the standard library. And right before Go 1,
we deleted a ton of it. And we forgot to
delete even more of it. So there’s a lot
of things that are in there that are an accident. And we didn’t have internal
packages or private packages. So there’s a lot of crap that’s
in there, just for TLS, that’s only public because of HTTP. And so there’s a whole lot of
low-level crypto networking details that we wouldn’t really
want to expose on their own. We might want them to live on
GitHub or something, anyway. So I don’t think the
trend is to put more stuff in the standard library. It’s really to make it
smaller and more modular. IAN TAYLOR: But I
want to add to that. With the Go modules work that’s
going on actively in Go right now, we’re making it
much easier for a program to pull in a reliably
determined set of sources from an external library. And we’re also developing better
module discovery and package discovery tools so
that people will be able to find the
packages that they want. And also, have a way of
knowing that these are packages that a lot of other people
use and are therefore highly reliable. And it’s tempting
to move everything into the standard library. But that doesn’t solve
the problem of who’s going to actually maintain it. The Go team is not
particularly large. And so we don’t want
to put something in the standard library which
we can’t take care of ourselves. But what we do instead
want to make it possible is that you can
build your Go program and know that you’re
pulling in libraries written and maintained by
other people that you know are high quality because
other people vouch for them. That’s the direction
we want to move in. MEGAN SANICKI: That’s great. OK, we have another
question over here. AUDIENCE: Hi. My question is for Tyler. Seems that Go have been launched
near about 10 years ago, as well as Google Cloud
about 10 years ago. But from my point
of view, support of Go in Google Cloud and Google
App Engine flexible environment still looks insufficient
from my point of view. Are you guys prefer
Java, aren’t you? TYLER BUI-PALSULICH: Yeah. I think this is something
that we’ve really tried to improve in the
last couple of years. So a couple of
things that are new are App Engine standard
second-gen run times. So this idea applies for
all of the App Engine supported languages. But specifically for
Go, if you ever used App Engine standard before, and
you had to import App Engine– anyone, raise your hand, used? A couple people. So now you can use
whatever library you want. Before, one of the issues
that would come up is, you had to use a special
package to make HTTP requests. So you run your
service on App Engine. You need to make some API call. You can’t use net HTTP. You need to use URL Fetch, which
was this other package that we maintained. Now latest version
of Go, that’s not something you need
to do anymore. Much, much nicer to use. And that’s all based on gvisor. That same technology was
used for Cloud Functions. And so we released Cloud
Function support for Go about a year ago, I
want to say, starting with an alpha and beta. And Go 111 for Cloud
Functions just went to GA. So those are some of
the ways that we’ve tried to improve support. And then the one other way to
run your Go code is Cloud Run. And you can run whatever
language you want, whatever language
version you want. And as long as you’re using
the cloud client libraries, hopefully, that’s
a nice experience. And then you mentioned
App Engine Flex. For someone who
hasn’t used it, it’s similar to App Engine standard. You can also provide
your own container images that you want to run. It will scale up for you. But it has a minimum
instance count of 1. That’s the default level. And then if you’re comparing
that to Cloud Run, which– how many people saw
that announcement? It was in the keynote today. A lot more people. So Cloud Run is
serverless containers. So you define whatever
container image you want. And that can bundle whatever
Go version you want. And then that scales up
and down really quickly. If you deploy, it literally
takes a few seconds. It’s really, really nice. So we’re working on it. I hope it’s much better than
it was, say, 3, 5 years ago. ROBERT VAN GENT:
And I wanted to put in a plug for my project,
the Go Cloud Development Kit. We’re another open
source project. And we’re trying to make Go a
great language for developing cloud applications, not just on
GCP but on any cloud, including on-prem or running
on your local box. So we’ve developed a
bunch of portable APIs for cloud services, like Blob
or Pubsub, things like that. And then we have implementations
for different cloud providers. So you write your app once
using our APIs, native Go APIs. And then you plug-in with simple
config or initialization time changes. You plug in whatever
implementation you want. If you want to run
locally on your box, you use that implementation. If you want to run on
Amazon, you plug in S3 or SNS for Pubsub. And so that way,
you have flexibility and good development workflow. MEGAN SANICKI:
Anything else to add? If not, we do have a
question coming in. AUDIENCE: I just have a question
with regards to WebAssembly. What is the roadmap
for integrating Go with WebAssembly? Will there be one day where
we can do away with JavaScript and have Go replace it? BRAD FITZPATRICK: I hope so. But it’s getting better. None of us are really doing
the WebAssembly back end. There’s some people on the Go
team that are reviewing it. But it’s mostly done from
external contributions. There was just a
change that landed that made it smaller
and faster, the output. IAN TAYLOR: Why don’t you
say what the status is today? BRAD FITZPATRICK:
The status today is, you can take programs and
compile them for WebAssembly. And you could run it
alongside Node.js stuff. Or you could run
it in the browser. And there’s an ecosystem
of UI framework stuff so you can write
front end web apps. And you can write it all today
without any JavaScript at all. So it’s nascent, but
it’s coming along. MEGAN SANICKI: And actually,
I just want to see– we’re hearing a little bit
through these questions, what’s new with modules and
other aspects, functions. Could you just tell
us, in one big arcing story, what is new with Go? There’s just a lot happening. ROBERT GRIESEMER:
Well, I can talk a little bit about the
changes to the language. So until the most
recent release, to 112, we have made almost
no changes to the language after an initial phase where
we made small, minor changes. So for the last couple
of years, we basically have frozen the
language, even when it comes to small, minor
adjustments that would have been fully backward compatible. But now we’re trying
to move forward towards what we call Go 2
And as part of this process, we have started to look at the
incoming proposals that come from the open source community. And we review them
and we identify the ones that seem promising. And so for 113, for
instance, we have started making the first
significant changes to the language. So now you will have,
with 113, assuming we’re going to actually
say yes at the very end of the development cycle,
of binary literals. That’s going to be hexadecimal
floating point numbers. Another thing is, we can
do now non-constant shifts without uint conversion,
which is probably going to clean up a lot of code. And literals can
have under bars. So if you have
very long numbers, you can have now underscores
in there to space them out. Apparently, something
that people really wanted. And there is
probably going to be some changes to the
libraries, which I probably not have the
best overview at the moment. BRAD FITZPATRICK:
I was also going to add that all these language
changes that are coming are like warm-up ones for
us to work on the process. So they’re kind of boring,
and they’re kind of small, but we’re going to do a couple
additions to the language. We’re going to do a couple
removals to the language and get practice
with that process. There’s a couple of
constructs in the language that we would like
to maybe remove. And so modules lets you specify,
on the granularity of a module, what language version
semantics you want. So if you say you’re
targeting Go 112, we can remove
something and Go 113. As long as your module
still declares 112, that language feature exists. But once you want some
new feature in Go 114, and you say that, then
you lose the features that we removed in Go 113. So it lets us slowly
evolve the language without breaking anyone. So there may not
actually be a Go 2 ever. But we say Go 2,
as in new stuff. But it may just be that
generics or something fun lands in Go 117. So keep that in mind. Whenever we say Go
2, it’s probably more of a marketing expression
than actually a thing. TYLER BUI-PALSULICH:
And just to call out the three main things being
looked at by the team for Go 2 are dependency management. So modules are the
Go solution to that. Came out starting in 111. Now again in 112,
and then hopefully, on by default in 113. And then the others are
errors and generics. So errors, the goal there
is to make it easier to develop and respond
to and check errors. And then last one, generics,
of basically deciding, should we include them? Should we not? If we do, in what form? MEGAN SANICKI: Great. Thank you. I think we have a question. AUDIENCE: Brad actually just
answered my original question. So a different question. I think one of Go’s
strengths, as you mentioned, is how few features it has. Could you give an example of
a feature in another language that you really like that
wouldn’t make sense in Go? MEGAN SANICKI: That
was a good one. You get a plushie. IAN TAYLOR: Well,
C++, for example, is a very complex language. But it has a number of
features that are very nice. For example, in C++, you can
templatize based on a constant and use that to compile
different versions of your code based on constants that are
passed into the template. And you can combine that
with variadic templates. So you can actually redesign
your data structures based on how the
template is expanded to make them more
or less efficient, depending on the
exact features you need from the data structure. You can actually
change how much memory it requires at compile time. So that’s a cool feature. And I’ve used that feature
myself when I’ve written in C++ in the past. But the complexity
of understanding how that feature really works. I don’t think it’s appropriate
for a language like Go, which is designed to be– as Robert said earlier,
it’s a language you can learn very
quickly if you’re familiar with other
programming languages. And even if you’re not
familiar with other languages, it’s a great language
to start with. We don’t want features
like that, I think, in Go. But it’s a great
question, though. BRAD FITZPATRICK:
In general, Go tries to give you 80% of what you
want with 20% of the complexity. Every time you try to
solve a little bit more or get it closer to 100% of what
you want, the complexity just ramps up way faster than
what you’re delivering. ROBERT GRIESEMER:
There’s one feature that’s relatively easy
to understand, I think, which is macros,
which Go doesn’t have. But there’s plenty of times when
I really, really, really wanted to just write a macro. But the problem with
a macro is, it’s possible to write
code that’s almost indecipherable afterwards. So it’s easy. It’s like, write once,
understand never. So it’s a feature
that definitely that we don’t want to
have in the language, because we put a lot of
emphasis on readability of Go. Because code, in our
experience, is read much more often than written. And so that’s a valuable
feature to maintain. MEGAN SANICKI: Great. I think we have another
question coming in. AUDIENCE: So Go is
about 10 years old now. So if you can comment
a little bit about, what were the
motivations that drove you to develop Go 10 years ago? And are these drivers
still valid today? ROBERT GRIESEMER: So
this is a question that’s been answered
many times on the web. But let me try to shortcut it. So in 2007, there was a lot of
code to be written at Google. Still, there’s a lot of code
to be written at Google. And some of us really
felt like at that time, the choice of
programming languages was somewhat unsatisfactory. So we were somewhat
stuck between a rock and a hard place, if you will. Some people called
it Java and C++. So there was a strong desire
to have something better. And so we embarked on
coming up with something that felt like a much
better solution at that time to the kind of
systems programming that we wanted to do. Because it seemed that
a lot of the problems were actually solved many,
many years, and maybe decades before, but
were not actually solved in programming
languages that were available at that time. And so I think a
lot of those things are still maybe
a little bit less true today, because
there’s actually a wider variety of languages. But when it comes to
things like concurrency, I think Go is still
way in the forefront. I don’t know of
any other language where it’s so easy to
write concurrent code. In terms of compactness,
I think Go is still extremely small
language and very easy to grasp and understand. So I think many of these
things are still valid. And, of course,
the language is not just compact and
small and clean, but it’s also very efficient. And I think that’s still true. We’re maybe not
at C or C++ level, but we are close enough for
99% of all applications. IAN TAYLOR: And I want to also
allude to something that Tyler mentioned earlier, which
is that Go the language was designed, as
much as possible, for programming in the large,
for many people working together on one program. And a lot of decisions
about the language were made with that in mind. How well we succeeded
at it, I’m not sure. But I think it was an
important goal at the time. And I think it’s even
more important now, especially as open source
has continued to get larger and larger and larger. Languages that help people
work in larger groups, I think, is a very important goal
for modern languages. And I think Go has aimed
for that all along. MEGAN SANICKI: That’s good. Anything else? Well, I know we have a very
patient person over here who’s waiting to ask a question. AUDIENCE: One of the things
I’ve really enjoyed about Go is the community. And I’m wondering how you all
stay engaged with the community and help build that,
especially in the face of contentious decisions
or changes to the language. IAN TAYLOR: So the question
is about the community and how we work
with it, I guess. Yeah. The community for Go
has been incredible. We’ve had so much support
from all of you, from people all around the world, working
in Go and contributing to Go. And then you asked,
how do we deal with contentious decisions? I think we try to be
as open as possible about how we’re
making our decisions. And I shouldn’t even say
as open it’s possible. We try to be completely open
about why we’re deciding the way we’re deciding. And things do get
contentious at times. There are disagreements in
the community, of course. There have been
disagreements in the past. And we listen to them. An easy example is
for the product– the language added a
feature, type aliases, maybe three, four years ago. And before type aliases
were introduced, we actually had a
separate proposal, which was a different
kind of aliasing proposal. And we designed it. Robert and I both worked on it,
and other people within Google. We put it out there
saying, this is something we think will
be useful that we’d like to add to the language. And there was a lot of
push back in the community. It did become contentious. And I think we tried as hard
as we could to listen to it. We withdrew the proposal. We put out a smaller and
simpler proposal, which did then get added to the language. Also, we explained
the use cases for it. And so I think it’s been a
learning process for all of us to work with the community. But I feel like the answer
really is just to be open, to explain why we’re
thinking what we’re thinking. We can’t take every
idea that comes in. We don’t agree with
every idea that comes in. Ultimately, a small
group of people is going to make the very
final decisions about what’s going to happen. But still, most
of the best ideas have come in from outside. MEGAN SANICKI: That’s great. Being open is important. Any other comments on that one? OK. Then I’m going take a
question on this side. AUDIENCE: Hi. So you guys are great at keeping
stuff backwards compatible. But if you could go tomorrow to
work and just change something completely without thinking
about it, what would that be? ROBERT GRIESEMER: If you
can go back all the way to the beginning of
Go, the original Go looked very, very different
than the one that we have now. And in the early days,
we had the luxury to actually make
a lot of changes. For instance, the very
first version of Go, you had to write semicolons. And now you don’t have
to write them anymore. Actually, for last 10 years,
you didn’t have to write them. And there’s a whole
bunch of things that we probably would like
to remove, some of which we can’t remove right now. One of them, again,
a simple example is, right now, you can
say string of an integer. And that gives you
the corresponding– it doesn’t give you a string
version of that integer value. It gives you the corresponding
Unicode code point as a string, so to speak. And that’s very confusing. And that was there just
for historic reasons, because it was convenient
in the beginning. And that’s something
we want to take out, but we can’t, because it would
break potentially things. And there’s a lot of
other things, probably. I don’t have a good list
in my head at the moment. BRAD FITZPATRICK:
Ranging over a string, giving you the UTF-8
code points rather than the bytes of the
string, which is inconsistent with
the slice of bytes. There’s things like
when you do a range loop and you want to capture,
you have a closure that captures one of the variables. The variables are just the same
variable for the whole loop, rather than every
iteration of the loop. So you can’t safely
start a Go routine with a closure in the
middle of the loop. And hat bites a lot of people. So there’s a lot
of little things that we realized after the fact,
but we can’t really change it. IAN TAYLOR: I would get rid
of return statements that don’t list the values
that are being returned. ROBERT GRIESEMER:
From the beginning, we tried to make Go really
platform-independent. And so most of the language is
actually platform-independent. You can write some code, and
you can run it on any platform. But some basic things, like
the integer type int or uint, they are platform-dependent. If you were running on a 32-bit
platform, you get a 32-bit int. And if you’re running
on a 64-bit platform, you’re getting potentially a
64-bit int, maybe a 32-bit int. So that’s actually
something that I think, in retrospect, was
probably a mistake. Because if you actually move
from one platform to another, you might incur
problems, or you may have to change code
and things like that. So it would be nice if we had
had a better solution for that. And one approach
could be, or could have been, maybe, that an int is
arbitrary size and the compiler does the right thing. And you never have
to worry about it. That’s something that
would be much, much harder, or is going to be much,
much harder to do now. MEGAN SANICKI: Well, we only
have a few minutes left. So we’ve got a few questions. People are queuing up. So we’ll see if we can go
quickly and answer some more questions. AUDIENCE: Sure. Just really quickly,
what would you say has been the
biggest challenge in creating Go, or
just a programming language in general? Is it the intricate
technicalities? Or is it understanding user
behavior and creating something to adapt to user behavior? IAN TAYLOR: So what’s been
the biggest challenge in Go? I’d say that, for me at
least, the biggest challenge is keeping it simple. It’s always so easy to
add another feature. And you can see so
clearly how useful it would be to have this new
facility in the language. But if we add every new
facility in the language, then we get something
so complicated that it’s very difficult to use,
like some existing languages today. And so I’d say the biggest
challenge has been to say no. MEGAN SANICKI: OK, over here. AUDIENCE: Hi, again. I have read a blog post,
the Golang official blog, that talks about a context. And it says that
internally in Google, it’s mandatory to pass the
context in the first argument in every function. First of all, I wanted to know,
what do you think about it? And also, I’ve read on
the internet somewhere that context will be removed
in Go 2 or something. I don’t know if it’s true. BRAD FITZPATRICK: There are
no plans to remove context. If anything, it will
become more pervasive. AUDIENCE: And what about
the mandatory thing of passing the context
in the first argument? Do you think everybody
should do it outside Google? BRAD FITZPATRICK:
Yeah, probably. So inside Google, a
lot of it was implicit, with magic ThreadLocal stuff. And so it was great
when it worked, because your context was
threaded through automatically. Because all functions
just picked it up from ThreadLocal storage. But once you start to
do something tricky, a lot of people didn’t
know how to stitch together their contexts. And they wouldn’t even
know that they didn’t do it until they had a
production problem and they went to look at
the global trace dashboard. And then they noticed
that none of their stuff was stitched together properly. So if you make it
explicit, you get it right from the beginning. So when you have a
production problem, it’s usable, the traces. IAN TAYLOR: And as far
as whether the context is the first
argument or not, it’s convenient to have it
be the first argument. It just makes the code be
stylistically consistent. But it doesn’t have any
meaning beyond that. It just helps if the code looks
similar in different parts of Google. BRAD FITZPATRICK: One
thing I’d like to do is maybe make context.context
be less stuttery. Because right now,
you write CTX. And so if you’re reading it,
it’s contextcontext.context. And right now, we
have one built-in type in the language, one
built-in interface type, which is error, which is
just an alias for anything with an error string method. So it would be nice maybe just
to make context first class, too, and make that built-in. So at least then it would just
be contextcontext or something. MEGAN SANICKI: OK. So I think we can get one,
maybe two questions in. We’ll start on this side. AUDIENCE: Hi. For such a new language,
I think my math is right, that there’s over 50 years
of experience and knowledge just on this stage. Can we get maybe one tip from
each of you for writing in Go and getting into the Go mindset? TYLER BUI-PALSULICH: I’ll start,
and I’ll take an easy one. Run gofmt and
require it on submit. You should run it on Save
as you’re writing your code. Same way with goimports. BRAD FITZPATRICK:
Small functions. Lots of tests. ROBERT GRIESEMER: Play
with it in the playground and experiment. ROBERT VAN GENT: Be
careful with context. I’ve had a lot of bugs with
using the wrong context in the wrong place. IAN TAYLOR: Be explicit about
what you’re trying to do. Keep your functions. Don’t use implicit information
passed between functions. MEGAN SANICKI: OK, great. We’re going to sneak
in one last question, then we’ll wrap it up. AUDIENCE: Hi, everyone. I have a question for Brad. You started writing the second
iteration of the Net::HTTP package. Can you talk a little
bit about the problems you have with your
original iteration of it and maybe what the status is? BRAD FITZPATRICK: Well,
I have a long Wiki page about all the things I dislike
about the first one, which grew organically
over 10 years or so. So I don’t really have time
in 30 seconds to go over that. But the current status
is, I got distracted. There were other
fires and stuff. It’s still my goal. It’s probably the
highest priority thing I should be
doing, is finishing up the new HTTP client. IAN TAYLOR: We’re all
looking forward to it. MEGAN SANICKI: OK. Well, we’re out of time. But thank you so much
for joining us and all your great questions. And all the credit goes to these
great experts and the community that’s building Go. [MUSIC PLAYING]

8 Replies to “Meet the Authors – Go Language (Cloud Next ’19)

  1. Great talk team. The generics proposal is great, even without contracts. Looking forward to seeing that in the language!

Leave a Reply

Your email address will not be published. Required fields are marked *