Hacker News Reader

Hacker News

Comment by aturek | Hacker News Reader

Parent Full thread

aturek

This sounds really interesting, but can you elaborate on how Go scales better with maintenance?

(disclosure: I haven't fiddled with Go at all yet, so I know nothing about the language itself)

View on HN

Several things make it easier to maintain:

- super fast compile times for fast developer iterations

- you can create an interface (set of methods) that your module owns, and apply it to objects created by other modules without recompiling. If you only need one method you can take that one. It encourages decoupling you from your dependencies.

- the code has one correct formatting convention and a tool that will auto-format your code

- many complex rules for numeric conversions that are implicit in C and cause no end of trouble are explicit and much simpler in Go.

- treating concurrency as a series of sequential process connected with channels makes it MUCH easier to reason about.

Don't the first 3 apply just as well to python? It compiles fast, and is duck-typed so interfaces are always there and implicit, and the indent-based blocking ends many arguments about formatting.

the difference is that if you're not careful when you cut-paste indented blocks in python, you can easily change logic.

If you cut and paste probably the misaligned indentation is the least problem. Cut and paste should be avoided if it's not done during a refactoring (so actual moving of code for better design).

Beginners usually think Python strong indentation is a weakness of the language. I actually find C++ freedom being more error prone:

    if (a < b);
        a = b

It's a not very frequent bug, but when it happens it takes you hours to spot. ;)

Yes and in Go (and hopefully all curly-brace languages of the future) this is actually a syntax error, you need the braces:

  if (a < b) {
     a = b;
  }

And you don't need the semicolons!

The thing I don't get...if braces are mandatory (Good), why keep the now completely, unambiguously, irrelevant () around the cond?

They're actually not required in Go.

You don't need those parens in Go, and go fmt will in fact remove them/

If you ran the code through gofmt, it would remove the () around the cond for you. I code go in SublimeText with GoSublime. On every save it runs the file through gofmt and reformats it for me. Keeps my code looking pretty with very little effort.

This would never happen to me because I frequently format my doc, and it wouldn't be indented.

Python executes, it does not compiles.

EDIT: Whoops, it's actually compiled into bytecode then executed by the VM.

This is not true.

As the_paul said, this is incorrect.

https://en.wikipedia.org/wiki/Python_(programming_language)#...

It actually "compiles" into bytecode, then consumed by the interpreter.

it's generous to call the CPython interpreter a VM - the binary encoding of Python isn't some crazy IL bytecode, its' really just python-as-binary. Language constructs converted into opcodes, strings with pre-calculated hashes, and local variables within a scope become a sort of vector... but otherwise, it's a prettymuch 1:1 mapping between Python language constructs and the bytecode form.

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.

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.

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.

Python is interpreted, not compiled... Of course it has 0 compile time.

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.

Reply on news.ycombinator.com