11 ms·

Examples of beautiful Go?

67 points by riyadparvez 14y ago

voidlogic 14y 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 14y 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.
  - jweir 14y 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-compilation-with-go http://dave.cheney.net/2012/09/08/an-introduction-to-cross-c...
    - icebraining 14y ago
      That's not necessarily an advantage. E.g. PyInstaller can create stand-alone executables from Python packages. That said, it's certainly much cleaner to just build static binary executables like Go does.
    - danieldk 14y ago
      Imagine that Go were used to write most components on a system. One security vulnerability in one package and you don't replace just one library, you'll have to reroll every binary (or package if you are maintaining a Linux distribution). Also, since there is no version management in Go packaging, you better hope that every program uses the API of the latest or fixed version.
      - burntsushi 14y ago
        > Imagine that Go were used to write most components on a system. One security vulnerability in one package and you don't replace just one library, you'll have to reroll every binary (or package if you are maintaining a Linux distribution). Imagine that a shared library were upgraded, and it contained a new vulnerability. This vulnerability now automatically exposes any program that uses said said library. Trade offs :-) (Compiling Go is fast. Re-rolling a binary isn't a Big Deal.) > Also, since there is no version management in Go packaging, you better hope that every program uses the API of the latest or fixed version. Simplicity has a price. But there's no reason why an external tool cannot be made to handle versioning.
        danieldk 14y ago
        Imagine that a shared library were upgraded, and it contained a new vulnerability. This vulnerability now automatically exposes any program that uses said said library. Production systems normally only replace shared libraries to fix vulnerabilities. So, that's a non-argument. On non-production systems, it's far easier to replace one vulnerable library, than tens of vulnerable Go programs. That is, if you know which Go program was using what version of that package again.
        dscrd 14y ago
        "far easier" only because there's a huge infrastructure in the package manager that has been built over several years. And it does not always work, even though these days it most often does.
        burntsushi 14y ago
  - pekk 14y 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?
    - pjmlp 14y ago
      Based on my experience yes. I work in enterprise projects done in multi-site context context, usually with teams that encompass more than 30 developers with multiple levels of experience. Depending on the customer, sometimes it is very hard to force developers to write unit tests. If the customer does not care about them, the product manager will not enforce them. Additionally given the lack of experiences of the junior developers, always chosen because they are cheaper to the customer, unit tests tend to be badly written. So with static typing one has at least a guarantee that the product compiles and might eventually even run. With dynamic typing and lack of tests, you can spend days getting the product back into a runnable state.
  - voidlogic 14y 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?test=all&lang=go&lang2=python3 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.
    - aleyan 14y ago
      Go is quite a bit faster and memory efficient than Python3? No unexpected. Curious how it stacks up with PyPy. Looking at the Benchmark Game Go vs Java7[0], why is Java 2x to 8x faster than Go for many benchmarks? Is the jvm that optimized these days or are those Java7 programs super tweaked for performance? [0] http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=go&lang2=java http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...
      - Ziomislaw 14y ago
        jvm is really fast, it can usually compete with C++ code in terms of speed (if you ignore the startup time ;p )
        voidlogic 14y ago
        The JVM is really fast- but to be fair note the JVMs memory usage in that comparison. Also version of Go used in that comparison is Go 1.0.3 and Go 1.1 RC (which is much faster and has better garbage collection) is going to be out next month. Go is a very young language so while very fast compared to an interpreted language like Ruby, Python, etc by virtue of being compiled, it going to take some time be be on par (in terms of execution speed) with a Java, a JIT language that has had 18 years to mature. It says a lot for Go that its execution time is on par with C#: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=go&lang2=csharp http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...
chimeracoder 14y 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 https://github.com/twitter/bootstrap/issues/3057
- jweir 14y 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/ http://golang.org/cmd/gofmt/
  - NateDad 14y 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.
    - 4ad 14y ago
      You are correct. I'll also add that consistent formatting provides an excellent aid for grepping. Sometimes you want to search for code in the standard library that does something similar to what you do, or you are looking for a specific idiom. Consistent formatting helps making a simple regular expression pretty exhaustive. Combined with structural regular expressions you can answer questions like "what are the types that contain both a mutex and a map, and what are the types that contain the types that use a map without a mutex": http://pastebin.ca/2202690 http://pastebin.ca/2202690
  - shurcooL 14y ago
jgrahamc 14y 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 14y 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.
  - jbooth 14y 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.
    - 14y ago
deleted 14y ago
[deleted]
rwj 14y ago
Conciseness was not a goal. Simplicity and regularity were. IN this case, beauty is in the eye of the beholder.
- eric970 14y ago
  Agreed.
mortdeus 14y ago
Omg ruby is so much better. K thnx bye.
- eric970 14y 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.
mortdeus 14y ago
Sorry didnt think this post had enough troll in it to qualify as an authentic go discussion.
munificent 14y 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 14y 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 http://emacswiki.org/emacs/ThreadMacroFromClojure
  - munificent 14y 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 http://magpie-lang.org/multimethods.html

67 points by riyadparvez 14y 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 14y 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.
- jweir 14y 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-compilation-with-go http://dave.cheney.net/2012/09/08/an-introduction-to-cross-c...
  - icebraining 14y ago
    That's not necessarily an advantage. E.g. PyInstaller can create stand-alone executables from Python packages. That said, it's certainly much cleaner to just build static binary executables like Go does.
  - danieldk 14y ago
    Imagine that Go were used to write most components on a system. One security vulnerability in one package and you don't replace just one library, you'll have to reroll every binary (or package if you are maintaining a Linux distribution). Also, since there is no version management in Go packaging, you better hope that every program uses the API of the latest or fixed version.
    - burntsushi 14y ago
      > Imagine that Go were used to write most components on a system. One security vulnerability in one package and you don't replace just one library, you'll have to reroll every binary (or package if you are maintaining a Linux distribution). Imagine that a shared library were upgraded, and it contained a new vulnerability. This vulnerability now automatically exposes any program that uses said said library. Trade offs :-) (Compiling Go is fast. Re-rolling a binary isn't a Big Deal.) > Also, since there is no version management in Go packaging, you better hope that every program uses the API of the latest or fixed version. Simplicity has a price. But there's no reason why an external tool cannot be made to handle versioning.
      - danieldk 14y ago
        Imagine that a shared library were upgraded, and it contained a new vulnerability. This vulnerability now automatically exposes any program that uses said said library. Production systems normally only replace shared libraries to fix vulnerabilities. So, that's a non-argument. On non-production systems, it's far easier to replace one vulnerable library, than tens of vulnerable Go programs. That is, if you know which Go program was using what version of that package again.
        dscrd 14y ago
        "far easier" only because there's a huge infrastructure in the package manager that has been built over several years. And it does not always work, even though these days it most often does.
        burntsushi 14y ago
- pekk 14y 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?
  - pjmlp 14y ago
    Based on my experience yes. I work in enterprise projects done in multi-site context context, usually with teams that encompass more than 30 developers with multiple levels of experience. Depending on the customer, sometimes it is very hard to force developers to write unit tests. If the customer does not care about them, the product manager will not enforce them. Additionally given the lack of experiences of the junior developers, always chosen because they are cheaper to the customer, unit tests tend to be badly written. So with static typing one has at least a guarantee that the product compiles and might eventually even run. With dynamic typing and lack of tests, you can spend days getting the product back into a runnable state.
- voidlogic 14y 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?test=all&lang=go&lang2=python3 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.
  - aleyan 14y ago
    Go is quite a bit faster and memory efficient than Python3? No unexpected. Curious how it stacks up with PyPy. Looking at the Benchmark Game Go vs Java7[0], why is Java 2x to 8x faster than Go for many benchmarks? Is the jvm that optimized these days or are those Java7 programs super tweaked for performance? [0] http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=go&lang2=java http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...
    - Ziomislaw 14y ago
      jvm is really fast, it can usually compete with C++ code in terms of speed (if you ignore the startup time ;p )
      - voidlogic 14y ago
        The JVM is really fast- but to be fair note the JVMs memory usage in that comparison. Also version of Go used in that comparison is Go 1.0.3 and Go 1.1 RC (which is much faster and has better garbage collection) is going to be out next month. Go is a very young language so while very fast compared to an interpreted language like Ruby, Python, etc by virtue of being compiled, it going to take some time be be on par (in terms of execution speed) with a Java, a JIT language that has had 18 years to mature. It says a lot for Go that its execution time is on par with C#: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=go&lang2=csharp http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...

chimeracoder 14y 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 https://github.com/twitter/bootstrap/issues/3057

jweir 14y 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/ http://golang.org/cmd/gofmt/
- NateDad 14y 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.
  - 4ad 14y ago
    You are correct. I'll also add that consistent formatting provides an excellent aid for grepping. Sometimes you want to search for code in the standard library that does something similar to what you do, or you are looking for a specific idiom. Consistent formatting helps making a simple regular expression pretty exhaustive. Combined with structural regular expressions you can answer questions like "what are the types that contain both a mutex and a map, and what are the types that contain the types that use a map without a mutex": http://pastebin.ca/2202690 http://pastebin.ca/2202690
- shurcooL 14y ago

jgrahamc 14y 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 14y 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.
- jbooth 14y 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.
  - 14y ago

deleted 14y ago

[deleted]

rwj 14y ago

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

eric970 14y ago
Agreed.

mortdeus 14y ago

Omg ruby is so much better. K thnx bye.

eric970 14y 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.

mortdeus 14y ago

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

munificent 14y 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 14y 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 http://emacswiki.org/emacs/ThreadMacroFromClojure
- munificent 14y 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 http://magpie-lang.org/multimethods.html