8 ms·

My Perspective on Go

52 points by zhenjl 12y ago

yawaramin 12y ago
To me that criticism you quoted seems really misguided. A person who doesn't want to see performance measures from new users will never understand how they (the new users) are typically using the language and where the most common performance blocks are at the newbie stage.
- chimeracoder 12y ago
  It's important to understand how new users are using the language, but new users of the language should not be focusing on performance before they learn the language well enough to know what is idiomatic and what is not, which was the original criticism. The criticism is well-grounded: it's rather tiring to see endless "performance benchmarks" that test little more than printing to the console[0], or create artificial programs that are direct line-for-line translations of another language, and don't represent what an actual developer would generally write. Think of it as a from of premature optimization - literally. [0] Not in Go, but I can't count the number of times I've seen people use these comparisons for languages like Python and Ruby. It's incredibly ironic, because these languages really just farm out to the same underlying C libraries for this functionality, so it's testing something, but not really the performance of the actual language features.
  - yawaramin 12y ago
    It's important to understand how new users are using the language, but new users of the language should not be focusing on performance before they learn the language well enough to know what is idiomatic and what is not, ... See, that's a chicken-and-egg problem. This was my original point. How do you come to understand how new users are using your language and where they're taking performance hits if you keep telling them not to try to write performant code?
    - chimeracoder 12y ago
      First you teach them how to write idiomatic code (non-performant), and then you teach them how to make the idiomatic code more performant. It's very common for new users (in any language, not just Go) to try to jump right to the end, but focusing on performance before understanding basic language building blocks is a recipe for frustration, both for the new users and for the language designers.
VeejayRampay 12y ago
"I haven’t used this extensively, but in my attempt to optimize the integer compression library, I added different C and assembly snippets to try to squeeze the last ounce of performance out of Go. It was fairly easy and straightforward to do." Ah, the famous integer compression library modifying non-programmer :)
- jfaucett 12y ago
  haha. I think the title should read, "Go: From a Non-Programming,Masters in Computer Science,7 years penetration testing, quite proficient in Pascal-C-Perl-PHP-Java-JavaScript, high performance MQTT broker implementing total Noobie Perspective"
duvander 12y ago
Just a non-programmer with a masters in Computer Science...
- 0xdeadbeefbabe 12y ago
  And for being non-technical he's good at technical writing. Could this be a case of anti-pride?
  - dummyfellow 12y ago
    or may be he doesn't like fixing friend and family computers, so claims to be non-technical.
- dang 12y ago
  We've taken "non-programmer" out of the title and replaced it with a phrase from the article.
bascule 12y ago
"For me personally, I don’t know any better. I have never used generics and I haven’t found a situation where I strongly require it." Sounds an awful lot like http://c2.com/cgi/wiki?BlubParadox http://c2.com/cgi/wiki?BlubParadox
- pron 12y ago
  No, because language features aren't a la carte, and when you pick a language can only weigh the combined pros and cons of each package deal. In fact, in many cases where the "Blub Paradox" card is played, that's actually what's happening: one language might be "linguistically" more powerful but another has better performance, or better monitoring, or a larger variety of available libraries, or even a specific library that you absolutely need. It is true that some languages can theoretically be categorically better than others (or, at least for certain domains), but in practice that usually applies to the compiler (i.e. the language itself) alone, and rarely to the entire ecosystem. Also, I find that people tend to vastly exaggerate the impact a specific language feature has over total productivity.
- Retra 12y ago
  I've found that generics are really only 'necessary' for building libraries. If you are writing applications or utilities, then you probably don't need it very much.
  - emsy 12y ago
    Generics aren't necessary at all, but they are a powerful addition to the means of expression a language offers and have use cases beyond collections. So while it's not a deal breaker, it's definitely sad and hard to understand why they left them out. Especially when you know Java's history and the pain they went through when they finally added generics.
    - Retra 12y ago
      Yeah, true. I feel disappointed whenever anybody tries to tack generics onto an existing language. You can never really tell if it is done correctly or not.
rakoo 12y ago
> Unlike other languages where you can just create a directory and get started, Go wants you to put things in $GOPATH. I've seen this complaint a lot and don't agree with it. Go just want everything to be accessible through $GOPATH, it doesn't have to _be_ there. Here's how I organize my code: - I have all my dev in ~/dev. Anything goes here, whether it's go, ruby,... it's my workspace - I put $GOPATH where it should be, in ~/.local/share/go - Whenever I need to go get something, it ends up in ~/.local/share/go/src/domain.com/author/package, as expected - When I need my package to be in $GOPATH, I just symlink ~/dev/project to ~/.local/share/go/src/github.com/rakoo/project, so it is visible in $GOPATH After that everything works as expected (modulo some minor quirks I have to do at go install time), and you don't have to have a specific workspace just for go. It's also minimal enough (once per new project) that I'm not too bothered by it.
- zzzcpan 12y ago
  I don't think you are being realistic. It is a significant additional effort that other languages typically free you from. Not a big problem though, we can write our own tools.
  - rakoo 12y ago
    It's only a symlink you create at the start of a new project (not even each package, each _project_), it's really not heavy. An additional step compared to other projects, but overall the cost of managing dependencies is still lower.
- falcolas 12y ago
  Even easier: just put your files in a directory and run 'go build' in that directory. If you have libraries, put them down lib/lib_name/lib_name.go, and your build from the root directory will work fine. The compiled lib files will not be in your current directory, but that's usually OK. For a working example, have a look at the logstash-forwarder code structure, it's how they do it, and you can build that from any directory you want. And if you really want to set up go path in your current directory, use a make file and set up a target with 'env GOPATH=$(pwd) go install'
cdelsolar 12y ago
Is it true what he is saying about a single binary? Go doesn't do dynamic linking?
- yebyen 12y ago
  Yes. Go binaries are statically linked and thus portable[1] without dependencies. [1]in the sense of being self-contained, not architecture-independent.
- landr0id 12y ago
  Currently Go only statically links libraries. I thought I read in one of the roadmaps that they want to do dynamic linking down the line but I cannot seem to find that source anymore.
- falcolas 12y ago
  Yes and no. Pure go libraries are statically linked, but if you run 'psof' on a running go process on Linux, you will see open file handles to some shared libraries.
wcummings 12y ago
>In a way, I consider that to be an advantage coming in to a new programming language, in that I have no preconceived notion of how things “SHOULD” be. I can learn the language and use the constructs as they were intended, and not have to question WHY it was designed that way because it’s different than what I know. >I just could not get my non-functional mind to wrap around the functional Scala. And since I really didn’t need to code (nor the developers want me to), I gave up on learning Scala. >I’ve barely heard of generics, communicating sequential processes, and other “cool” and “advanced” concepts. Emphasis added

52 points by zhenjl 12y ago

To me that criticism you quoted seems really misguided. A person who doesn't want to see performance measures from new users will never understand how they (the new users) are typically using the language and where the most common performance blocks are at the newbie stage.

chimeracoder 12y ago
It's important to understand how new users are using the language, but new users of the language should not be focusing on performance before they learn the language well enough to know what is idiomatic and what is not, which was the original criticism. The criticism is well-grounded: it's rather tiring to see endless "performance benchmarks" that test little more than printing to the console[0], or create artificial programs that are direct line-for-line translations of another language, and don't represent what an actual developer would generally write. Think of it as a from of premature optimization - literally. [0] Not in Go, but I can't count the number of times I've seen people use these comparisons for languages like Python and Ruby. It's incredibly ironic, because these languages really just farm out to the same underlying C libraries for this functionality, so it's testing something, but not really the performance of the actual language features.
- yawaramin 12y ago
  It's important to understand how new users are using the language, but new users of the language should not be focusing on performance before they learn the language well enough to know what is idiomatic and what is not, ... See, that's a chicken-and-egg problem. This was my original point. How do you come to understand how new users are using your language and where they're taking performance hits if you keep telling them not to try to write performant code?
  - chimeracoder 12y ago
    First you teach them how to write idiomatic code (non-performant), and then you teach them how to make the idiomatic code more performant. It's very common for new users (in any language, not just Go) to try to jump right to the end, but focusing on performance before understanding basic language building blocks is a recipe for frustration, both for the new users and for the language designers.

VeejayRampay 12y ago

"I haven’t used this extensively, but in my attempt to optimize the integer compression library, I added different C and assembly snippets to try to squeeze the last ounce of performance out of Go. It was fairly easy and straightforward to do." Ah, the famous integer compression library modifying non-programmer :)

jfaucett 12y ago
haha. I think the title should read, "Go: From a Non-Programming,Masters in Computer Science,7 years penetration testing, quite proficient in Pascal-C-Perl-PHP-Java-JavaScript, high performance MQTT broker implementing total Noobie Perspective"

duvander 12y ago

Just a non-programmer with a masters in Computer Science...

0xdeadbeefbabe 12y ago
And for being non-technical he's good at technical writing. Could this be a case of anti-pride?
- dummyfellow 12y ago
  or may be he doesn't like fixing friend and family computers, so claims to be non-technical.
dang 12y ago
We've taken "non-programmer" out of the title and replaced it with a phrase from the article.

bascule 12y ago

"For me personally, I don’t know any better. I have never used generics and I haven’t found a situation where I strongly require it." Sounds an awful lot like http://c2.com/cgi/wiki?BlubParadox http://c2.com/cgi/wiki?BlubParadox

pron 12y ago
No, because language features aren't a la carte, and when you pick a language can only weigh the combined pros and cons of each package deal. In fact, in many cases where the "Blub Paradox" card is played, that's actually what's happening: one language might be "linguistically" more powerful but another has better performance, or better monitoring, or a larger variety of available libraries, or even a specific library that you absolutely need. It is true that some languages can theoretically be categorically better than others (or, at least for certain domains), but in practice that usually applies to the compiler (i.e. the language itself) alone, and rarely to the entire ecosystem. Also, I find that people tend to vastly exaggerate the impact a specific language feature has over total productivity.
Retra 12y ago
I've found that generics are really only 'necessary' for building libraries. If you are writing applications or utilities, then you probably don't need it very much.
- emsy 12y ago
  Generics aren't necessary at all, but they are a powerful addition to the means of expression a language offers and have use cases beyond collections. So while it's not a deal breaker, it's definitely sad and hard to understand why they left them out. Especially when you know Java's history and the pain they went through when they finally added generics.
  - Retra 12y ago
    Yeah, true. I feel disappointed whenever anybody tries to tack generics onto an existing language. You can never really tell if it is done correctly or not.

rakoo 12y ago

> Unlike other languages where you can just create a directory and get started, Go wants you to put things in $GOPATH. I've seen this complaint a lot and don't agree with it. Go just want everything to be accessible through $GOPATH, it doesn't have to _be_ there. Here's how I organize my code: - I have all my dev in ~/dev. Anything goes here, whether it's go, ruby,... it's my workspace - I put $GOPATH where it should be, in ~/.local/share/go - Whenever I need to go get something, it ends up in ~/.local/share/go/src/domain.com/author/package, as expected - When I need my package to be in $GOPATH, I just symlink ~/dev/project to ~/.local/share/go/src/github.com/rakoo/project, so it is visible in $GOPATH After that everything works as expected (modulo some minor quirks I have to do at go install time), and you don't have to have a specific workspace just for go. It's also minimal enough (once per new project) that I'm not too bothered by it.

zzzcpan 12y ago
I don't think you are being realistic. It is a significant additional effort that other languages typically free you from. Not a big problem though, we can write our own tools.
- rakoo 12y ago
  It's only a symlink you create at the start of a new project (not even each package, each _project_), it's really not heavy. An additional step compared to other projects, but overall the cost of managing dependencies is still lower.
falcolas 12y ago
Even easier: just put your files in a directory and run 'go build' in that directory. If you have libraries, put them down lib/lib_name/lib_name.go, and your build from the root directory will work fine. The compiled lib files will not be in your current directory, but that's usually OK. For a working example, have a look at the logstash-forwarder code structure, it's how they do it, and you can build that from any directory you want. And if you really want to set up go path in your current directory, use a make file and set up a target with 'env GOPATH=$(pwd) go install'

cdelsolar 12y ago

Is it true what he is saying about a single binary? Go doesn't do dynamic linking?

yebyen 12y ago
Yes. Go binaries are statically linked and thus portable[1] without dependencies. [1]in the sense of being self-contained, not architecture-independent.
landr0id 12y ago
Currently Go only statically links libraries. I thought I read in one of the roadmaps that they want to do dynamic linking down the line but I cannot seem to find that source anymore.
falcolas 12y ago
Yes and no. Pure go libraries are statically linked, but if you run 'psof' on a running go process on Linux, you will see open file handles to some shared libraries.

wcummings 12y ago

>In a way, I consider that to be an advantage coming in to a new programming language, in that I have no preconceived notion of how things “SHOULD” be. I can learn the language and use the constructs as they were intended, and not have to question WHY it was designed that way because it’s different than what I know. >I just could not get my non-functional mind to wrap around the functional Scala. And since I really didn’t need to code (nor the developers want me to), I gave up on learning Scala. >I’ve barely heard of generics, communicating sequential processes, and other “cool” and “advanced” concepts. Emphasis added