Things I Love About Go

http://www.cambus.net/things-i-love-about-go/

by fcambus • 14 years ago

55 54 14 years ago

A lot of these are simply the Go people declaring certain conventions by fiat: gofmt, the go build tool, a large standard library, and the like.

These are a lot of the benefits that Python had: everybody pretty much has to do things the same way (and there's PEP 8 that establishes non-enforced conventions), so I can start playing with a new codebase without having to figure out their conventions and build system too.

drivebyacct26• 14 years ago

It's unbelievable how helpful it is. The Go article that was posted last week was lambasted for a lot of good reasons, but even as a Go fan I was annoyed at how hard it was for me to quickly scan the source because it didn't follow the conventions that I'm used to staring at quickly.

acomjean• 14 years ago

Go seems like a rehash of Ada, without the option to dynamically linked. Maybe an improved version of Ada.

I liked some feature of Ada a lot, it was safe, input, output, in/out parameters for functions. Of course to make itself useful as a lower level language you need to be able to call OS functions, which in unix means C. So then you have to start wrapping... Some parts of Ada were terrible (string handling comes to mind.)

I think its worth a look, but I'm still not sure what problem its trying to solve.

Peaker12• 14 years ago

Go repeats the mistake of Boolean Blindness [1] so I think it disqualifies it from "safe", though.

[1] http://existentialtype.wordpress.com/2011/03/15/boolean-blin...

drivebyacct26• 14 years ago

You posted this a few days ago, I didn't understand it and still don't understand after another read through. Can you give either a dumbed down summary or a scenario or an example of a language that doesn't do this?

ralph3• 14 years ago

Sorry, but having had some dealings with Ada many years ago I'm sure Go is little like it. Go has CSP in its ancestry, what with channels and goroutines, and both are fundamental to it whereas Ada has nothing similar?

pjmlp3• 14 years ago

Goroutines -> tasks

channels -> rendezvous

pjmlp3• 14 years ago

> Go seems like a rehash of Ada, without the option to dynamically linked. Maybe an improved version of Ada.

Go has more in common with Oberon and Component Pascal than Ada

Hominem2• 14 years ago

There are some neat things about it. Being able to retroactively distill an interface from code you do not have the source to. Sometimes I wish I could do this in c# when I mock stuff up.

Goroutines and channels are cool because they are simple to use. We have tasks in c# and I could construct channels in countless ways. But go makes them dirt simple.

I don't like the terse c-like naming conventions but that is a manner of taste. Makes it feel more close to the metal and less enterprisey I guess.

I wish there was go#

rwj• 14 years ago

I definitely agree with your comment about interfaces. This appears to be a concept that could be transplanted to C++, and would help quite a bit. Often in C++, people rely on template (compile-time polymorphism) because it is not possible to retroactively use interfaces (run-time polymorphism).

dsymonds• 14 years ago

"less enterprisey" is a feature.

Hominem2• 14 years ago

Yeah I'm guessing that is why they went that direction. It really isn't any less enterprisey than anything else and we ended up with stuff like fmt.printf, who would have guessed printf is in something called fmt. Well I guess it stands for format, but is printf primarily a formatting function? It prints and the formatting is a convenience. If we are meant to use it for formatting, it is badly named.

jbert3• 14 years ago

I'm learning a bit of go at the moment, and liking it a lot. One thing which caused me a little head scratching was doing something like this:

    for _, item := range slice_of_obj {
        item.update()
    }

where the 'update' method wrote to some member data in item.

It seems that the 'item' is a copy of, rather than an alias to, the underlying object, so the mutating 'update' call is updating the copy, which is then discarded. (The 'right way' to do this to use the loop index and slice_of_obj[i], but that seems mildly barbaric)

This seemed odd to me, particularly since no error was generated. Can anyone comment if I'm doing anything particularly dumb here? If Go had a concept of 'const', at least it could throw an error when you mutate the copy which is going to be discarded.

densh• 14 years ago

IMO The right way is to have a slice filled with pointers rather than bare structs: https://gist.github.com/2975397

Btw code that uses range will always be faster than alternative with for loop and indexing (obj[i]) as range-based code can be optimized by Go compiler not to perform any bound checks.

jbert3• 14 years ago

Yes, that works nicely, thanks. But sometimes (rarely) you do want a contiguous bunch of objects, rather than have the indirection.

I think ideally, it would work (as an alias) but if not, I think it should error. Or maybe this is a FAQ, with a good rationale, which I just haven't got to yet.

jgrahamc• 14 years ago

The effect you are seeing there is because the as it says in the documentation: "The iteration values are assigned to the respective iteration variables as in an assignment statement." So item is being assigned and because it's an obj and not a *obj you are getting a copy.

Whereas slice_of_obj[i] is accessing the element within the slice without a copy. One solution to this problem would be to store pointers in your slice instead of objects.

jbert3• 14 years ago

Thanks for the reply. I don't argue that it's not to spec, just that it seems not useful/a bit surprising.

Some other languages (e.g. perl and I think also java) choose to make the loop var an alias, rather than a copy, to allow mutation:

    for my $item (@items) {
        $item->frob; # Can happily mutate the item
    }

will work as it reads.

Nate75Sanders• 14 years ago

Statically linked binaries (No dependencies hell, easy to deploy in production)

Is this always this way? I'd be interested in a discussion on the pros/cons of this. Some are obvious, but I'm interested in a deep discussion.

Things I Love About Go

Related Stories