Not Bryan obviously, but here's a rundown of the highlights and lowlights of Go as I see them, paying attention to JVM languages (since I don't know that much a

Not Bryan obviously, but here's a rundown of the highlights and lowlights of Go as I see them, paying attention to JVM languages (since I don't know that much about C#). The Good: * Performance. Java and the JVM are certainly performant once things get going, but Go and other compiled languages are at peak performance out of the box. Go should generally be a bit faster or equal speed to Java and should use a fraction of the memory. Here's some microbenchmarks that look good for Go vs Java: https://benchmarksgame.alioth.debian.org/u64q/go.html https://benchmarksgame.alioth.debian.org/u64q/go.html * Concurrency. Go makes it simple to communicate and synchronize with other threads, and the co-routine model allows for expressiveness in async without running into callback hell. * First-class Functions. Some JVM languages have this, but even Java 8 doesn't have the ability to set a variable equal to a function definition. Coming from Node, Python, C, C++, etc. Making functions first class citizens helps a lot. * Interfaces. Go has auto-fulfilled interfaces that you opt-in to by writing the functions they require. The compiler figures out which types match an interface for you, instead of you specifying it. This is probably my favorite feature of Go. It feels like duck-typing with type-safety. * Unicode support. Go has excellent unicode support, which I don't think any JVM language has. Javascript also has great unicode support. This is probably a big one for someone doing a lot of web-based application deployments. * "Batteries included". Go's standard library is amazing. All the basics you'd expect like string manipulation and math functions are there. They also have a dead-simple http server/client that supports http2 and SSL. Full crypto libraries with key-management. Encoding/Decoding for csv, json, and xml built into the standard library, even compression formats. The standard library feels really good to use compared to C++ and Java for me. C# I believe is on-par with Go as far as built-in libraries go. * Compiled and statically linked. Go only does static linking for Go code, and does interoperate with C (but it's awkward). This means you compile the Go program and then run it, the runtime is in the binary. There's no worrying about versions of your JVM and ensuring that class paths are set up correctly. A single binary executable is all you need and what you get out. * The tool chain. Go comes built in with documentation generation (really nice stuff, everything on golang.org/pkg is automatically generated from the source and comments), testing facilities (including coverage tools and benchmarking), and dependency gathering (like pip without the versioning). The dependency gathering uses VCS, so you can point it at any mercurial, svn, or git repo and Go will go download and put it in the right spot for you. The compiler can do cross-platform compilation from your local machine (on windows machine, compile for linux) with some playing with the settings. There's a race detector, code formatter, and version upgrade tool in there too. The Divisive: * Error handling. A lot of people I've seen using Java/C# like exceptions for error handling. Go doesn't use exceptions except in exceptional circumstances (and no try catch when that happens). Go instead recommends you use secondary return values (since you can return multiple values) for your errors. This leads to a lot of code that says `if (err != nil) { return nil, err }`. I find that in my first pass, that line is everywhere, but when I start building toward production of the system, I'm responding to the errors fairly deep in the call stack and the number of default error lines drops dramatically. Your mileage will vary. The Bad: * No generics. This might be a deal-breaker for you, depending on how you like to program. Go has first class support for a simple hash map (generic) and dynamic arrays (with slicing semantics similar to python) (generic). Every other generic collection type you might want will be made yourself, made by code generation with a third party module, or lacking any type safety through the use of `interface{}`. Generics are probably going to come at some point, but not yet. * Package version management. While Go makes it easy to get the latest version of a package, Go does not have a robust package version management system yet. Getting the specific version of a package your project needs is difficult and error prone at times. Third party tools are currently the best way to deal with versioning and freezing your dependencies. Hopefully the `dep` tool or something like it will become a first class part of the tool chain, but it's not there yet. * Debugging and IDE support. There's still not a lot of IDEs that support Go, but it looks like JetBrains may be fixing that soon with a dedicated IDE: https://www.jetbrains.com/go/ https://www.jetbrains.com/go/ * Lack of expressiveness. In Go, there is often only one way to do things. Go is specified in it's entirety in under 30k words. You can write a whole compiler based on that information. That means it's lacking a lot of nice syntax that's become popular: Option types, pattern matching operations, decorators, lambda expressions, etc.