I add that Python is excellent at data representation and transformation. You can easily write some test data and just include it in python, then transform it any way you feel you like to get intelligence out of it. With the standard library you can easily load a CSV file you exported form a data-set and then aggregate and evaluate it with only a few lines of code without much language overhead. Schema-less mixed containers, array operations, dictionaries and sets are incredibly powerful and you can nest them anyway you like. Additionally you can also forget about type limits. Work with numbers as big as you like. That's useful for a lot of things.
Go is good at concurrency and speed. It has some very neat features but it's targeted at a different audience. Data transformations in Go are trickier. You have to do a lot of explicit transformation and that's just not as slick as Python. It really shines with concurrent programming, so I you are writing a server backend for your application and have to decide between C++ or Go, you might very well be compelled to go with Go. (C++ also has it's strength and is healthy as ever with the new standards, just more heavyweight).
I don't get why is Go defined as a competitor to Python. Go documentation itself places Go in the systems programming language class. The same class as C or Rust. The language advantages are defined by comparison to C. Heck, it starts by stating it compiles quickly.
I know Go is the language of the moment. Fashionable. I assume I take a cautious stance approaching fads, so I may tend to dismiss new stuff rather than all-in adopt every new tool. Having said that, my quick survey of the language features a couple of years ago produced nothing eye catching.
The concept of channels is nice, it lends itself easily to data pipelines and to SIMD parallel programming. It is not a breakthrough, though. SIMD is easily done in many many languages. Other than that, it's pretty down to earth. There's a myriad nice things (first class functions, closures, garbage collection, strong(ish) typing), but nothing ground breaking. There are also some choices that smell, namely the lack of inheritance due to the flat type hierarchy (and the obvious need for a fix), or the inability to overload methods and operators.
All in all, there's not enough in Go to warrant the level of attention the language gets. It's a nice language, it's not groundbreaking.
On the same class, Rust is looking rather nice. The memory management model alone is enough for me to keep an eye on how its ecosystem develops.
Go was never a class of C and Rust. Maybe it becomes once, but at the moment I observe it as a kind of server-side Java replacement: by the current design it simply can't be as low level as C and Rust. The main difference with Java is that it compiles to he native code and not bytecode. Still it is dependent on its own special conventions, GC and libraries.
The confusion comes from the announcements of the Go team where they claimed a "systems programming language" where they, it seems, didn't mean "operating systems" but more "some user-space programs on our servers," that is, their in-house user-space "systems." They of course discovered that the only group who saw possible benefits were programmers that would otherwise use languages like Python but liked extra speed and convenience of a compiled language. The other group were those that liked Go's concurrency primitives.
> the only group who saw possible benefits were programmers that would otherwise use languages like Python but liked extra speed and convenience of a compiled language.
To say "the only group" is far from true. Go has a lot of uptake among people who would otherwise use C++ or Java, for example. And yes, actually there is overlap in the audience of Go and the audiences for C or Rust. Go has its own advantages but really lacks the advantages of a very high-level interpreted language.
I agree, "the only" is wrong wording. Luckily there are more sentences in my reply. And actually there are elements of Go that I like. However my impression of the responses of the compiled-language groups were: C: "oh, it's GC, runtime-lib and its calling conventions dependent," C++ "oh it can't make universal containers" and Java "oh it lacks exceptions." Only the Python people were "oh it's much faster than Python and not much harder." And no, I don't think Go needs exceptions.
The people who call Go a systems programming language are fundamentally misguided. It is an applications programming language under any reasonable definition.
Yes, but they are also the ones being surprised that Go is cannibalizing Python, not C or C++.
They are smart guys, so I can only conclude that "systems programming" means something different to them than it does to many other systems programmers.
To me, "no imposed GC" is a non-negotiable element of being a systems programming language. So I am far more drawn to Rust than Go.
«
No major systems language has emerged in over a decade, but over that time the computing landscape has changed tremendously.
(...)
We believe it's worth trying again with a new language, a concurrent, garbage-collected language with fast compilation. Regarding the points above [cut on edit]:
* It is possible to compile a large Go program in a few seconds on a single computer.
* Go provides a model for software construction that makes dependency analysis easy and avoids much of the overhead of C-style include files and libraries.
* Go's type system has no hierarchy, so no time is spent defining the relationships between types. Also, although Go has static types the language attempts to make types feel lighter weight than in typical OO languages.
* Go is fully garbage-collected and provides fundamental support for concurrent execution and communication.
* By its design, Go proposes an approach for the construction of system software on multicore machines.
»
It is still at the forefront of the language presentation.
> I don't get why is Go defined as a competitor to Python.
To me the area where Go excels the most, and where I feel most strongly compelled to use it, is in tooling apps that you expect your users to install on their machines and run from a command line. This has been an area where python and ruby have been pretty common, but they're both a complete pain in the ass to use that way (setting up virtualenv, setting up rvm, pip problems, gem/bundler problems, etc).
For eg. we use vagrant and fabric at my work for server management (vagrant+fabric for dev environments, fabric alone for production servers). One's written in ruby and the other is written in python, and we have to spend a non-trivial amount of time managing their dependencies so they continue to install correctly. If they were go apps we'd just build and install binaries.
This is the area where I think Go is taking up python users, personally.
Go has pretty neat semantics for channels and goroutines, but it presumes you want threads and blocking IO. Or in other words, "hey kid here's some rope"
Your approach to concurrency matters even more than the tool you use, and python is a great tool for network services. It's my preferred tool actually.
Go is good at concurrency and speed. It has some very neat features but it's targeted at a different audience. Data transformations in Go are trickier. You have to do a lot of explicit transformation and that's just not as slick as Python. It really shines with concurrent programming, so I you are writing a server backend for your application and have to decide between C++ or Go, you might very well be compelled to go with Go. (C++ also has it's strength and is healthy as ever with the new standards, just more heavyweight).