Hacker News new | ask | show | jobs
by hyp0 4433 days ago
I thought you had meant that Go was "easier to maintain" than python - most of these don't apply to Python: Python has faster compilation times (0); interfaces without recompiling; formatting conventions; and numeric conversions is compared explicitly with C. Channels is the only one that applies to python.
5 comments

As some who generally prefers Python to Go quite strongly, the formatting situation is no where NEAR equivalent. With go it's trivial to setup your editor to perfectly reformat every time you save, or even on carriage return, and it does in a way that is 100% consistent and will never alter the logic of your code.
I'm not a python expert by any measure, but I've written a couple small projects with it. Python surprises for how well documented it is. In this specific case, PEP8 lays down most formatting conventions, so you'd expect some tooling to be available. Is this not the case?

A quick Google search brought up this, for instance:https://bitbucket.org/StephaneBunel/pythonpep8autoformat

The thing is, while this kind of thing is available for pretty much every language, it is standard for Go. As in, if you don't gofmt your code, everyone who looks at it will bug you to format it. That's a huge difference. There's basically zero code in the wild that you'd ever want to use that /isn't/ gofmted.
Exactly the point. Go is a VERY opinionated language. You see the term "idiomatic Go" used very regularly. The Go team and community push hard for everyone to follow a set way of doing things. This means all Go code must be formatted a certain way, handle errors in a certain way, etc. People even put pre-commit hooks into their VCS system that will reject .go commits unless they are properly formatted before commit.
I use Vim and there's a plugin just for that: making sure my code is PEP8 compliant.
Maybe he meant that having a typed language that is checked at compilation time is a huge plus for maintenance, and the usual downsides that come with compilation (mainly slowness) are pretty much inexistant with Go.
I think he mean one single big ass executable is way easier to maintain than pip install & virtualenv everywhere.

Yes we can also make a single big ass executable out of any python code but it's slower and not supported out of the box.

And IMHO that's whats killing python - the fragmentation.
You are incorrect about compile times in many ways. First- python byte compiles to a weird VM. Then it executes that. Second- go compilation times are comparable to python byte compilation time but the result is a native executable.
Python is interpreted, not compiled... Of course it has 0 compile time.