5 ms·

IMO we loose a lot with go: having to compile, loosing the interactive shell, etc. Best case you work with a lot of people who know how to install python and us

IMO we loose a lot with go: having to compile, loosing the interactive shell, etc. Best case you work with a lot of people who know how to install python and use pip. Many people whine on boards, but it's not that complicated, especially with python 3.

cconstantine 5y ago
> install python and use pip Now you've given your users 2 issues completely unrelated to the problem they're trying to solve. If you can't give your users a single simple command, or a single file to download your tool is too complicated to install.
- p_l 5y ago
  Not to mention all kinds of python version issues, especially given that botched 2-to-3 migration means there's a lot more Python 2 than there should be.
  - worik 5y ago
    Yes. Except. If I have a Python2 tool I paid $X for, and now I need to to change it for $Y because, because, because no reason. Tough luck! Stop "whining" and write a cheque!
    - burnished 5y ago
      Where does that happen? Honestly I think I only know of open source python stuff, so I'm real curious!
      - worik 5y ago
        What is open sauce? My point being to the users of the products we create, software licensing is not what they are thinking about.
        burnished 5y ago
        I'm asking you about this >Yes. Except. If I have a Python2 tool I paid $X for, and now I need to to change it for $Y because, because, because no reason. Tough luck! Stop "whining" and write a cheque!
shoo 5y ago
> we loose a lot with go: having to compile If you're concerned about compile time -- Go does a pretty reasonable job of caching (including caching unit test results). If you're working on a Python project with a large number of unit tests, because Python is so slow to execute anything, and the go build and test tools are quite fast, it wouldn't be that surprising if it was actually faster to compile and run the test suite in Go vs running the test suite in Python -- particularly for incremental work where you make a change in one library and rerun the impacted tests. If you're concerned more about the workflow of needing an additional compile step, go has `go run script.go` which lets you use go like a scripting language, assuming you're in an environment with the go toolchain installed.
pphysch 5y ago
I used to abuse Python's REPL and realized I was wasting a lot of time in the REPL that could be saved by articulating my tests in a proper test file or even just main(). pkg.go.dev and gopls also automate away most of the "exploration" I would be doing in Python REPL.

cconstantine 5y ago

> install python and use pip Now you've given your users 2 issues completely unrelated to the problem they're trying to solve. If you can't give your users a single simple command, or a single file to download your tool is too complicated to install.

p_l 5y ago
Not to mention all kinds of python version issues, especially given that botched 2-to-3 migration means there's a lot more Python 2 than there should be.
- worik 5y ago
  Yes. Except. If I have a Python2 tool I paid $X for, and now I need to to change it for $Y because, because, because no reason. Tough luck! Stop "whining" and write a cheque!
  - burnished 5y ago
    Where does that happen? Honestly I think I only know of open source python stuff, so I'm real curious!
    - worik 5y ago
      What is open sauce? My point being to the users of the products we create, software licensing is not what they are thinking about.
      - burnished 5y ago
        I'm asking you about this >Yes. Except. If I have a Python2 tool I paid $X for, and now I need to to change it for $Y because, because, because no reason. Tough luck! Stop "whining" and write a cheque!

shoo 5y ago

> we loose a lot with go: having to compile If you're concerned about compile time -- Go does a pretty reasonable job of caching (including caching unit test results). If you're working on a Python project with a large number of unit tests, because Python is so slow to execute anything, and the go build and test tools are quite fast, it wouldn't be that surprising if it was actually faster to compile and run the test suite in Go vs running the test suite in Python -- particularly for incremental work where you make a change in one library and rerun the impacted tests. If you're concerned more about the workflow of needing an additional compile step, go has `go run script.go` which lets you use go like a scripting language, assuming you're in an environment with the go toolchain installed.

pphysch 5y ago

I used to abuse Python's REPL and realized I was wasting a lot of time in the REPL that could be saved by articulating my tests in a proper test file or even just main(). pkg.go.dev and gopls also automate away most of the "exploration" I would be doing in Python REPL.