It looks like the author found the worst use case for Go in comparison to a library that Python absolutely soars in and uses that as a basis for this argument. Go does not have something as nice as numpy. For numeric computing, by all means use Python.

He then makes some crazy statements about operator overloading as if that is the essence of a good language. I disagree. I don't want operator overloading. I almost never used operator overloading in C# or Java. Maybe that's just me, but it's certainly not a reason to avoid a language.

The crux of his argument is that C++ users who switched to Java years ago are the types of programmers that Go wished to convert.

He neglects to mention deployment. He neglects to mention stability in runtime. He neglects to mention any low level meddling that you have to do in compression. The examples you posted are exactly the kind of things that Go soars in. It's very convenient to leave them out while beating your chest about how your language is a superior language because it is superior in a very specific niche.

Erm... so:

* I didn't "find" my use cases - they found me. All are real things I do with Python.

* I'd switch to something faster than Python, and finding more errors statically, if it wasn't for the bunch of things I'd miss.

* I like C better than C++ though the former lacks operator overloading; it's not "the essence of a good language", just one thing I use in Python.

* Further evidence that "I'm not here to bitch about Go for the sake of it": I didn't mention generics or similar, for instance - because they don't matter in the cases where I use Python, at least I don't recall that they do. I'm not looking for things to complain about.

* Deployment, etc. - it probably won't make someone switch to Go though it might be nice if you start in Go, and also - it's an argument in itself. I like how in Python you can change a file and all code using it "sees" the change, or how in languages with dynamic libraries/runtimes/whatever you change the library and all code "sees" it. Basically there are deployment trade-offs and in my environment - a controlled LAN - Go is simply worse. On a DreamHost box with ancient everything it'd be a godsend.

Overall - I don't think "Python is better than Go", but the ones who "beat their chest about how your language is a superior language because it is superior in a very specific niche" are people arguing about Go the way you do :-) That niche in Go's case being servers.

Speaking of servers... I know the difference between servers and web servers, I just said/implied that if Go is great for web apps, then it might take off as a really big thing, if it's just for high-performance infrastructure it's a language for Google, CloudFlare and a small number of others...

You've been saying that it's just about your own use cases, but your statements in that post are much more general. For example:

> What does Go have that Python lacks? Performance, static typing.

That's a very simplistic view. Being a long term Python developer that switched to Go as the preferred language years ago, here are some of the things I appreciate on the other side of that fence:

- Performance, indeed.

- Static typing, yes.

- A simpler language specification (a big one for me, game changer for large code bases in large teams)

- Interfaces based on structural typing ("static duck typing", as some say)

- Much better control of memory layout (struct with 2 int64s takes 128 bits in memory, a list of those takes N*128bits)

- Built-in micro-threads (goroutines)

- A runtime that schedules (means, you can block, despite concurrency)

- Buffered and unbuffered channels managed by the runtime (with select, etc)

- Builds native static executables, fast (maybe you don't care, many people do)

- A much better organized standard library

- A very good http server _and_ client package in the standard library

- Good crypto packages and APIs in the standard library

- Error handling without exceptions (that's a pro for me and many, feel free to disagree)

- A very elegant system to define access control (private/public) on vars/funcs/types/fields/consts/etc.

- All names inside files that are part of a package ("directory") are part of the same namespace (allows better organizing code than with Python's file-is-a-module style)

- Code files that can see declarations out of order (improves code organization)

- gofmt! godoc! Love those.

- None of the Python 2 => 3 migration mess (people are being told to program in a pseudo-language that is neither Python 2 nor 3 in recent times)

And so on... That's not to judge your use of Python, though. By all means stick with Python if it suits your needs.

As a last point, if you're interested in Qt bindings, I've been working on this:

https://github.com/go-qml/qml

Some applications coming out of it:

http://blog.labix.org/2014/04/25/qml-contest-results

> - Performance, indeed.

I have been really disappointed and underwhelmed by Go's performance (I have not tried the gccgo yet). For such a simple, statically typed language I was expecting really an order of magnitude better performance. So, in light of Cython and Pypy the performance story is quite murky, the other points do stand.

Performance is always a hard topic to talk about. For almost any language you can optimize hotspots in the code to make it go super-fast. You can make any code run slow in any language if you are not familiar with how the language behaves.

Go has pprof which allows for profiling of your code to help find the hotspots. Without a specific case it's hard to say that Go is fast or slow compared to other languages.

That's not about how much the code might be optimized. I could always step out of Python and do a C module if I needed speed.

Instead, what's valuable in terms of the perceived performance delta is the speed of standard code as one would write intuitively and conventionally. With a reasonable understanding of how CPython compiles and interprets code, and a reasonable understanding of how the standard Go compiler suite generates binary code, one can make ballpark-style statements of performance for such code without lying too much.

Sure, there's PyPy, and there's gccgo, but that's not what most of the respective communities are using today, and it's not what we use in the projects I'm part of either.

I'm curious - why did you go with Python over Java in the first place? Many of your bulletpoints are also things that Java gives you, except for the duck-typed interfaces, goroutines, and control over memory layout.

> It looks like the author found the worst use case for Go in comparison to a library that Python absolutely soars in and uses that as a basis for this argument.

But you also seem to be using a bit of a straw man here as well, aren't you?

You focus how he picked numpy and operator overloading.

Ok how about REPL, does go have one? No.

Does it support dynamic code loading?

Does it have exceptions?

He wants exceptions. That is his post. Remember, the title "Things I'd miss". Not things "jamra" should miss.

Let's continue.

Does Go have a lot of GUI bindings? No. Ok talk about that maybe as well.

> He neglects to mention deployment. He neglects to mention stability in runtime. He neglects to mention any low level meddling that you have to do in compression.

So where is your blog post then?

Ok. You have a point, though I don't think my argument is a straw man. Numpy is one of those rare and great libraries.

Go's error handling is the way it is for a reason. The authors chose to leave out exceptions. Stating that exceptions are better because you're more used to them or because they more easily hide errors is not a good critique. Even if you choose to squelch your errors in Go, you can always go back into your code and handle your errors appropriately. That makes it far easier to find bugs and makes your code very robust. I personally like how it compares to C in that regard.

Go has some QML bindings that are pretty great, although I don't think that third party libraries are a good measure for a language. Especially seeing as how Go is quite young. I think that facets of the language itself are better choices of criticism.

To help the OP, I think that python and other functional languages make dealing with abstract concepts more appealing. I walked the tight rope between writing Flask web sites and Go web sites. In the end, I know how to do either and I don't think one language needs to be better than another. In the case of my example, Sql Alchemy makes it much easier to make web apps. This does not detract from my issue with these kinds of articles in general. This seems to me more like a programmer trying to convince himself to not like a language due to his comfort zone.

> how about REPL, does go have one? No.

What? https://github.com/rocky/go-fish "Yet another Go REPL"

Made by a third party, it doesn't come with Go. Granted neither is numpy.

> I almost never used operator overloading in C# or Java.

Dude, you can't overload operators in Java. You can overload methods of a class, but not operators. Operator overloading means that you can overload '+' for example for your particular class, which would enable you to write code like (in Java):

    Matrix a = zeroMatrix(4,4);
    Matrix b = identityMatrix(4,4);
    Matrix c = a+b;

You can't do that, so you would have to write:

    Matrix c= a.add(b);

Which makes your code verbose and makes Java (and Go) painful for doing numerical analysis.

It's important to note that numerical calculation is a domain particularly suited to operator overloading simply because the underlying domain (math) already uses operator overloading heavily (e.g. multiplication means something different when done on scalars and vectors, but in both cases it is well defined and in common usage).

You should leave out the 'overloading':

- Math (and it's very close relative logic) are the only domains that use operators, period.

- other domains use overloading; homonyms are very common.

Which leads us to that ugly a.equals(b) instead of sane a == b. When not abused, operator overloading is a bless.

Except that a == b and a.equals(b) are two different things.

As it stands you can't in Java but you can in C#, although it's usually a really bad idea.

My comment only applies for Java - I don't know C#. As you say, it's usually a bad idea but it's quite reasonable to do for numerical analysis, as your sibling comment says.

You are right. Can you tell which language I spent more time with?

"Also, our entire logging and analysis infrastructure is being migrated to Go." This intrigues me. I've been moving a lot of ETL into Go (as it's pretty well suited to this), but I still end up doing a lot of the analytics in Spark (for bigger work) or Pandas or R (for smaller bits of data). What are you guys planning on doing for the analytics? Or is it more of straight up time series work (so you can use influx + whatever). Just curious and keep up the good work :)

Since I'm not actually involved in that project I'm going to defer answering until we write a detailed blog post.

Also, if you are interested in a job...

"Also, our entire logging and analysis infrastructure is being migrated to Go." This intrigues me....

Go is great for this kind of stuff. Spark is great when you have a lot of custom queries, but if you have a few fixed queries writing a simple solution in Go have have huge gains.

I worked to implement a web service + simple map reduce (with network transparency) + a time series DB (storage engine too, NOT using levelDB like influx) all in Go and the result was it is many times faster than an order of magnitude larger hadoop cluster, BigQuery, etc for the limited operations it supports.

Did you use a framework to run mapreduce with go or did you roll your own?

We wrote our own, Go 1.0 had just come out.

It seems that you have the canonical type of use case for Go.

Server systems for thousands of customer and huge number of requests. Python became a jack of all trade where concurrency and performance is not the main focus.

Is the Lua stuff going away? What are your opinions of Go vs Lua?

Nope. No need to throw away the Lua. We're moving more and more to a combination of C-based (nginx) for core serving, Lua-based for logic and Go for services.