Hacker News Reader

I'm curious, how does it compare to Java with a good IDE (eg. Eclipse or IntelliJ)?

One thing I really missed when I abandoned the Java world and went to C++/Python was the refactoring and formatting tools available in the IDE. I could set it up so it'd auto-format my code on save, so that I could rename methods with a single keystroke, so that I could pull out classes or add getters/setters, so that I could add parameters, etc. I know Go supports some of that through gofmt and go fix, but I'm curious if anyone is both an experienced Java dev and an experienced Go dev and can compare the continued maintenance costs of the two.

BTW, I would put the productivity premium of Go over Python at about 50%-2x, not 10%. I did a mid-size (~6 man-months, though much of that time went into interactions with other teams) green-field prototype in Go at Google, and found myself really missing constructs like list comprehensions, dynamic typing, strong support for literal data, ability to treat user-defined types just like the built-ins, etc. I do think you'll make some of that back in continued maintenance - I actually really enjoyed working with Go - but I didn't experience the claims of "Go is just as good as Python for prototyping", as someone with a fair amount of Python experience.

Experienced Java and Go dev here.

On formatting, gofmt is awesome. There's an IDE called LiteIDE which automatically calls gofmt for you, or you can just run it yourself whenever. Additionally, because there's deliberately no room to customize gofmt, you don't have to spend time in pointless meetings when "that guy" decides it's time to rewrite your company eclipse templates and argue over all the minutiae.

As far as refactoring, nobody's built an IDE integration that comes close to eclipse/IDEA for that as far as I know. It's totally doable in Go, in a way that it wouldn't be for Python (yay types), but I don't think anyone's done it. On the upside, doing it manually is less painful than it would be in typical Java code, due to type inference and having less code to begin with.

I wasn't a huge fan of LiteIDE when I tried it. I prefer GoSublime[1] with SublimeCodeIntel[2], with goimports[3] for my gofmt command. The combo of the three is really awesome.

[1] https://github.com/DisposaBoy/GoSublime

[2] https://github.com/SublimeCodeIntel/SublimeCodeIntel

[3] https://github.com/bradfitz/goimports

What does SublimeCodeIntel provide that GoSublime doesn't already give you? GoSublime gives you Gocode support, so you have full auto-complete already.

For some reason I thought that was where I got the autocomplete from, but as you've pointed out it's totally unrelated.

Cool, just wanted to make sure. I just started with Golang and wanted to make sure I didn't miss something.

gofmt is the single biggest feature of Go that might make me try it out. Such a great idea, I wish every language would adopt it.

If you use C# in Visual Studio, you can press Ctrl+K, Ctrl+D to have the entire document reformatted. Surprisingly few people seem to know about this, judging by how often I've found myself using this on other people's source files and had everything shift around. (Or maybe I'm just unusual and everybody else has just played with the settings.)

The reformatting is actually quite aggressive (it will add/remove blanks and move braces and bits of code around), and so does a good job of keeping everybody's code looking consistent. The Visual Studio text editing functionality only occasionally reaches even the lofty heights of "pretty good", but I do think the document reformatting actually even exceeds that.

(Shame the settings are are per-user rather than per-project, but there you go. It wouldn't be Visual Studio if they didn't manage to fuck something up at the last moment.)

Every decent IDEs have a code formater, but not everyone uses the same IDE so its usefulness is limited. On the other hand, gofmt comes with the platform and make it easy to enforce a common standard between developers.

That said, I think that in C#'s specific case most developers should be using Visual Studio.

The default Visual Studio formatting sucks - wasted lines for opening braces when we have limited vertical real estate. Visual Studio should support per-project, or per-solution formatting configurations, which can be placed into the source code repository to ensure everyone on the team is using the same settings - MonoDevelop already does this and it's really useful for switching between projects which use different formats.

A lot have:

https://news.ycombinator.com/item?id=7600130

This isn't the same. Go defines a standard format for all code written in Go with nothing left up to programmer opinion. While a lot of great formatting tools exist for other languages, they require choices to be made which inevitably results in disagreement.

Four space tabs are like a splinter in my mind.

That suggests you don't understand what tabs are. Tabs are a single char, not x number of spaces. You can set your text editor to display tabs as any number of spaces you want, I set mine to two.

See: https://www.youtube.com/watch?v=sln-gJaURzk#t=1735

No need to be pedantic. The choice is more that just trivial display in and IDE.

For example,

https://github.com/zenazn/goji/blob/master/goji.go

> There's an IDE called LiteIDE which automatically calls gofmt for you...

or on emacs, if you use the packaged go-mode.el, you can run gofmt on the "before-save-hook" to do that for you...

I'm surprised nobody has mentioned gofmt -r yet.

http://golang.org/cmd/gofmt/

missing constructs like list comprehensions, dynamic typing, strong support for literal data, ability to treat user-defined types just like the built-ins, etc.

Of those, I only see comprehensions as something that's severely lacking, though I am not a Python guru by any measure. Dynamic typing: Go has duck typing, which gives some of the same benefits. Different refactoring strategies that take advantage of duck typing over other things you'd do with dynamic languages (like just substituting an object of a different type willy-nilly) will probably make up for the rest. I don't see strong support for literal data as a big productivity gain. Go also does a rather good job of treating user defined types like the built-ins and vice-versa, with a few exceptions like maps.

I didn't experience the claims of "Go is just as good as Python for prototyping", as someone with a fair amount of Python experience.

A lot of your competence with Python for prototyping probably has to do with your competence with Python. A lot of the advantage of Go is what it doesn't have. It's a much simpler system, so it's easier to design around, especially as one needs to get closer to the metal.

The use-case for dynamic typing was that I was decoding a large JSON data structure that could easily have thousands of different fields nested 10+ levels deep. Go's standard json library usually recommends that you define a struct type to hold the result of the decode, tagging field names with the `json` annotation. This obviously doesn't work when you only care about a few dozen of the several thousand possible fields. There is fortunately an escape hatch where you can declare a field as interface{} to say "Any type of data goes here; I'll downcast it later, and just trust me on the type", but then you have to litter your code with downcasts.

Python just hands you back a dict of lists, and you pull out the information you want, no type declarations needed.

The "user-defined types like built-ins" lets you build libraries where you can use the basic language structures on the data structure itself, without having to convert to an intermediate form. For example, the Python bindings to Amazon S3 let you access files through dictionary notation. BeautifulSoup lets you iterate over child nodes with a for loop, or access attributes as a dict. NumPy lets you use standard arithmetic operators on matrices. Judicious use of this in libraries makes the resulting code much briefer.

    >  I was decoding a large JSON data structure that could 
    > easily have thousands of different fields nested 10+ 
    > levels deep. Go's standard json library usually 
    > recommends that you define a struct type to hold the 
    > result of the decode, tagging field names with the 
    > `json` annotation. This obviously doesn't work when you 
    > only care about a few dozen of the several thousand 
    > possible fields.

Sure it does!

    type Response struct {
        LevelOne map[string]struct{
            LevelTwo map[int]struct{
                Value string `json:"eventual_value"`
            } `json:"level_two"`
        } `json:"level_one"`
    }

The response can have way more fields than just the ones you declare in your struct.

Compared to the Python version of:

  response['level_one']['level_two']['eventual_value']

?

I did ignore fields that I wasn't interested in; however, you do at least have to declare all the intermediate structs in the tree. With 10-ish levels of nesting, that's a lot of boilerplate; even in your example with 3 levels, you've still got 6 lines of code for what's a one-liner in Python.

It wouldn't be as much of a problem for a production system where you define your data structures once and then expect to amortize them over many, many changes. But I was prototyping, and the point of prototyping is to not spend time on boilerplate that isn't necessary to prove out your concept. A few hundred lines of type declarations just so I could decode JSON isn't exactly convenient.

I think the solution posed to you is at least much better than what your comment thread started with: defining the entire JSON structure with Go types. Actually, I think it's a lot better. Personally, I'd probably stop there---even if I were prototyping.

But, at your insistence, we can keep digging. It's easy to write a polymorphic function that arbitrarily picks out values from a Go `interface{}` value.

    func lookup(v interface{}, keys ...string) interface{} {
    	switch len(keys) {
    	case 0: return v
    	default:
    		dict, ok := v.(map[string]interface{})
    		if !ok {
    			panic(fmt.Sprintf("%T is not a dictionary", v))
    		}
    		return lookup(dict[keys[0]], keys[1:]...)
    	}
    }

And then we can use it like you would in Python:

    lookup(response, "level_one", "level_two", "eventual_value")

This doesn't completely remove the burden of type asserting (unfortunate), but it at least makes nested lookups much easier. Arguably, the nested lookups are probably where the type asserts hurt the most.

Full example: http://play.golang.org/p/4tWtqGRgU6

Lines of code in type declarations isn't an interesting metric. Type safety, however, is.

Said otherwise, the python oneliner is likely not what you want, in real life you'd have to check for fields existence, purpose defaults or warn, etc. So you must likely end up with a few kings of code anyways.

Context of this thread is prototyping. For prototyping that one-liner is exactly what you want; if the fields don't exist just dump a stack trace and fix your code to use stuff that does exist.

The use-case for dynamic typing was that I was decoding a large JSON data structure that could easily have thousands of different fields nested 10+ levels deep.

Yeah, prototyping with JSON is one place where dynamic languages are more nimble.

For example, the Python bindings to Amazon S3 let you access files through dictionary notation. BeautifulSoup lets you iterate over child nodes with a for loop, or access attributes as a dict. NumPy lets you use standard arithmetic operators on matrices. Judicious use of this in libraries makes the resulting code much briefer.

Yes, this is another specific area where dynamic languages do prototyping better and can produce shorter code. I did an exercise where someone implemented a routine in Clojure that I had written in Python. The Python was shorter! In part, this was due to list comprehensions. In part, it was due to an excellent library. What you describe is what many Smalltalkers did as well: create your own control structures and DSLs.

I've sometimes wondered what could be done with a dynamic superset language of Go, such that one could mostly add type definitions and compile to Go.

My biggest pain when programming servers in Go is when handling others' dynamic JSON. Multiple levels of switch-case to handle different types for the same JSON fields at different times. With the current eco systems, Objective C seems the best language, dynamic typing with optional static typing, or mostly static typing in the programs, with dynamic typing for cases like handling dynamic data. Other goods include ARC, Xcode, Apple's frameworks, etc. Concurrency seems to work well with dispatch queues etc. I wonder if Objective C could be as good as Go for servers.

My biggest pain when programming servers in Go is when handling others' dynamic JSON.

It should be simple enough to implement a dynamic JSON parsing DSL in Go. It would be slower and memory inefficient, but much more convenient for rapid development.

Apple uses Java on its server-side.

Note on encoding/json: you only need to mention the fields you care about. If there are extra fields, the parser will just scan past them.

>A lot of the advantage of Go is what it doesn't have. It's a much simpler system, so it's easier to design around, especially as one needs to get closer to the metal.

Go doesn't have a REPL and that is objectively a serious dent on effective prototyping.

The availible go ide's are still young but go includes a lot of really nice tooling in the core distribution. The gofmt tool enforces a canonical format for go code and I have sublime text set up (via gosublime) to reformat on save and use the gocode autocomplete/linting daemnon.

Gofmt is actually one of my favorite parts about go and I feel that it, along with the simple documentation system and godoc.org save me a ton of time making my code ready for others to read/use.

The code base behind gofmt and gofix can also be used for other tools, i haven't felt the need for a powerful refactoring tool but I'm sure one will show up eventually.

I do miss list comprehensions and operator overloading but I understand the dev's arguments against those.

There is actually a decent open source, third party Go plugin for Intellij that works pretty well. Our team has been using it successfully on a fairly large project.

It's slightly annoying to setup, but absolutely worth it.

Doesn't Go come with an executable that reformats .go files to a canonical format?

That's the gofmt tool that we're all talking about.

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)

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;
  }

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

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.

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

They're actually not required in Go.

And you don't need the semicolons!

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.

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.

As the_paul said, this is incorrect.

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

This is not true.

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

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.

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.

I also rewrote a tornado service in Go. The thing I found most surprising was that the length of the program was about the same as the Python version. I had expected it to be quite a bit longer.

Is there a book or tutorial or blog you would recommend for a Python person to learn Go? I'm certainly interested in what your thoughts are.

Here's a few links you might find helpful. They're not specific to Python developers, though.

http://www.golang-book.com/

http://www.golangbootcamp.com/book

http://talks.golang.org/2012

https://gobyexample.com/

I wrote about my experience here:

http://blog.repustate.com/migrating-code-from-python-to-gola...

Sure - I actually gave a talk last year on this exact topic. There's an audio recording somewhere, but here's the repository for the slides (which contains a link to the PDF): https://github.com/ChimeraCoder/go-for-pythonists

How does Go makes it easy to scale the maintenance of software?

Would you please expand on [2] please with concrete examples.