5 ms·

I have recently installed Go on my machine. Then I made a quick little server and put it on Digital Ocean. It was seriously the easiest thing I've done with "sh

I have recently installed Go on my machine. Then I made a quick little server and put it on Digital Ocean. It was seriously the easiest thing I've done with "shipping" code in a long time. I love Python, it is my hammer and everything looks like a nail. However, Go makes it so easy to share/deploy all the things. I could see Go becoming my hammer.

ambulancechaser 11y ago
i played with it last week but decided to play around with Rust instead since there was no debugger support and the official statement from the go team was that they have no intention of making integrations with gdb
- reality_czech 11y ago
  The problem with Go is that it only works in practice, not in theory.
devishard 11y ago
Have you tried writing "a quick little server" in Python and deploying it? Packaging and deployment aren't problems in Go OR Python if you're only solving trivial problems. With a larger project, you might have an easier time packaging and deploying Go code, but that's largely because there are no libraries to package. Admittedly packaging can be a pain in Python, but that's usually because of poor choices in dependencies. Packaging Python with a few mature dependencies isn't hard in my experience. It's the projects where some idiot has pulled in every 0.x versioned library in pip that are hard to package. When Go has as wide a variety of libraries as Python people will run into the same problems in Go. You could argue that at least for now Go doesn't allow you to shoot yourself in the foot that way, but I'd rather have the option. I'm not defending Python in particular here. I'd say the same things I've said here about any mature language with extensive libraries. If you're espousing Go because of easy packaging and deployment, I strongly suggest that you consider whether that's actually a feature Go will have long term, and whether you're currently paying for that feature by having no libraries available to you. The only lesson I would take away from Go's easy packaging is to only use mature dependencies that pull their weight.
- ashearer 11y ago
  Go and Python deployment aren't quite that equivalent. I've seen build and deployment problems over multiple years with widely-used Python libraries including Python-MySQLdb and Python Imaging Library (PIL). The Go equivalents for such essential libraries are typically in pure Go, so it's much easier to avoid C build and link errors when choosing project dependencies. The prevalence of pure-Go libraries is likely to remain high in the long term even as Go's base of libraries expands.
  - devishard 11y ago
    C build and link errors are only one of a myriad of issues that one can have with packaging. I've had far more problems with badly-managed packages in pure Python than with stuff like PIL. And one only has to look as far as JavaScript to see that pure native language dependencies won't save you. I stand by what I said: give it a decade and Go packaging will be just as miserable as packaging in any other language.
lmm 11y ago
Have a look at OCaml. For simple standalone binaries it's a real sweet spot: it's powerful and safe without being complex. It has the best module system going and a mature open-source ecosystem, and in the last few years it's converged on a good package/dependency manager. There's a great series of blog posts from someone who looked at replacements for Python and ultimately moved to OCaml, summarized at http://roscidus.com/blog/blog/2014/06/06/python-to-ocaml-retrospective/ http://roscidus.com/blog/blog/2014/06/06/python-to-ocaml-ret...

ambulancechaser 11y ago

i played with it last week but decided to play around with Rust instead since there was no debugger support and the official statement from the go team was that they have no intention of making integrations with gdb

reality_czech 11y ago
The problem with Go is that it only works in practice, not in theory.

devishard 11y ago

Have you tried writing "a quick little server" in Python and deploying it? Packaging and deployment aren't problems in Go OR Python if you're only solving trivial problems. With a larger project, you might have an easier time packaging and deploying Go code, but that's largely because there are no libraries to package. Admittedly packaging can be a pain in Python, but that's usually because of poor choices in dependencies. Packaging Python with a few mature dependencies isn't hard in my experience. It's the projects where some idiot has pulled in every 0.x versioned library in pip that are hard to package. When Go has as wide a variety of libraries as Python people will run into the same problems in Go. You could argue that at least for now Go doesn't allow you to shoot yourself in the foot that way, but I'd rather have the option. I'm not defending Python in particular here. I'd say the same things I've said here about any mature language with extensive libraries. If you're espousing Go because of easy packaging and deployment, I strongly suggest that you consider whether that's actually a feature Go will have long term, and whether you're currently paying for that feature by having no libraries available to you. The only lesson I would take away from Go's easy packaging is to only use mature dependencies that pull their weight.

ashearer 11y ago
Go and Python deployment aren't quite that equivalent. I've seen build and deployment problems over multiple years with widely-used Python libraries including Python-MySQLdb and Python Imaging Library (PIL). The Go equivalents for such essential libraries are typically in pure Go, so it's much easier to avoid C build and link errors when choosing project dependencies. The prevalence of pure-Go libraries is likely to remain high in the long term even as Go's base of libraries expands.
- devishard 11y ago
  C build and link errors are only one of a myriad of issues that one can have with packaging. I've had far more problems with badly-managed packages in pure Python than with stuff like PIL. And one only has to look as far as JavaScript to see that pure native language dependencies won't save you. I stand by what I said: give it a decade and Go packaging will be just as miserable as packaging in any other language.

lmm 11y ago

Have a look at OCaml. For simple standalone binaries it's a real sweet spot: it's powerful and safe without being complex. It has the best module system going and a mature open-source ecosystem, and in the last few years it's converged on a good package/dependency manager. There's a great series of blog posts from someone who looked at replacements for Python and ultimately moved to OCaml, summarized at http://roscidus.com/blog/blog/2014/06/06/python-to-ocaml-retrospective/ http://roscidus.com/blog/blog/2014/06/06/python-to-ocaml-ret...