ATO 2014 - So You Think You Know 'Go'? The Go Programming Language

Editor's Notes

• #2: What this presentation is about: Overview of language features, some personal perspective as a newcomer, current perspective NOT a talk on programming language theory NOT an advanced talk For people looking to learn about Go, answer “should I use this language for my next project?”
• #5: Me: “Looks kinda like a somewhat crippled C#/Modern C. Clean syntax, and gothreads/channels are nice. Now what’s the syntax to declare an abstract class…?” Founders: Tried to create a simple language (get rid of the “kruft” in C++, that is well prepared for modern runtime environments (concurrency, networking, etc.) Procedural language (mostly), somewhat based on C/C++ Garbage collected Statically typed Compiles to native code Concurrency built-in at the lowest level
• #6: “So I’ve heard a lot about how great Go is, tell me about all of the awesome features it has!”
• #7: Well…. Go is actually a pretty simple language! Simple, purpose built to address programmer productivity issues experienced by Google in C++ projects Long builds, crazy dependencies (include hell) Programming language not adapted to take advantage of modern hardware (concurrency) Poor integrated tools to support the language Common errors in development (memory leaks, etc)
• #8: When you download Go, you get way more than just the compiler/std libs: Go fmt - format code Go Get - fetch remote dependencies Go Test - integrated unit/benchmark testing Go Vet - check for common errors in code Go Doc - Generate code documentation from comments Go Fix - Help upgrade to new releases of Go (when syntax changes break builds - not much of an issue post v1.0) go tool pprof - help profile your Go Application 3rd Party: goimports - remove unused imports automatically (I have my IDE configure to do this on save) golint - another syntax checker, looks for code improvements jd - locked dependency manager (made by VividCortex)
• #9: Go Creators have joked that Go was developed between C++ builds at Google. Not entirely untrue Large C++ codebase, build can take over an hour Even large Go projects can compile in seconds Reason is dependency management system (doesn’t lead to recompiling dependencies over and over) Also much simpler language structure (syntax, paired down feature-set) “ Build time matters more than anything else” - Rob Pike
• #10: Memory Management is hard. C/C++, mem management left to programmer, bugs ensue Immediate design decision in Go - garbage collector
• #11: Similar to C - if you declare an int you get and int (no worrying that your variable type is inferred correctly at runtime) Go also has type inference, but only at declaration Once you create it, you have to explicitly change a variable’s type
• #12: Go has support for Objects - but we call them structs Objects can have methods just like classes in most OO languages can In fact, any type you create can have methods! i.e. type Name string can have method func (name Name) Introduce(){} Go has interfaces, but they do not have members, only functions Go does not have the traditional inheritance models in C++/Java We use “Strong Ducktyping” Any struct can “inherit” from an interface if it has the methods defined Standard lib structs can inherit your Interfaces!
• #13: No talk about Go is complete without talking about Concurrency! Channels - send data between threads easily, asynchronously or synchronously GoRoutines - spin up another thread, just like that! Concurrency is a fundamental component of the language
• #14: Here’s a list (not all inclusive of course): Implicit numeric conversion (int != int32) ‘Implements’ keyword (interface inheritance is implicit) No ‘classes’ (declare structs/methods wherever, any data type can have methods) No constructor/destructors Function overloading (methods match by name, not signature) Pointer arithmetic (unsafe.Pointer exists though) Exceptions and try/catch (although we have panic/recover - for extreme cases) Generics
• #15: Simple, productive language for modern hardware Fast Compilation Good tool support included Easy to pick up and understand Can hold the spec in your head No cruft/legacy support Start from scratch, don’t try to “fix” C++
• #17: The real world has concurrency - so here’s a “Hello World” that showcases Go’s concurrency model Create a concurrent thread just by prefixing a function with ‘go’ Synchronize your threads with a blocking channel No Imports to access concurrency - they are built right into the language.
• #18: And there’s our output (Pirate Slang!)
• #19: To be fair, “Hello World” isn’t really a “real world” scenario. Let’s make a simple web-server, that’s a little better!
• #20: Do a live demo on your local machine, or just go over the code in the Playground (don’t hit run in the playground!)
• #21: A static website server that looks in a single location and responds to requests with the file there. 1 line.
• #22: Unlimited concurrency can be dangerous (DDOS?) Let’s see a server that limits the number of concurrent connections This code uses channels to do just that
• #23: Go has a couple of things that can be quite annoying at times
• #24: Here’s a program, what will it’s output be? Why doesn’t it think there is a bomb? thereIsABomb was actually declared twice! once outside the for-loop and once inside. We change the value of the one that then loses scope, so thereIsABomb is always checked as false. This is a tricky problem that occurs due to Go’s flexible variable declaration syntax Even the creators have said they dislike it as it is Can it be fixed? Maybe make go vet warn?
• #25: So what else is interesting, problematic and/or weird about Go?
• #26: Go doesn’t have generics One of the most criticized points Considered the biggest feature-screwups (why didn’t they include it!?) by a lot of people Most asked-for feature (to my knowledge) Initially I thought this was a pretty big drawback A Couple Things: I haven’t needed Generics since I switched to Go In fact, I didn’t really use them a lot anyways when I had them Did I ever really “need” them? I’m not so sure Generics are complicated Significant increase in language complexity to add them in all liklihood Compile times will increase The Go Developers are not blatantly against them Have said they would add if a good solution or blatant problem was brought forward So far none has AFAIK Go Mentality: Smallest possible featureset we can be productive with It’s okay if we have to copy some code as a result Productivity is higher priority than hyper-elegant code
• #27: Builtin Types - complex64 and complex128 Builtin functions - real() and imag() to get the components math/cmplx package to manipulate them
• #28: When you declare a variable, that’s it. Want to treat it as something else? Cast it. int and int32 are different, have to cast to add them (note constants can be added to any numeric type - they are typeless) I thought this sucked when I started using Go “What do you mean I can’t just add this byte to an int!? Are you kidding me?” Luckily, I could usually just change the types interacting and the code got cleaner Why would they do this though? It makes every expression explicit (i.e. “I am specifically choosing to mix these types, as I believe it is okay) Reduces the chance of accidental scope issues (overflow, ect.) Absolutely no ambiguity as to how types interact together (is it safe to mix these?) Annoying? Sure, but not a deal breaker
• #29: go fmt - it formats your code, the Go way only If you are the guy on the left (like I was), this will make your brain itch Won’t even compile when you have bracket on its own line “So why can’t I use my own style?” Simplicity (a minor case, I know) Universally formatted code, no matter where you go Lends to readability Google has “solved” the style debate in Go (we have more important things to do as engineers)
• #30: I agree that unused vars/imports should be errors, but picture if you will: Hacking on a feature, want to print a value as a sanity check go add “fmt” to imports declare the var, add a print statement It works! Let’s move on: Delete print statement, add some more code Build fails - unused import remove import Build fails - unused variable delete var What was I doing again??? GoImports helps, but requires a mindset change (quick hacks no longer quick, I guess) This still trips me up, but less as time goes on
• #31: Go supports concurrency very easily, but race conditions are still a problem builtin “sync” package has mutexes As always, be careful when sharing data across threads!
• #32: Why does a language whose creators specifically wanted simplicity and eliminate errors include the ‘goto’ statement? Let’s all agree - the next popular language will not have ‘goto’ - this madness must end.
• #33: Here’s something fun: Easter Eggs! These keywords really exist - you can use them anywhere in a Go Program (the compiler simply ignores them all) go fmt will not understand them though