Transcript

My name is Aarti Parikh and today I'm here to talk about Go, and why it's a really important language for enterprise development today. Everybody is being here in this room. It's pretty crowded I think. It's the largest audience I've ever spoken to. So I'm pretty excited to be here. I am a new engineering manager. Before that I mostly worked in startups. For the last three years I've been writing in Go. Then I started the two meetups that Ashley mentioned in Silicon Valley.

So rankings- let's talk about the TIOBE index, which is the one where we saw skyrocket and then later it went down, but it's going up again. Rankings matter. It is an indicator that the language is getting popular. Why is it getting popular? What is happening is that a lot of startups have adopted Go and they have found success with that. So Uber is pretty much Go with their microservices and all of that. There's a lot of Go at segment, if you know, segment. So there are a lot of startups that were writing in Go and they found it really fast and they found productivity was high, and they also found that they were using less resources. As a result, performance, productivity and simplicity. So it's been great.

Now enterprises are starting to pay attention. They're like, ''Oh, we also want to do this. We can save money. And also we can find good developers.” People say history repeats herself. I don't think it repeats itself. I think that we have all of these bad things that happen in history, and then in the next generation, we try to fix them in some way, but I don't know if you actually fix them, or we make more of a mess or whatever. We're doing something. So it happens in programming languages too. I love Mark Twain, so I have his quote up there.

Going back in history: this slide is actually going back to 1970. was alive, but I wasn't writing code in 1970. But all these companies were writing business applications. So this is an enterprise application development pitch. Go is good for an enterprise application development. And so when we talk about that, we're talking about invoicing and payroll and finance and all of those things, that business logic stuff, that was running on Cobol based systems on proprietary systems and then came the open systems, the open architecture and X3H6 and all of that. A lot of C and C++ was being written, but it wasn't taking on for the business application needs.

There was this like, “Oh, this is causing, this is too hard or this has these problems”. This again, like Ashley said, isn't about which language is great or what, which language is good for which system that you're writing. If you're writing low-level stuff, C, C++ were great, but they weren't great for business applications. And that's where Java's timing in the early 2000s was perfect. I've written a lot of Java. I raised my children writing Java. But yes, my daughter's taking AP computer science now and she has to study Java, so I'm helping her with recursion and all of that.

But why not C++? C++ is on the list of the most difficult programming languages in the world. It's number 10, but I think Haskell is number one for me. I've tried to learn Haskell many times. I have several books on bookshelves of FP books. But it's a hard language to learn. If you're been doing application development and you are in the enterprise application development world, it's not well-suited. Going back again, Java was like perfect for its time. At the time when Java came in, the early 2000 was late groundbreaking or like, “Oh we don't have to deal with C makefiles and auto conference from bill tools and write for the compile for this and compile for that and all of that.” So it changed things and memory safety, which was the earlier talk today, was important in this area because Java was garbage collected and memory safe are no pointers.

Innovation & Growth Early Years

This is a little bit of history. I have some history with Java. I was young, I was really excited about coding and I was doing all of this stuff. Every time a new article would come on O'Reilly- O'Reilly was like our water cooler, just like hacker news is today. So we're like, “Oh, this article came on hibernate and now everybody's excited about hibernate.” And Gavin Newsome, I don't know if anybody knows, remembers his name. Mark Flurry, who wrote Jay Boston, changed things because it was open source, and changed things from websphere. I don't know if anybody here knows those names.

But extreme programming, anybody? Anybody read that book? Ken, back. Oh yes, that was groundbreaking. Wesley’s scary. That book like changed my life, because J unit and unit testing and all of the innovation that happened during the Java years was really amazing, at least it was for me. Then design patterns and we were all innovating on all of these things; dependency, injections, spraying- we're still using spring. That is the sort of what enterprise application developers are using everywhere. Maven, how to do dependencies was beautiful. You had the Maven sitting locally on your local system and then you had all the layers.

I see the excitement around via SKO today, and it's a little bit of history because the eclipse plugin architecture reminds me exactly of what we as code is today, because I wrote plugins in Eclipse. I was so into all of this. It was a good time. And I was promoted. I was an architect and it was like, “Hey, I have an A in my title.” I was an architect for a healthcare startup and I was writing a lot of abstractions, that was the thing. I loved it. So I was already abstract. We are already abstracted from the JVM. You don't know what's happening on the hardware. Then we're writing frameworks upon frameworks. It was fun. It's fun to write, “Hey, I can just do this and all of this stuff happens on its own.”

So that was sort of my story. But what happened as a result, was engineers on the ground floor who were coming in, they were like, “This is tedious. This is verbose. Why am I doing all of this factory builder, blah, blah, blah?” To write a thread in Java was like six lines of code and executed a thread factory, blah, blah, blah and then something inside. So it was crazy. I felt like it was like object-oriented programming, extreme object-oriented programming, and heavyweight frameworks. Startup times were slow. You would just be sitting. How many times he was sitting and just watching j boss startup. We had this discussion at PayPal, sitting in the audience. We talked about how Spring Boot came to the rescue but still, Java was slow. And for concurrency things, Java's concurrency model is always threads map one-to-one, with Java threads. That was the limitation.

Don’t Underestimate Developer Happiness

Then I went to this conference and I met Dave Thomas and I read his book. Anyone, Dave Thomas, “Pragmatic Programmer”? Oh, my gosh. Only two, three people. So yes, Bruce Tate, he wrote this book, ''Seven Languages in Seven Weeks.'' And he tweeted this outside, “Dave Thomas ruined Java for me.” I saw that and I was like, “That's me. He ruined it for me too.” I read his book and then I read all of the Ruby books that came out and then it changed things for me. So my thing with enterprises- because this is an enterprise application developer conference- is that developer happiness matters. Don't underestimate it. I was unhappy. I was like, “Hey, I wrote all of this stuff,” but I wanted to write in a fun language that me happy and Ruby made me happy. Ruby on Rails at the time, convention over configuration that was another huge growth that happened in the community.

This is the time that I also got involved in communities where I found the Ruby on Rails and Ruby community to be amazing. I was like, “Wow, this is a little group of really passionate people, writing stuff, doing stuff that they're excited about.” That was a sort of my story. At PayPal, the story was node.js. So the VP who's Org I work in, Geoff Harold, he's kind of famous at PayPal for heralding this big change with node.js because Java- PayPal was all Java. Then he came and I sat with him once and he's telling me his story, like, "You can't tell this to anyone," so I'm not going to tell his story. But how he brought about that change is really cool. So if you ever come to PayPal and have a one-on-one with him, you should talk to talk to him about that. He was able to bring about big change at PayPal, and that developer velocity at PayPal just like boomed. You look up the Java to node.js story. That was a big part of it. In my discussion with him, developer velocity mattered. We wanted to ship products fast because we wanted to keep up with the competition. Not only that, but you see your score and running and that's important.

10 Years after the Rise of Dynamic Languages & Web Frameworks

But what happened after? I don't know how many people in the audience follow Gary Bernhardt? Yes, he's awesome. Yesterday he tweeted that he runs this conference Deconstruct Con, which is really cool. If you all get a chance to go there, and he does also live coding and all of this. He tweeted that, “Oh, my gosh, 10 years after the rise of these dynamic languages we're seeing fatigue.” There's all these security vulnerabilities in these things. There's all this dependent NPM install downloads, the whole internet on my local laptop. It's like, “Okay, this isn't fun anymore. What was fun 10 years ago is not fun anymore.” We're back to not being simple and fun anymore. More than that, I have this maze. This is the best image I could use to describe callback hell in my opinion.

Then, just as you're in the node event loop or whatever, and you're dealing with all of this, crazy, you can't figure out how your code is working. So because you have a state machine always to deal with, with all of these callback things, and it's not sequential like where you can just read your code and say, “Talk to Don, what's happening?” You have to go on these code paths.

How Should I Change My Code to Gain More Performance in Multicore Environments?

So that's what we're facing right now, people were facing. Then the other thing, people who were close to the hardware, like the C, C++folks always know more than you always, because they're close to the hardware. They're like, “You’re writing all this code in scripting languages but you're not using all the cores.” And that was the message that people were getting. “Hey, you're node.js is single-threaded and you're not using all the cores or global interpreter lock. How do you leverage that?” There was, of course, another framework, I think BM2 is what people use in the node world to scale on the different processes. But then again, framework. It's not in the language itself where you could use all of the processors.

So that was kind of the unease with that. And then now we are here and this is not my slide. I have attributed this to the person who created it. But I thought this was a really neat slide. We were running on hardware. Then we went to okay, easy two instances or whatever. Then we were like, “Hey, we just need something, even simpler, or get pushed Blah and my code runs.” And now we're like, “We just want to run something, and you all take care of all of the service, everything underneath. I just want my language to run. It doesn't matter what I'm running. If I ship you a minor, you should be able to run in on your server, somewhere.” And so serverless, it's not on.

I think that developers want this. They want even more simplicity. We're going to this function as a service serverless. I'm sure like a lot of people were in. Serverless it's this thing that people make fun of, but it's really about developer experience, because as an engineer, if I'm a product developer, in product development teams- they're called PD teams at PayPal - I just want to ship my code and I want to do a good job and I want the product to be good. So that's what's needed.

This is a code from Bala Natarajan. He heads all of bill, trust and release platforms at PayPal. It supports 4,000 developers and we have 2,500 microservices. It's kind of crazy. One code I heard from someone in the platform team at PayPal says like, if we sneeze PayPal shivers. So this really small core team supports lots and lots of developers at PayPal. There's a really great talk from our CTO from Google nest, where he talks about how PayPal operates at scale. So his thing is he's kind of like, “You know, I have seen so much in my life, Aarti. Developers keep shifting with line. Every generation comes and they want more simplicity, simplicity.” And he saw that with node.js. He's like, “We're definitely seeing another shift now where things just run somewhere and backends are running, front ends are running and we just need to make this work for developers.” That's the new paradigm. We need to simplify it to that. So I will end with that and I will take a quick water break.

Designers

It took me a while to get here, but I had to tell my journey, my story with Go. So the designers of Go, how the language was designed- it's something when I tell people, they're like, “Really?” They're like, “Yes, the person who wrote UNIX also wrote Go.” That's kind of a big deal. Somebody tweeted “Bell Lab refugees wrote Go”. I thought, I love that tweet. So yes, these people like performance. They like languages that are simple. Robin Grades, I was researching about him. It's like, “Oh my God, he wrote everything”. He was in the JVM, he wrote the JavaScript V8 engine, also wrote the chubby locks over, the cluster thing that makes Google work, all of the Google clusters work, in borger whatever. He wrote that too. I was like, "Oh my God." Then the face of the Go programming languages is Rob Pike. He's like the brainchild. He was also on the original Unix team and a lot of the Go ideas come from Plan9, some of them. He also rode UTF-8. It's not UTF-16 like JavaScript and windows and all of that. So it's in UTF-8.

Those are the designers. So it comes from that place. It comes from people who cared about performance, simplicity and wanted things to run. I was on Rob Pike's blog and I've read this blog like five, six times. I recommend you all read it too. The trigger for him for designing Go was, they were combining all of this C++ code in Google. And then he went to some meeting about C++, what they're doing to improve. The discussion was, “Hey, we're going to add these many features in C++.” He's like, "Really? Do you not really care about developers at all?" So again, people that are asking me about Go, I was like, developer happiness. That's what this talk is about. Developer happiness. So it matters all the way. People are unhappy and then go and build things in the languages they want.

I love to read like commentary on where ideas came from and I think that matters, because Go may not be the final destination. Who knows? I'm excited about Russ too and I'm excited about all this other stuff. But you want to know where ideas came from. To me it was really interesting, like, “Hey, we took C and we want to fix all this stuff.” But we were making it and it turned out to be something else. Then what they really wanted to do- because they were mostly programming in Python and C++. So that's what Go kind of looks like.

Simple

So it's simple. Go is a really simple language to start with. It has 25 keywords, low cognitive overload loop for everything. You don't have seven different ways to do something. I remember submitting poll requests for Ruby programs and I would get 10 different comments. “Oh, you can concise it like this and you could put it in one line and you could tweak this.” And there's nine different ways to do something. I'm spending most of the time making my code look pretty, versus understanding how my code actually runs, where it's supposed to run. So I think that that changed. I could spend all my life making pretty code, but if I don't understand how it's operating, or that becomes more important if I want to scale my applications.

My punch line here was it feels like Ruby runs like Steve, but then I wrote, feels like scripting language. So I was a former Ruby programmer. I still have a complicated relationship with Ruby. I love Ruby. So readability was paramount to them. Then simple code is debuggable. You can go in the goal line code right now on GitHub and start reading a top down. It's just fun. Hey, I can go and read the HTTP library. I don't need no framework for it. I can go and read how Go channels are made. Even that code you can go and read, “Okay, this is H times track.” “Oh, that's how it works,” so you can actually go and read the code and it's readable. It's top down, you can figure it out. So I love that part. It makes it very accessible for me.

And it can scale on large code bases where you have by large code bases. I'm an engine manager now, I work at an enterprise company. I have 10 developers on my team and then I'll have a couple of interns. I have a couple of RCGs. Rohart is nodding his head, and there'll be maybe a few senior developers, there will be one architect. You're not in the startup world where everybody's a senior developer You're an enterprise company. So somebody coming into your code base needs to be able to read it. It's a very different need than working at a startup where everybody's a senior engineer and has built systems.

Stable

The other thing that enterprises need is stability. Stability of a language. I think this was really one of the big successes of Java, was it was always backward compatible. Every release they came out with, it was backward compatible. They had the deprecated flag that, “Okay, don't use this, but if you use it, it's still going to run. We're going to make sure your code runs.” And that really mattered. I think that's still the big success of Java, and the Go community is paying attention. So Go2 is in the works right now. One of the talks that I attended from Ian Wallace, who's on the Go2 team was like, “We're looking at that, we're looking at the success of C with not that many changes, and the success of Java with not that many changes, and we want stability.” I think that was one of their things too, where they don't add many changes in the language pack. So the focus for the Go team was, “Let's make compiler performance. Let's make runtime faster.” Performance, performance, performance; not waste time on language features.

Who Is Using Go?

A little bit about who's using Go. I think this slide is important because people may know, may not know, that all of these things are written in Go. Docker is written in Go, Kubernetes is written in Go, etcd, [inaudible 00:22:30]. IPFS is an interesting project that I discovered, and it's a good one. Hopefully one day I can contribute to something. It's a fun project and it's written in Go. All of Hashicorp stack is written in Go. Prometheus, OpenCensus, influx DB and so many other ones. Cockroach DB, Victus. Sogou is presenting here somewhere. It's all written In Go.

Also these companies are writing in Go. PayPal has a bit of Go in the infrastructure side right now, mostly. But we have Go, we're talking about Go. I have seen job postings from big companies looking to build Go framework teams very recently in the Bay Area. So I can't name names, but they have also approached me, but I'm not going anywhere. But yes, Go is picking up everywhere. There are going to be go framework teams. There are going to be enterprise companies saying like, “Hey, we're going to write microservices in Go.” So this isn't just about infrastructure. I think it's going to be more, that's my thing.

Design

The design of Go, it's natively compiled, statically typed, open source. I'll say all these things- it's on the slide, but I'll say it again. It's important because I had an interview and someone says, "Oh no, Go, is it really natively combined? There has to be a virtual machine somewhere." They just couldn't believe that it was natively compiled. This was an interview and it was a senior director asking me this question. It was pretty interesting. It has concurrency primitives built in. That's one of the things that people love the most about Go. They'll come, "Oh I came to learn Go because I want to learn about Go's concurrency model." So yes, that's one of the things I talk about, in the next slides.

It's a C-like language. I think I had a lot more slides with code, but the feedback I got from my mentor was don't put code on slides so I removed them. But if you, later on, want to meet me in the hallway entrance, I can share some code. But it's very simple. It reads like C. I mentioned about natively compiled. So this is a question; I think it's an important question. At least this is how I learned, is through FAQs and not by reading. So Go has a really nice language specification. If you are one of those learners who learns from reading the whole specification packets in our forum and all of that, it's there, go read it. I struggled, it was not easy for me, so I jumped around. Why is it so big? It’s because Go binaries include the Go runtime. It's all packaged together. You've got everything in one single binary that's running your Go code.

Compiler

The compiler, it's fast. It's really fast. Early, it was written in C. They ported it to Go, it's still fast. It's not as fast as the C one, but they admit it, but it's still fast. They're focused more on the runtime than the compiler for performance. There's dependency cache and you can do Go Bill Myers, and you can cash your dependencies, statically linked to a single binary. So, for example, if you're linking C libraries, for example, if you're using Kafka and you have Liberty Kafka, you can link it with your Go binary and ship a single binary if you're using the Kafka driver. I did that in a previous project and you can do that. You can dynamically link too, but you can statically link the binary. There are provisions to do that. I put this l slide for cross-compilation there because I feel like people really need to see that it does do all of this cross compilation across all these platforms and oasis.

So that's one of the things, and there's also support for assembly. So you can ride hand-coded assembly, and there's a lot of poll requests that come from academia for the math libraries. If you're watching the Go line GitHub, you'll see that on the math libraries for sign costs down and all of those, a lot of that is in assembly and people are constantly tweaking, people- their domain, is constantly making it better, which is great, right, because we get a better language.

Data Oriented Design

Go is not object-oriented. It's data-oriented. By data-oriented it has struts and it has methods that are outside of struts. They are not related; there is no class keyword in Go. There is no extends keyword in Go. So class extends- we don't have that. We just have struts, like C, and we have methods that are outside of struts. So stayed in behavior is separate because it's based on the data, the strut. Struts do a lot of other stuff too, like Go behind the scene does alignment and all of this stuff to make it compact, very much because they are coming from the C world. I don't talk about it here because there's so much to cover.

So Go uses interfaces to implement polymorphism. Again, like I mentioned, with methods you can implement multiple interfaces. It also prefers composition over inheritance, because we don't do the inheritance tree. Encapsulation is done with three things. You've got the packages. Packages are not like Java namespaces, they're more like libraries. They're completely encapsulated. If you start thinking of them as Java namespaces, it's trouble. If you think of them as libraries, like, “Hey, this needs to live independently off everything else,” then it works. It follows a very simple upper case convention for things that are exposed out of that package and things that are lower case or not. So it's a very simple convention.

There's also this concept of internal, which you don't want it exposed at all, which is sort of protected I think. I don't know which paradigm, but yes, so you wouldn't be able to ask us those portions of a library that you're using. You can embed struts inside Strut. So type reuse is through embedding struts inside struts.

Language Design (continued)

So language design. This is interesting because maybe you took a C-class in college and you have mostly written in Java or mostly written in languages that didn't have pointers, you come to Go on, you're like, "Oh, Go has pointers." It has pointer semantics. These are not your seed pointer arithmetic thing. So don't confuse the two. Pointer semantics is the same thing as Java references. Java is all pointer semantics. Everything is a pointer semantic in Java. Java doesn't have value semantics, and that's something that is a concept that I feel people should tell up front somewhere- maybe I’ll write a blog about it because it was a source of confusion for me too. I'm like, "Oh my God, these stars are scaring me. Pointers," because I haven't used pointers in awhile. It doesn't like that.

Value semantics is really nothing. But if people who came from C++ know this, it's just about copying something instead of using it as a reference. So that's value semantics. Java doesn't have value semantics, but there's a GSR open for the next release of Java to have value semantics. Which is the next one, Java 11 or Java 12? Yes, that's going to have that has a GSR open for adding value semantics. So look at pointer semantics as nothing but references, just like you are in your ordinary code. Use those more than where you need to pass references.

You can do low level stuff with pointers, I played a little bit with it. You can import the unsafe and access things inside that Strut with casting with unsafe. But don't do that unless you have to. So one place where I've seen it is in Go's binary serialization package, GAB. It's called GAB, which is Go's thing for like doing service to service. If you don't want to use GRPC, if you're writing everything in Go, you can use the GAB library, because to make it really efficient, Rob Pike had written it and he was using unsafe that to do all of the manipulation and make it fast. So that's there.

cgo is an option. I have used cgo for image processing in a previous company. That's the only place I needed to use it because there are some things, you’re going to write all of it in Go? For example, like FFmpeg. Who wants to write it in Go? That's a hard library to port to Go. So you end up using cgo for those kinds of things, those libraries that provide those values. The other thing about Go, and I think it was in the previous talk mentioned too, about zero value. Go does that too. When you say new or make or you know any of these things, you're not instantiating a class in Java. All you're doing is you're allocating memory for this variable and you're zeroing out that memory.

So zero value is that you're doing that because this whole zero value concept is interesting. I didn't come from the C word, but the C people are really excited about it. I'm like, "Why are you always talking about is zero value?" I asked Bill. And Bill's like, “Because C had this problem where it would allocate memory but it would not zero it.” So you could do bad things. You could access things inside and mess things up. So Go takes care of that for you. There's a slight performance hit. You would never do this in C, because you're writing firmware in C. You wouldn't want to do anything with performance. But Go cares about data integrity first. So that matters. So things have to be accurate, consistent, efficient. That's more important.

Testing

I'll take a quick break again, sorry. So Go has testing built in. In the toolchain you've got Go test, you've got the benchmarking tests and I had a bunch of code associated with that. If anybody wants to look, I can talk about table-driven tasks and how Go does unit tests. There's also how you can wrap a benchmark test, and test race conditions. I mentioned everything was a reference. So yes, you will run into race conditions. Go has a race detector in the testing toolchain built in, which you can run to detect these kinds of errors. There are also options for coverage, memory profiling, and other things. So it's pretty good. To be honest, I still find it lacking straight up. I think we need a Go testing cookbook. Maybe someone will write a Go testing cookbook that'll tell us how to do tests well. I still love the Java style of doing tests and their ways, so in a very systematic way. Ruby too had great testing frameworks. So I think this is an area where we could do more open source and contribute Go testing frameworks.

Concurrency

Concurrency. There are some really great talks about concurrency in Go. I saw all of them and I still didn't understand concurrency in Go. And I finally get it, so it isn't about running on all of these processors. It's about multiple things. Concurrency is about out of order execution. If I go to a coffee shop and I ask for coffee and I pay the money, but there's someone behind me and there are things that can happen in parallel inside the coffee shop. The things that can happen out of order; I can pay first or somebody's doing something first. It isn't about using all of the machines in the coffee shop for example. You can do certain things out of order, and actually you all should watch the talk- Samir Ajmani has a great talk on this, about concurrency, and he has this coffee example that really explains how concurrency works with channels and goroutines in Go. But it's really about out of order execution.

Go gives you goroutines. They are lightweight userspace threads. Then Go has a cooperative scheduler that's in the Go runtime, that's managing these goroutines for you. The scheduler is deciding which goroutine is going to be run, which goroutine is blocking or whatever, and which goroutine needs the Cisco right now, so I need to go to the OS level. It's managing all of that so you don't have to do that. So it's like a mix. It hits the sweet spot. So node.js had the event loop and was managing all [inaudible 00:36:44] io and working around this, I’m mumbling right now, but it wasn't going to the OS level threads. But Go is doing all of that with this really amazing scheduler.

A lot has been written about the scheduler. There are some great talks. My favorite talk is by Kavya Joshi at Go for con. It's called the scheduler saga. You must watch it. She's amazing. She's my hero. So yes, you must watch that talk, the scheduler saga. It explains how Go handles all of these. There's a lot of literature on it too. A lot of great blog posts.

Channels

Where was I? Yes, this slide. I talked about goroutines. So you've got your threads. I talked about concurrencies, about out of order execution. So now how do I make sure what thing happens when? I need to signal. There are four things happening. There's out of order execution happening, this thing happened, this thing happened, but I need to signal these and bring it all together. So the channels provide the mechanisms that allow the goroutines to communicate. And that comes from this old paper written by Tony H-O-A-R-E- you all can pronounce it in your heads- from 1978. Communicating sequential processes. It's a great paper. That's one of the talks that Go for con was also about, implementing the paper in the original language, which was done by Adrian Crockford. That's also a great talk if you like the academic side of things. That's a great talk to watch.

Channels are signaling semantics. I'm trying to signal what happens first. I'm orchestrating what's happening. This is one of the patterns, and I've just picked one good example where I have a goroutine. In this example, I'm a manager and I'm hiring a new employee, and I want my employee to perform a task immediately when they're hired. Then you need to wait for the result of their work. And so you need to wait because you need some paper from them before you continue. That's what this orchestration is about, and this is the semantics here. So you make a channel, you run a goroutine, and then you're waiting for something to land before you can exit this function.

Tooling

I'll talk a little bit about go toolchain. A lot of people talk about toolchain and Go. It's really, really well written because there's a lot of good tooling built, in especially the Go format, gofmt or whatever. You don't have to talk about tabs and spaces ever, ever again. There's just one way to do formatting of all of your code, and you just do it to Go way, it's in the toolchain, it's there. There's Go LinkedIn, there's Go where, there are other things that the toolchain provides. But it also provides really powerful tools for profiling, memory and CPU and blocking. There are really some really great workshops. We had a workshop for women a couple of weeks ago where we did a Go tooling workshop, where Francesc went through and we worked through all of these examples and wrote code on the Go toolchain.

And then tracing: Go tool trace really helps you when you want to see when garbage collection is happening, how many goroutines are running, the GC pause or whatever, if you're really into all of that. I wasn't into that when I was doing Java, but if you're into that now you can, and now I'm into everything. But it's kind of fun that you can do this very easily and it's built in. You don't have to download a special framework or a library. It's part of Go.

Error Handling

Error handling. Go does not have exceptions. There is no exception hierarchy. If you are like me and have written all this code path, with tons and tons of exceptions, it's like, “Oh my gosh, that's my main program. This is my exception program.” I used to write down like that. You had to, because that was the one way. You had checked exceptions. And I think that Java improved exceptions from C++ and it made them better. But it wasn't like now where we're taking it to the next level. I think with Go, errors are just values. You can do whatever you want with them. You have state and behavior.

Data structures - I'm going to go really, really fast now. Go has arrays, maps and slices, and if anything you should read about slices. Slices is the best thing ever. It just makes Go super fast. It's contiguous chunks of memory. It's not your dynamic array, it's not your array list. I was confused forever. Think of slices as its own thing, and read up on it. Just leave the old paradigms when you start reading up on this. Go has this built in thing for if you want to do a pence and length and all of that. It's in the library. It also has a rich standard library. All of the stuff is there. And you can read on it. I'm going to go really fast.

API development. This is at the heart of everything. I have written swagger and lots of Go swagger stuff. I have written REST stuff, web frameworks are there. GRPC. This is a quick example of chaining middleware and I put this in there because this is something that comes up that you have to do. I'm going to go much faster. This is a really important slide. So seven minutes. You should read up about the Go network polar. It's really, really amazing. This is why Go's network library is amazing. That's why Cisco wants to use it and all these networking companies want to use it. It just does these amazing things. There are great blog posts on it. Underneath it just abstracts all the different operating systems. The community- we have Gopher slack, Golang mailing lists, Global conferences, WomenWhoGo.

The Future of Go

The future of Go. There's stuff happening with Go 2. Generics is something that people miss, improved error handling, dependency management is something that the Go team is working on. And my last slide is for people who are writing Go frameworks. This is my pitch: please, please, please build for developer happiness. Don't build top-down frameworks that make your developers unhappy. Build tooling that helps give developer autonomy.

These are the learning resources for Go that I use. My last slide is why I like Go. I feel like I'm a programmer again. I was writing business logic forever. I've lived in API land, and I feel like I can finally see what's happening. I'm attached to what's happening with systems and I'm very excited about learning more and doing more. There's a great blog post that I would recommend, that's called Go has Heralded the future for Rustin other systems languages. It's an amazing post. Go has all these problems. It's an easy-to-read blog post where there are pros and cons. But yes, this is where we're going. This is what's happening with the changes and things that are coming with Docker and containers and at Go. So thank you all for listening.

Questions & Answers

Participant 1: If Go does not have interfaces, what do you create that implements interfaces?

Parikh: Go has interfaces.

Participant 1: Yes, Go has interfaces. But I just think an interface is something that a class kind of uses, right?

Parikh: Yes. No. You have interfaces and then you have methods. When it's implicit, if you implement those methods that the interface wants, then you have your implementation. So I'll tell you what ...

Participant 1: Where are those methods? Because that to me is a class.

Parikh: It's not a class. It's methods on the struts. I'll show you. I'll show you after. I can show you some code.

Moderator: We have something similar in Rust. So I know this and it is complicated to figure it out.

Parikh: It is. It's way hard. I was like, “Oh my God, where are my classes. I was the same way.

Participant 2: A question about since the stock was at an enterprise applications, I just want to know what does Go support for working with databases?

Parikh: Yes. There is a database in the standard library, but there are also these abstractions that people have built on top of that, that you can sequel acts and all of that that you could use to streamline. You could use ORMs if you want. In one project I used ORMs and then the other project was a gaming company, high performance. And the CTO made us write all sequel by hand, which is a good thing. But yes, you could do both.

Participant 3: I was just wondering if it is a good prototyping language. I have a lot of systems engineers that just come up with some quick ideas.

Parikh: CLI is fun stuff. I want to teach my daughter Go this summer, because I want her to learn. She's learned all this Java, but prototyping is perfect for that so you can see what's happening.