5 ms·

I don't get this recent narrative that the productivity you'd get out of languages like go is comparable to higher-level ones like python. As someone who uses b

by m0th87 13y ago

I don't get this recent narrative that the productivity you'd get out of languages like go is comparable to higher-level ones like python. As someone who uses both go and python in production, this sounds like the blub paradox in play here. Yes, you will get significantly better performance for CPU-bound applications in go vs python. But you'll also get significantly better productivity out of python, assuming equivalent knowledge.

mattrobenolt 13y ago
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. :)
- m0th87 13y ago
  This library? https://github.com/bmizerany/pq 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?
  - mattrobenolt 13y ago
    Yeah, but that's an older unmaintained version. Official is at https://github.com/lib/pq https://github.com/lib/pq, and I already shaved my yak. :) https://github.com/lib/pq/pull/135 https://github.com/lib/pq/pull/135
- frio 13y ago
  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.
bhauer 13y ago
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.
- m0th87 13y ago
  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.
burntsushi 13y ago
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.
- girvo 13y ago
  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 :)
  - virtualwhys 13y ago
    absolutely agree, static typing/FP convert here, once you get over the hump, it's a joy.
  - burntsushi 13y ago
    > 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.
    - girvo 13y ago
      Yes! Immutability and a lack of side effects has changed my mindset for the better. It really helps keep things understandable.
asdasf 13y ago
>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.
- m0th87 13y ago
  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.
  - asdasf 13y ago
    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.
  - fedesilva 13y ago
    "* 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.

by m0th87 13y ago

mattrobenolt 13y ago

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

m0th87 13y ago
This library? https://github.com/bmizerany/pq 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?
- mattrobenolt 13y ago
  Yeah, but that's an older unmaintained version. Official is at https://github.com/lib/pq https://github.com/lib/pq, and I already shaved my yak. :) https://github.com/lib/pq/pull/135 https://github.com/lib/pq/pull/135
frio 13y ago
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.

bhauer 13y ago

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.

m0th87 13y ago
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.

burntsushi 13y ago

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.

girvo 13y ago
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 :)
- virtualwhys 13y ago
  absolutely agree, static typing/FP convert here, once you get over the hump, it's a joy.
- burntsushi 13y ago
  > 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.
  - girvo 13y ago
    Yes! Immutability and a lack of side effects has changed my mindset for the better. It really helps keep things understandable.

asdasf 13y ago

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

m0th87 13y ago
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.
- asdasf 13y ago
  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.
- fedesilva 13y ago
  "* 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.