Go is successful because it has many appealing features:
1. trivial cross-compilation
2. native multi-threading (eg no GIL or multi-process hacks) that is easy to take advantage of
3. fast. An order of magnitude faster than Python in many cases.
4. easy to deploy. Most often just a single binary
I like Go because once I compile it, I can ship that binary anywhere and it will run. I like Python for a great number of tasks and for prototyping, but I prefer Go when I need to run my code on another machine (or it needs to be fast).
To put it simply, with Go I ship a binary. With Python I have to ship my entire development environment.
Ya, and if you look at the language space, there's nothing else that offers #1.
That set of features isn't related to the language itself (though the language was designed to allow those features).
This is where Go is appealing, it's not the language itself, it's the properties it brings with it. Cross-compilation, multi-spec, reasonable performance and low memory footprint. Single binaries. And I'd add fast compilation times.
Honestly it needs more competition that offers those same properties, because I'd love to have more choice of language (syntax + semantics), but get the same properties. But for now, you have to use Golang if you want something that gives you all those properties and that's just where Golang differentiates itself.
That's a great point, and one I hadn't considered. One language feature that Go brings is first-class multi-threading and communication amongst and with child threads.
The only languages I know that can compete with Go with similar properties are Nim, Zig, and Rust. I'd like to include Delphi / Free-Pascal, but cross-compilation can be a bit of headache at times.
Well, when it comes to cross-platform desktop apps, Lazarus (Free Pascal) and Delphi (payware) do very well. There is nothing in Nim, Zig, Rust, or Go that I know of that can compare to the Lazarus or Delphi IDEs (for Object Pascal). As a matter of fact, there is an effort among Golang users to copy Lazarus. But, for Lazarus and Delphi, things get a bit shaky when we start talking about mobile or desktop and mobile development.
Delphi incorporates a mobile solution that was bought for the purpose, called FireMonkey, that doesn't completely integrate with their desktop solution (VCL). Each new version of Delphi is making progress with integrating the different solutions more tightly, but we are still talking about payware that is priced above what most individuals would want or feel comfortable paying for.
Lazarus, for various odd reasons (or even suspicious reasons), their developers appear to be dragging their feet with making a mobile solution. They should be able to incorporate technologies such as OpenGL ES with LCL and their custom drawn interface, but don't. A 3rd party developer came up with their own solution, that works for Android only (LAMW), but doesn't integrate with the desktop solution (LCL) nor is a part of Lazarus. So for Lazarus, outside of desktop development, things get a bit confusing. However, if team Lazarus ever got their act together and took mobile development more seriously, they probably would have among the best solutions out there.
The two things I always bring up in interviews on why I like Go:
1) Easy to use pointers. There's just pointers, not like C where you can have anywhere from 4 to 8 different types depending on your platform. And no, pass by reference vs. value are not the same as pointers.
> 1) Easy to use pointers. There's just pointers, not like C where you can have anywhere from 4 to 8 different types depending on your platform. And no, pass by reference vs. value are not the same as pointers.
Null, void, wild, dangling in core C. DOS also had far, near. I believe one of the Windows Visual something platforms had extensions that added another three or four.
I'll bite. So null is just a special value one can assign to a pointer, marking it not used. In Go this is nil. Void means "absence of type" and is related to pointers only marginally - void* is a pointer to something we don't know a type of. In Go, I guess a pointer to interface{} would be the same? (Not quite, but close)
As for wild and dangling pointers (I would argue the are the same - pointers that show somewhere they shouldn't), fair point. Of course one would expect this from a language so many decades younger.
But none of these are pointer "types" (far and near arguably are - iirc they determine the size of a pointer - but these four are not). I hope the question on the interviews are posed differently, I for one wouldn't know what you mean.
> As for wild and dangling pointers (I would argue the are the same - pointers that show somewhere they shouldn't), fair point. Of course one would expect this from a language so many decades younger.
It’s not due to age, but due to having a GC and being a managed language. I really don’t get all the comparisons of Go to C, the former seems to want to sell itself as a modern C replacement but they are nowhere in the same niche (and that’s ok, there are very few places where a GC can’t work). They just operate by completely different semantics when it comes to pointers.
I love Golang but its pointers are awful. "Nil is not really Nil" has tripped >1M Go programmers. It's the "trillion dollar" mistake.
People make fun out of C++ all the time. Yet, Go has some extraordinary Gotchas of its own. You need to read "The Go Bestiary" to make sure you don't blow your head off.
1. VM-targeting languages have even more trivial cross-compilation, like you even get a single .jar file
2. There are hundreds of languages like that
3. It’s not too hard to be faster than python - Java, C#, JS are all in the same ballpark as Go (and for more complex programs some can often surpass it due to the much better GC-implementations)
4. Very very slightly easier than the above mentioned bunch. But with Java’s stellar backwards compatibility record you pretty much just has to have a big enough JVM version and that’s it.
I ask because I've started a side project in rust because all of its guarantees were appealing to me (I don't want to spend too much time on bugs, and my code uses some threads). I also need maximum performances. So I've chosen it. But now I have my compilation times that reach 45 seconds, so I'm slowly wondering if the go balance (towards fast compilation) would not be more advantageous; unless of course, performances are real bad...
There are a bunch of different metrics for performance that it is a little hard to compare.
Rust will have faster CPU and memory performance. It has no GC (well, other than RC). If you are IO bound, there won't be much of an appreciable difference, assuming you are using Rust's async/await for stuff. If you are using threads directly, then it will be a lot easier to make goroutines faster for IO stuff.
The long compile time of rust has a lot to do with it's LLVM backend, which is ultimately generating pretty fast code. You don't get that with go (well, unless gollvm lands). Go traded execution speed for compile speed by doing their own compiler/optimizer. Generally speaking, that doesn't really matter (hence the reason python is popular).
It's about on par with Java and C#, which is roughly in the ballpark of "half as fast as Rust/C/C++". If your goal is to spend less time programming overall, Go is great for most applications. If your goal is to spend 10% less time fixing bugs and 100% more time writing code, Rust is great for most applications. :) Of course those figures are made up, but in my experience they're in the right ballpark (I like both languages, but if I actually want to get something done in a reasonable timeframe I always end up using Go).
As someone who has started side projects with very technical and opinionated friends, just stick with Rust.
Make a decision, stick with it, ship it. If there's a real problem, change it after you have it up and running. There's no point in optimizing for millions of users if you have 0 users now.
yeah sure, I have zero user and well, it may be like that until my death :-)
that project was an excuse for learning rust. But now I understant rust a bit more, well, I'm a bit scare to wait 45 sec on each build for a side project (ie a project I do on my very limited spare time) :-)
but anyway, rust is really cool to work with (I have a python/C++/assembler/R background). The level of checking it does is really mindblowing (and frustrating at times :-))
Try to debug where your compile times are going[1][2], but if you want a good rule of thumb: separate your crate into multiple if you can (that way incremental compilation will yield better results), switch to an alternative linker, like mold or lld, and use trait objects instead of generics (monomorphization can be expensive during compilation, while trait objects can be slower at runtime, but not enough to be worth it worrying about it).
Thanks to some hints in those articles (basically, enabling incremental builds on release mode), I've been able to remove about 70% (yes!) of the build time :-)
Go is slower than Rust. Rust allows you to go as fast as the metal can get you if you want.
But Go is still reasonably performant and has a reasonably low memory footprint. We're talking C#/Java level performance with C level memory footprint.
To put it simply, with Go I ship a binary. With Python I have to ship my entire development environment.