I use Go quite a bit, and like a lot of things about it. Static compilation (deploy a binary), good ecosystem, tooling, and docs. There are some things I am not a big fan of too – no generics, lots of code duplication, vendoring, code generation. So far the utility has outweighed the pain.
However, due to my “discomfort” with a few aspects of Go, I find myself looking into other new languages with a bit more regularity than I used to.
The thing that I find so frustrating about all of this:
I know a language. Has great tooling, builds statically, has a great ecosystem, and solid docs. It runs well on Linux and Windows, has an optional GC (used pervasively throughout the standard library), and has a better-than-goroutines async story. Also like Go, it supports both value and reference types, and can trivially interpolate with C due to having a deliberately similar story with primitives. But unlike Go, it has generics, versioning resolution, and both a good AOT compiler and a good JIT. And its license protects it from patent lawsuits to boot.
I’m talking about .NET and C# with Mono.
Or, if you don’t like that suggestion, you could look at several of the MLs (assuming you don’t need Windows support), D (if you do), or, if you drop the goroutine part of the equation and aren’t wedded to static typing, quite a few schemes, including Chicken Scheme in particular.
The thing that frustrates me so much about Go is that it provides nothing new except Google’s backing.
Talking about Go specifically, I think its popularity has to do largely with timing, the founders, and stability:
Timing: Don’t forget that when Go came out, things looked differently than they do today. .NET was still pretty much windows only, and mono was … usable I guess? For many it was still clouded in uncertainty for sure. I also know some people who simply refuse to even look at any MS tech on principle, based on their own experiences and personal history. Rust was super alpha and changing constantly, Elixir wasn’t a thing yet, Nim was Nimrod, etc.
Founders: Go had some pretty recognizable names as original designers – Ken Thompson, Rob Pike, Robert Griesemer. I think that alone attracted some early folks, and helped it reach an early “critical mass”.
Stability: Once they released Go 1, they consistently stated that Go 1 was “done” and there was a clear backwards compatibility guarantee with 1.x releases. This stability has really helped grow the ecosystem.
I also think that go fmt has been a great boon to the community. While people may not like tabs (I don’t!), having a standardization formatting tool really makes other people’s code more readable and approachable. It removes a large amount of wasted energy on people even thinking (or arguing) about different styles of formatting.
I have also written lots of python, often as part of large 2.7 codebases. The whole python3 thing has been rather unpleasant. It requires enough work that you have to go through all of your code to fix things (web apps, so LOTS of string handling), and is painful as a library to support both at the same time (mostly using sixx). If you are having to quasi-rewrite of an app (that isn’t enormous – if it was you probably wouldn’t be going to python3 either!), why not go all the way and rewrite your app in something better? I think Go is seeing lots of people moving over from python and ruby. Again due to timing, and Go being both faster, and easier to deploy (just a binary).
Personally, I am looking at Rust and Elixir as the next languages to play around with. Ocaml looks fun, but easy to use concurrency is important to me, and Ocaml does not seem to have a great story there.
That’s fair. I think that the main reason, though, is one you buried under timing:
I also know some people who simply refuse to even look at any MS tech on principle, based on their own experiences and personal history.
This is, in my opinion, why Go could succeed where Mono failed. Your other points are valid, but the refusal to even touch a Microsoft technology for fear of patent lawsuits and whatnot meant that there wasn’t even ever really a competition to begin with.
We’re comparing Mono of 2009 to Go of 2009. In that context, I think Mono ran pretty well. Go’s GC at the time was so slow that Python code could sometimes outperform it, and, like Mono pre-SGen, was conservative non-compacting, so they were at least comparable in the runtime department, but Mono would’ve had a better runtime, better cross-platform support, and better tooling.
Mono had quite the headstart at that time, but if you want to talk performance, that’s also the era in which mono had an O(n^2) string builder and a garbage collector with a minimum 100ms latency per collection on Mac because boehmgc used the wrong mutex by default.
What soured me on mono more than the buggy experience was that all their attention seemed focused on building MonoDevelop and MonoTouch and so forth. Go, from the beginning, has had an entirely different attitude of making it work first, then adding cool things later. Like instead of trying to build an entire IDE in Go, they said “here’s a go.vim file” and that was it. I have to admit that I’ve not pushed Go as hard, but I’ve never experienced bugs like “setting timezone to Arizona aborts process” either.
I do like C# more than Go, btw, and I’m hoping the open sourcing really kickstarts things again, but mono still hasn’t climbed out of the “do not touch” pit of despair.
That’s fair; you were knee-deep in it when I was just watching, and I know your initial comment was poking fun at me because I’ve been noisy about how going with Mono in 2008 was a bad decision. I guess I just did get bit by Go when it first came out with things like leaking memory and odd performance characteristics, and that happened about the same time that Mono started to clean up its act, so I was biased. It seemed like I was giving up a ton of language features for (at the time) no real benefit. (Since then, the situation has obviously changed on both sides. If anything, the reason I’m interested in .NET again is that the availability of CoreCLR on non-Windows platforms means I can ignore Mono.)
I also think I need to mention that my go-to “systems” languages at the time were FreePascal and Chicken Scheme, so I may just make weird decisions in this department.
I use Go quite a bit, and like a lot of things about it. Static compilation (deploy a binary), good ecosystem, tooling, and docs. There are some things I am not a big fan of too – no generics, lots of code duplication, vendoring, code generation. So far the utility has outweighed the pain.
However, due to my “discomfort” with a few aspects of Go, I find myself looking into other new languages with a bit more regularity than I used to.
The thing that I find so frustrating about all of this:
I know a language. Has great tooling, builds statically, has a great ecosystem, and solid docs. It runs well on Linux and Windows, has an optional GC (used pervasively throughout the standard library), and has a better-than-goroutines async story. Also like Go, it supports both value and reference types, and can trivially interpolate with C due to having a deliberately similar story with primitives. But unlike Go, it has generics, versioning resolution, and both a good AOT compiler and a good JIT. And its license protects it from patent lawsuits to boot.
I’m talking about .NET and C# with Mono.
Or, if you don’t like that suggestion, you could look at several of the MLs (assuming you don’t need Windows support), D (if you do), or, if you drop the goroutine part of the equation and aren’t wedded to static typing, quite a few schemes, including Chicken Scheme in particular.
The thing that frustrates me so much about Go is that it provides nothing new except Google’s backing.
Talking about Go specifically, I think its popularity has to do largely with timing, the founders, and stability:
go fmthas been a great boon to the community. While people may not like tabs (I don’t!), having a standardization formatting tool really makes other people’s code more readable and approachable. It removes a large amount of wasted energy on people even thinking (or arguing) about different styles of formatting.I have also written lots of python, often as part of large 2.7 codebases. The whole python3 thing has been rather unpleasant. It requires enough work that you have to go through all of your code to fix things (web apps, so LOTS of string handling), and is painful as a library to support both at the same time (mostly using sixx). If you are having to quasi-rewrite of an app (that isn’t enormous – if it was you probably wouldn’t be going to python3 either!), why not go all the way and rewrite your app in something better? I think Go is seeing lots of people moving over from python and ruby. Again due to timing, and Go being both faster, and easier to deploy (just a binary).
Personally, I am looking at Rust and Elixir as the next languages to play around with. Ocaml looks fun, but easy to use concurrency is important to me, and Ocaml does not seem to have a great story there.
That’s fair. I think that the main reason, though, is one you buried under timing:
This is, in my opinion, why Go could succeed where Mono failed. Your other points are valid, but the refusal to even touch a Microsoft technology for fear of patent lawsuits and whatnot meant that there wasn’t even ever really a competition to begin with.
Surprised to see you saying mono runs well. :)
We’re comparing Mono of 2009 to Go of 2009. In that context, I think Mono ran pretty well. Go’s GC at the time was so slow that Python code could sometimes outperform it, and, like Mono pre-SGen, was conservative non-compacting, so they were at least comparable in the runtime department, but Mono would’ve had a better runtime, better cross-platform support, and better tooling.
Mono had quite the headstart at that time, but if you want to talk performance, that’s also the era in which mono had an O(n^2) string builder and a garbage collector with a minimum 100ms latency per collection on Mac because boehmgc used the wrong mutex by default.
What soured me on mono more than the buggy experience was that all their attention seemed focused on building MonoDevelop and MonoTouch and so forth. Go, from the beginning, has had an entirely different attitude of making it work first, then adding cool things later. Like instead of trying to build an entire IDE in Go, they said “here’s a go.vim file” and that was it. I have to admit that I’ve not pushed Go as hard, but I’ve never experienced bugs like “setting timezone to Arizona aborts process” either.
I do like C# more than Go, btw, and I’m hoping the open sourcing really kickstarts things again, but mono still hasn’t climbed out of the “do not touch” pit of despair.
That’s fair; you were knee-deep in it when I was just watching, and I know your initial comment was poking fun at me because I’ve been noisy about how going with Mono in 2008 was a bad decision. I guess I just did get bit by Go when it first came out with things like leaking memory and odd performance characteristics, and that happened about the same time that Mono started to clean up its act, so I was biased. It seemed like I was giving up a ton of language features for (at the time) no real benefit. (Since then, the situation has obviously changed on both sides. If anything, the reason I’m interested in .NET again is that the availability of CoreCLR on non-Windows platforms means I can ignore Mono.)
I also think I need to mention that my go-to “systems” languages at the time were FreePascal and Chicken Scheme, so I may just make weird decisions in this department.