Hacker News Reader

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.

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.

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.

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.

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

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.

> 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.

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.

    >  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.

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.

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

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.

Apple uses Java on its server-side.

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.

>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.