Examples of beautiful Go?

http://programmers.stackexchange.com/q/82179/19141

by riyadparvez • 13 years ago

67 43 13 years ago

programmers.stackexchange.com

voidlogic3• 13 years ago

"Because of that, I'm having trouble persuading myself that Go is much more expressive than competitors" Beauty is in the eye of the beholder. While one programmer might say beautiful code is expressiveness (ex. performing a one liner quick sort), that is not what most Go developers I know see as beauty. Beautiful Go in my opinion is code that (in increasing importance):

  1. runs fast
  2. uses little memory
  3. is easily made (or is) concurrent / parallel
  4. is transparent (the intuitive run time complexity of operations is apparent, no hidden O(n..) operations, etc)
  5. is easy to maintain

If this code happens to be more verbose than say Java, so be it, it is still beautiful. On an anecdotal note, most large C++, Java and node.js projects I have ported to Go have ended up being fewer LOC in Go.

melling• 13 years ago

How does a Go solution compare to a Perl, Python, or Ruby solution? The latter languages offer quick solutions to problems but they don't often scale to large projects built by large teams.

jweir2• 13 years ago

Binary builds are one advantage. Compile your go application and deploy it. No need to also install Ruby, gems etc.

You can cross compile as well. IE compile for Linux from OS X.

http://dave.cheney.net/2012/09/08/an-introduction-to-cross-c...

pekk• 13 years ago

This kind of free-floating opinion, unsupported by evidence or even details, is worse than useless. It's a waste of time masquerading as content.

What is the basis for your claim? That it's impossible to build large projects without static typing, or what?

voidlogic3• 13 years ago

Pretty much like you would expect, the Go code is a bit longer but much more efficient at runtime; similar to what you see at the benchmark game: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t... Note: That graph is using go 1.0.3 not Go tip which is even faster.

I do believe the Go code is more maintainable and I like the fact it is statically typed.

chimeracoder2• 13 years ago

Go fmt is my single favorite feature about the language.

Coming from a background in Lisp, I don't find much in Go that seems very 'elegant' or 'beautiful'. What I find is that everything - including the Go source code itself - is perfectly standardized (and therefore immediately readable).

I don't have to worry about different coding styles, about semicolons vs. no semicolons[0], about having more than one way to express the same code. I can skim the code easily because the structure is so uniform across all standard and community libraries.

That's a different kind of beauty from chaining macros and cons cells, but it's beautiful nonetheless.

[0]https://github.com/twitter/bootstrap/issues/3057

jweir2• 13 years ago

Not only does gofmt make the code consistent for people, it makes it machine consistent. Once the code is "fmted" parsing, replacing, etc is simple.

Which, btw, gofmt does does pattern replacement.

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

NateDad2• 13 years ago

There's a parser in the standard library that makes parsing Go code simple (regardless of format). This is actually what gofmt uses, I believe.

shurcooL• 13 years ago

The pattern replacing is awesome. It can do a lot of refactoring.

http://talks.godoc.org/github.com/sunfmin/talks/2013/gofmt.s...

jgrahamc• 13 years ago

To a certain extent the question is not correct. Go was not designed to be beautiful, it was design to be readable. So the code can look quite pedestrian (e.g. for { } loops where other languages might have other constructs).

I believe this to be a win because learning and writing the language are fast. There are some nice 'a ha' moments (such as when you understand interfaces), but mostly the code is (in a good way) boring.

It's also a small language. I think it was designed for people who want to get things done, not for people who want to find the cleverest (i.e. least-number-of-characters) way of doing it.

The way concurrency is built into the language (based on sequential programming with channel based communication) further reduces the potential complexity. You just write sequential code and let the Go runtime handle the rest.

randomdata• 13 years ago

Beauty is inherently linked to readability, at least in my opinion.

If you look at typesetting, a lot of care is taken to tweak letter spacings and getting the font just right. This makes the work easier to read than a giant wall of text, and visual beauty comes as a natural side effect of that optimization.

Code really isn't any different. While there is certainly some variance by the beholder, code that is generally easy to read is going to naturally look beautiful. Additionally, and perhaps more importantly, if the code is beautiful, it will attract you to maintain it.

I am still a Go newbie, but my initial impression is that certain constructs make it more difficult to write beautifully than it should, which only serves to detract from the readability (not talking clever one-liners here – which shouldn't even come up in beauty discussions). However, given that I am new to the language, I may just not be yet able to express things as well as I could.

jbooth2• 13 years ago

Coding is completely different from typesetting, otherwise we wouldn't all be using monospace fonts.

Beauty's more subjective than readability, but most of the time a beautiful, elegant, recursive structure takes more time to figure out than your ho-hum for loop, in my experience at least.

blablabla123• 13 years ago

>I am still a Go newbie, but my initial impression is that certain constructs make it more difficult to write beautifully than it should, which only serves to detract from the readability (not talking clever one-liners here – which shouldn't even come up in beauty discussions). However, given that I am new to the language, I may just not be yet able to express things as well as I could.

It depends very much on what you want to write. If you want to write something related with File I/O or Network I/O in a reliable fashion, chances are that you cannot see it more beautifully implemented than in Go. No big surprise, the language designers are known for being involved in a lot of Unix stuff.

On the other hand, if you want to implement a linear algebra package that has support for a lot of structures, you will see less beautiful code. The same is somehow true for a number of algorithms that act on collections. There are no templates, so you either Copy&Paste or you work with interface{} worst case, meaning such code is cluttered with type assertions.

But besides that, I think most Go code can be made beautiful. It definitely has its sweet spot in Server Programming.

rwj• 13 years ago

Conciseness was not a goal. Simplicity and regularity were. IN this case, beauty is in the eye of the beholder.

eric9702• 13 years ago

Agreed.

mortdeus2• 13 years ago

Omg ruby is so much better. K thnx bye.

eric9702• 13 years ago

LOL. I know this is a joke, but I'm actually a ruby dev myself diving into Go. I find it to complement Ruby extremely well. Both have their strengths and weaknesses.

mortdeus2• 13 years ago

Sorry didnt think this post had enough troll in it to qualify as an authentic go discussion.

munificent2• 13 years ago

Caveat: lots of subjectivity here.

My impression is that Go and Lisp are similar here. Neither is particularly pleasant to read in the small. Lisp because of all of the parens and the sometimes "backwards" dataflow of nested functions. Go because of the "imperativeness", the frequent manual returns for errors, the mandatory {} for blocks.

In both cases, that was a deliberate choice in order to get simple syntax. The beauty they are focused on is larger-scale beautiful semantics. Lisp with macros, first-class functions, etc. Go with interfaces, goroutines, and channels.

Where some languages treat the syntax as a first-class feature, I think Go and Lisp treat it more as a means to an end. That being said, in both cases, practitioners of those languages do specifically like their syntaxes. It's just not a major focus of the language designers' time.

bitops• 13 years ago

> Lisp because of all of the parens and the sometimes "backwards" dataflow of nested functions.

I've come to believe that the second part of this statement really is the primary reason why Lisp drives some people absolutely nuts. The parens are really just a distraction and "easy" justification for not liking the language.

It makes sense, though. When you have to read both "outside in" and "bottom up", a lot of your acquired reading abilities (left to right, top to bottom) are in tension with the code you're trying to understand.

At least in Clojure, the ->> family of operators ("threading" macros) are doing a good job helping to alleviate this. Maybe they're available in other Lisps, I don't know.

EDIT: found a reference to these macros in Emacs Lisp: http://emacswiki.org/emacs/ThreadMacroFromClojure

munificent2• 13 years ago

> I've come to believe that the second part of this statement really is the primary reason why Lisp drives some people absolutely nuts.

Agreed. This is a major reason why Lisps read wrong to me and is one of my favorite things about conventional subject.verb(object) syntax in OOP languages.

My own language[1] has Lisp-like semantics where methods are lexically-scoped and not attached to classes but retains something close to OOP syntax because I think that's such a readability win. For me, this is the best of both worlds.

[1] http://magpie-lang.org/multimethods.html

Examples of beautiful Go?

Related Stories