Hacker News Reader

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.

> 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.

The people who call Go a systems programming language are fundamentally misguided. It is an applications programming language under any reasonable definition.

You know that "the people who call Go a systems programming language" are its authors, do you not?

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.

They actually dropped the "systems" bit on the home page because people told them it wasn't a systems language.

"Systems" in Rob/Ken's time was services/servers - what we call applications these days.

You know that they retracted that line from the Go introduction text on the webpage, don't you?

And of course, them being Go's authors and them being wrong on characterizing it, is in no way contradictory.

http://golang.org/doc/faq#What_is_the_purpose_of_the_project

« 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 add that Python is excellent at data representation and transformation

Indeed! It's a very practical extraction and reporting language.

I see what you did there :-)

When it comes to Unix glue jobs, it's certainly no Perl.

Shame it doesn't have regex syntax built in...

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.

Maybe it's time to start porting twisted to go.

I think D will grow in that server space.