I also write Go probably just as much as Python anymore, and the biggest set backs I have in Go is the immaturity of the ecosystem. Almost any project I work on, I have to shave 10 yaks to get things working right.

My most recent yak was fixing lib/pq so I could query against our production dbs. :)

This library? https://github.com/bmizerany/pq

If so, we're about to use it. Anything we should be forewarned about with respect to its use in production settings?

Yeah, but that's an older unmaintained version. Official is at https://github.com/lib/pq, and I already shaved my yak. :) https://github.com/lib/pq/pull/135

That's largely why I ended up back on Python, after experimenting with Go a bit. I'll try Go out again in a year or two, when others have forged the path a little better.

This is a subjective matter, I suppose. I can see your point about Go. As a counterpoint, looking back on projects my team has worked on, I can't say we've reaped a great deal of net gains from leveraging the more mature Ruby or Python ecosystems, especially as compared to a modern JVM stack. Sure, sometimes we find a library that claims to address our need, but we often find the library doesn't do what we need precisely, is incompatible with something else we're using (e.g., JRuby), or whatever. The quality is all over the map. Net efficiency seems like a wash in my experience. But YMMV is always applicable with developer efficiency.

Yeah, that's fair. Our biggest cost has been the same - the libraries aren't there yet. This is something whose impact would likely vary a great deal from one project to the next. I do think there is quite a bit to be said of the value of higher-level language semantics as well though.

Anecdote: I definitely don't agree. Both Python and Go are in my wheelhouse, and I feel much more productive with Go than Python. Personally, I think it's the static types and simple language design. (i.e., Reading Python code, for me, requires a higher cognitive load than Go.)

I freely admit that this may vary from person to person, but I think it's close enough that you don't need to resort to rationalizations like the Blub Paradox.

Background: I've probably written ~100K LOC in each of Go and Python in the last few years.

I agree. I feel more productive in statically typed imperative languages, vs dynamically typed ones; it took me a while to get there though. The change in mindset was difficult to start with, coming from A dynamic scripting background.

I'm learning functional programming at the moment, and hope to have a similar epiphany :)

> I'm learning functional programming at the moment, and hope to have a similar epiphany :)

I've done quite a bit of FP, but I've still held out from acquiring a traditionally FP language as a go-to language in my toolbox. Instead, I've found the intense focus on abstraction and representation in the FP world leak over into my interaction with other more imperative languages.

Yes! Immutability and a lack of side effects has changed my mindset for the better. It really helps keep things understandable.

absolutely agree, static typing/FP convert here, once you get over the hump, it's a joy.

>But you'll also get significantly better productivity out of python, assuming equivalent knowledge.

Why? What is python doing to get you better productivity? As someone who is certainly not an expert at python, but used it as my perl replacement for a few years I feel like I am as productive in python as I am going to get. I was just as productive in go after two days of playing with it. The only reason I can see to use python is if it has a library/framework go doesn't.

Biggest semantic baggage of go over python that I've experienced:

* Lack of exceptions causes a lot of noise. Wrapping a bunch of code in try/catch is just more terse.

* Lack of parametric polymorphism means there's no useful higher-level functions like map, fold, etc.

"* Lack of parametric polymorphism means there's no useful higher-level functions like map, fold, etc."

This is one of my problems with Go, too. This will add line after line of repeated code in the long run. Time will tell.

I find the opposite on the error handling. The lack of exceptions is one of the few things I like about go. I just wish they had done error handling correctly instead of the stupid kludge they put in because "durr what is an ADT?". I agree that the lack of parametric polymorphism makes go essentially useless, I just don't understand how python is any better. It also lacks parametric polymorphism, and in fact polymorphism period. It is a unityped language.