12 ms·

OK, I'll admit it. I've spent six months with Go. I keep waiting for the moment when I understand it, maybe even develop some enthusiasm for it, and reach Pike-

OK, I'll admit it. I've spent six months with Go. I keep waiting for the moment when I understand it, maybe even develop some enthusiasm for it, and reach Pike-enlightenment. And I pretty much hate the language. I feel like I'm writing in something that combines the worst weaknesses of Pascal and Java. In fact, Mark Dominus' comments about Java (http://blog.plover.com/prog/Java.html http://blog.plover.com/prog/Java.html ) approximate my experience Go far better than I would have guessed when I started the project I'm on. People who seem to be smart nevertheless keep talking it up... some not even as just a good tool but as their favorite language. So I'll ask: What is it I need to read/work through in order to at least "get" Go and really understand its strengths (whether or not I end up liking it)?

claystu 12y ago
What weaknesses of Pascal are being repeated in Go?
- lmm 12y ago
  There is no escape. The language thinks it knows better than you. The standard library is allowed to do things that your code isn't.
  - _ak 12y ago
    Like what? The standard library is no more special, other than where it resides in the filesystem. You can write C and assembly code as well and link it to your Go code. And I'm not talking about cgo, I mean [568][ac], the Plan 9 C compiler and assembler that come with Go.
    - lmm 12y ago
      I was thinking most obviously of generics. The go standard library is full of generic collections, but you're not allowed to use generics in your own code.
      - _ak 12y ago
        That's not the standard library, though.
      - claystu 12y ago
        It looks like free pascal has generics: http://www.freepascal.org/docs-html/ref/refch8.html#refse46.html http://www.freepascal.org/docs-html/ref/refch8.html#refse46.... But to your larger point, doesn't any non-programmable programming language exhibit the same weakness to some extent?
        lmm 12y ago
        Any language will have some "magic" things that are special-cased in the compiler - things like the basic integer datatypes, or the threading primitives - and probably a few more things that are implemented as C code (though if you're lucky this can be done in a "standard" way, through the language's FFI). But most of the standard library should be implemented in the language itself (look at e.g. the Java standard library, or the Python standard library. In a more coherent language like TCL, even language constructs may be written this way - e.g. "for" or "if" can be just ordinary methods. At the other extreme, PHP has the infamous T_PAAMAYIM_NEKUDOTAYIM, because a simple-seeming piece of syntax had to be special-cased in the parser). If the standard library authors kept feeling the need to step outside the language itself, that's a bad sign - it suggests the language is poorly suited to writing libraries in. But you're right that it's a question of degree rather than a binary thing.
    - pjmlp 12y ago
      > Like what? Maps, slices, the pre-defined functions. More powerful languages make no big distinction between user defined types and the language provided ones.
    - howeman 12y ago
      Actually, the c compiler just got deleted. https://groups.google.com/forum/#!topic/golang-codereviews/AfirOjUi6e4 https://groups.google.com/forum/#!topic/golang-codereviews/A...
ansible 12y ago
So I'll ask: What is it I need to read/work through in order to at least "get" Go and really understand its strengths (whether or not I end up liking it)? As discussed elsewhere on this page, Go is not the most feature-rich language out there. But it does have features that seem to help my solve my problems with a minimum amount of fuss. Like using interfaces liberally, instead of having to define classes. Having lexical closures is also nice. If you're not working on an application that can benefit from concurrency, you may not see all the benefits of Go either. What kind of problems were you trying to solve, and how did Go see heavyweight compared to how you'd solve the problem in some other language?
- wwweston 12y ago
  I like functions as first-class values and closures. If they weren't present, I might well have bailed months ago. :) And from various experiences doing OO with other languages, I can kindof buy that Go interfaces are often 80% of what you want. Most of what I've been working on is a Rest API. Here's an example of a problem that felt like it should be something for which I'd be able to write an abstraction to deal with, but turned out to be challenging, at least as a n00b: https://groups.google.com/forum/#!topic/golang-nuts/JhsiiGHQ2j4 https://groups.google.com/forum/#!topic/golang-nuts/JhsiiGHQ... (Incidentally, though I moved past my then really poor understanding of Go interfaces, I wasn't able to apply the respondent's answer or my new general knowledge to achieve the abstraction I was looking for, and settled for just grinding out the same code for the dozen entities/endpoints it applied to.) Concurrency: I suspect there's a bit that's hidden in some libraries we're using, and we may yet need to write our own code for some API requests that get processed offline, but I haven't had to explicitly write code for it yet. If you can think of a specific exercise that might serve to illustrate Go's outstanding concurrency strengths, I'd be interested to try it and compare efforts to another language or two.
  - ansible 12y ago
    (Incidentally, though I moved past my then really poor understanding of Go interfaces, I wasn't able to apply the respondent's answer or my new general knowledge to achieve the abstraction I was looking for, and settled for just grinding out the same code for the dozen entities/endpoints it applied to.) I definitely can't deny that using interfaces instead of regular OO classes takes some getting used to. Though I don't understand why you had to grind out duplicate code for all the entities / endpoints though. I hacked up things a bit to get it to run on the playground, but as Jesse McNelis wrote, just passing the pointer to foo worked for the code you wrote. http://play.golang.org/p/jNpK5CRBfv http://play.golang.org/p/jNpK5CRBfv
cft 12y ago
Go is the only language that allows one to write very scalable TCP servers fast (i mean development effot). The servers are almost as fast as C (i.e. 15x Python), but the development time is like Python.
- tlmr 12y ago
  What about Julia?
  - FraaJad 12y ago
    Yeah, what about Julia? which makes as much as sense as asking - What about R? - What about GNU DAP? - What about FORTRAN? for writing a TCP server.
- est 12y ago
  For the record, Go does not allow you to operate on fd, so some fine tuning TCP parameters does not happen unless you do reflection magic and use SysCall. Which is PITA compared to Python.
- threeseed 12y ago
  There are numerous options for writing very scalable TCP servers on the JVM e.g. Vertx. Then you have the option of using Java, Clojure, Scala, Ruby, Python, Javascript or Groovy languages.
cgag 12y ago
I don't think you're going to come around on it. It's not suddenly going to stop being terrible at abstraction. That essay seems very accurate and applies to Golang. The strengths of Go to me seem to be its extensive standard libary and the fact that you don't need to worry about writing elegant code because it's not really an option. That reduced decision making is actually really appealing to me on some level, but it's not enough for me to consider it over what I consider better tools (Haskell, Rust). I'm currently porting a tiny program a friend wrote in Go to Haskell so we can compare notes, and I think the Haskell is both safer and more elegant, but I'm jealous of the fact that all the libraries he used are from the standard library while I have to evaluate libs of varying quality. However, I would rather put my time in to improving the Haskell ecosystem than using something convenient that makes a lot of decisions I disagree with. edit: I also think there's value in being a conventional imperative language as someone mentioned below. I with there were something between Go and Haskell. Perhaps that'd essentially be Rust with immutable data structures and garbage collection.
- nickik 12y ago
  I dont know much about go, but I always thought that the problem with 'the standard library does everything' is that it starts to feel heavy and better alternatives pop up. Then you have these dark places in the library that most people avoid, and you cant really throw away. Clojure used to have something called, clojure contrib and it was kind of awsome, it did pretty much everything in just one jar. It was also a huge problem to mentain and everybody wanted to be in contrib, so you had the one json lib in contrib and fasters outside. With clojure 1.3 it got split up into many diffrent parts and it still servs as somewhat of a community standard or recommended library. Overall its much better and much more usful, but sometimes I miss the days when everything was in one jar on on dependency.
  - cgag 12y ago
    I started using Clojure just after 1.3 came out so I could be wrong, but my impression was that while contrib was all in one place, it was still maintained by a bunch of random people who got their code into contrib, rather than being treated as a core part of the language the way (I believe) Golang's is.
melvinmt 12y ago
> So I'll ask: What is it I need to read/work through in order to at least "get" Go and really understand its strengths (whether or not I end up liking it)? I highly recommend to read this article where Rob lays out the motivation behind many aspects of Go: http://talks.golang.org/2012/splash.article http://talks.golang.org/2012/splash.article
meowface 12y ago
Going by Paul Graham's "Blub" essay (http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html), I'd say the problem is that languages like Go and Java are simply not high in the rankings when it comes to power.
- enneff 12y ago
  The underlying assumption is that the problem that modern programming languages should solve is lack of power. But I don't see that problem in modern codebases. In my experience, the problem is complexity.
  - pjmlp 12y ago
    > In my experience, the problem is complexity. Simple languages led to complex code bases. Many of the Enterprise Java sins were caused by the language limitations and developers trying to work around them.
    - oblio 12y ago
      True, but in a lot of enterprise situations the complexity is intractable - it is caused by business requirements.
      - pjmlp 12y ago
        Exactly because of that I rather use languages that provide the tools to work with complexity, instead of shunning it into the shoulders of developers. Anyway Go has its use cases, and it is already an improvement if less C code gets written.
    - enneff 12y ago
      I think the enterprise Java sins were caused by cargo cult programming. Java can actually be pretty nice when wielded by someone who isn't afraid to invent new things.
      - 12y ago
Elrac 12y ago
Maybe unlike other respondents, I'm a Go amateur. I've written three projects in Go, one of a few thousand lines and two of a few hundred. Also unlike many others, I consider Go un-elegant to the point of being ugly. In other words, I'm no expert and no fanboy. What makes Go my go-to language for certain kinds of projects (I'll doubtless be using it again) is that it gets shit done. It has the brutal simplicity and hardware proximity (and raw speed) of C combined with the small handful of things that most significantly contribute to make Java better than C: A simple type system, garbage collection, usable string handling and dynamic data structures (arrays and hash maps). Go also has a fairly large, useful library. Multiple return values often including errors make error/exception handling very explicit and in-your-face. When something can go wrong, you the programmer are forced to recognize that and deal with it as soon as the function returns. That's a Good Thing IMO. Java-style exception handling, by comparison, looks to me like an elaborate language hack for passing the buck. There's a ruthless kind of efficiency in Go's surrounding philosophy. There's one way to format Go code, you let the utility take care of it and never worry about formating again. The compiler won't tolerate various kinds of sloppiness, such as unused imports. As somebody else mentioned, in Go, writing elegant code is not a consideration because it's nearly impossible. Well, I'm sure there are "better" and "worse" ways to write Go code, but not so obviously that I'd be tempted to give it a lot of thought. So I tend to just sit there and write code by the bucketful until I'm done. Finally, the tooling gets the job done, and quickly. I can compile for and across various hardware environments and ship executables that don't rely on a JVM or other external dependencies.
coldtea 12y ago
>People who seem to be smart nevertheless keep talking it up... some not even as just a good tool but as their favorite language. Being good enough, not knowing any better PL-wise, and the Stockhold Syndrome explains that.
spotman 12y ago
If you have spent six months, is that just occasionally tinkering and reading things online, or actually using it fairly regularly? If you have developed software in go, and after a couple months you aren't finding its saving you time, or at least pleasant to work with, maybe its not for you. I feel like it is similar to C, but more opinionated, with much less rope to hang yourself, and often things I would have used C or Java, I find doing them in golang saves me plethoras of time. It is opinionated, but for me the aha moment was after I learned enough of the standard libraries to feel comfortable in the language, I find myself getting things done at lightning speed, and it has performance that is as solid as the jvm in your average use case. I find the code is also pleasant to read, and the language lends itself to writing verbose, simple code, which I find easier to debug than overly abstracted systems.
- curun1r 12y ago
  > I find the code is also pleasant to read This, to me, is what he's missing. On the continuum between readable and expressive, Go falls decidedly on the readable side. If you're working on a project by yourself for 6 months, you might not like Go. But if you work on a team or return to code you wrote 6 months ago and haven't touched since, that's when you'll appreciate Go. Evaluating languages based on simple solo projects will always favor the more expressive languages, but it's a short-sighted evaluation.
jfb 12y ago
It may just not fit for you. I feel the same way about C++ -- I understand the strengths of a pay-for-what-you-use language with a ridiculously powerful template library, but it just never came naturally to hand for me.
MetaCosm 12y ago
Composition. That is the single biggest thing that has impressed me as my codebase has grown. Concurrency and messaging is nice, but I come from Erlang... I am not easily impressed by concurrency and messaging. Composition, the power of interfaces in complex systems is the key for me. It is what makes me stay with Go, and why I will probably stick around for a long time. It is so obnoxiously useful, without ever getting in my way. Let's talk for a second about the tiny little function io.Copy(dst io.Writer, src io.Reader) It reads data from reader and writes to writer... simple. Now what makes this little function so darn useful is it takes anything fulfilling its interfaces (io.Writer and io.Reader). The first way you will probably use it will be to copy between some stream and a file without having to eat up all the memory to store the buffer (not using ioutil.ReadAll for example)... but then you realize you can use a gzip compressor on the writer side, or a network socket, or your own code... and io.Copy works with anything that fulfills its interface. As you build out a complex application, you start by creating your own functions that take advantage of existing interfaces foo.OCR(dst io.Writer, src img.Image). After that you start building out your own interfaces... like a MultiImage interface that has ImageCount and ReadImage methods that returns the count of images and binary data... but then you realize the images could be big, so you make the ReadImage method return an io.Reader... and now you have gone full circle and are using io.Copy to copy imageX from a stack of images to return to your OCR function that will output the data to an io.Writer which you made actually a gzip writer because text compresses well. Beyond composition -- obviously, the concurrency and messaging is nice and when you need it vital. The other thing that will help make Go "click" is being very "data oriented" in your design... be vicious and minimal: http://youtu.be/rX0ItVEVjHc http://youtu.be/rX0ItVEVjHc (great talk on data oriented design) and be absolutely pragmatic, focus on getting shit done, always...
- coldtea 12y ago
  >It reads data from reader and writes to writer... simple. Now what makes this little function so darn useful is it takes anything fulfilling its interfaces (io.Writer and io.Reader). The first way you will probably use it will be to copy between some stream and a file without having to eat up all the memory to store the buffer (not using ioutil.ReadAll for example)... but then you realize you can use a gzip compressor on the writer side, or a network socket, or your own code... and io.Copy works with anything that fulfills its interface And how is that any different than any language with interfaces? (Besides the implicit thing?).
pasxizeis 12y ago
Tooling, simplicity (eg. lack of features), composition, channels.

claystu 12y ago

What weaknesses of Pascal are being repeated in Go?

lmm 12y ago
There is no escape. The language thinks it knows better than you. The standard library is allowed to do things that your code isn't.
- _ak 12y ago
  Like what? The standard library is no more special, other than where it resides in the filesystem. You can write C and assembly code as well and link it to your Go code. And I'm not talking about cgo, I mean [568][ac], the Plan 9 C compiler and assembler that come with Go.
  - lmm 12y ago
    I was thinking most obviously of generics. The go standard library is full of generic collections, but you're not allowed to use generics in your own code.
    - _ak 12y ago
      That's not the standard library, though.
    - claystu 12y ago
      It looks like free pascal has generics: http://www.freepascal.org/docs-html/ref/refch8.html#refse46.html http://www.freepascal.org/docs-html/ref/refch8.html#refse46.... But to your larger point, doesn't any non-programmable programming language exhibit the same weakness to some extent?
      - lmm 12y ago
        Any language will have some "magic" things that are special-cased in the compiler - things like the basic integer datatypes, or the threading primitives - and probably a few more things that are implemented as C code (though if you're lucky this can be done in a "standard" way, through the language's FFI). But most of the standard library should be implemented in the language itself (look at e.g. the Java standard library, or the Python standard library. In a more coherent language like TCL, even language constructs may be written this way - e.g. "for" or "if" can be just ordinary methods. At the other extreme, PHP has the infamous T_PAAMAYIM_NEKUDOTAYIM, because a simple-seeming piece of syntax had to be special-cased in the parser). If the standard library authors kept feeling the need to step outside the language itself, that's a bad sign - it suggests the language is poorly suited to writing libraries in. But you're right that it's a question of degree rather than a binary thing.
  - pjmlp 12y ago
    > Like what? Maps, slices, the pre-defined functions. More powerful languages make no big distinction between user defined types and the language provided ones.
  - howeman 12y ago
    Actually, the c compiler just got deleted. https://groups.google.com/forum/#!topic/golang-codereviews/AfirOjUi6e4 https://groups.google.com/forum/#!topic/golang-codereviews/A...

ansible 12y ago

So I'll ask: What is it I need to read/work through in order to at least "get" Go and really understand its strengths (whether or not I end up liking it)? As discussed elsewhere on this page, Go is not the most feature-rich language out there. But it does have features that seem to help my solve my problems with a minimum amount of fuss. Like using interfaces liberally, instead of having to define classes. Having lexical closures is also nice. If you're not working on an application that can benefit from concurrency, you may not see all the benefits of Go either. What kind of problems were you trying to solve, and how did Go see heavyweight compared to how you'd solve the problem in some other language?

wwweston 12y ago
I like functions as first-class values and closures. If they weren't present, I might well have bailed months ago. :) And from various experiences doing OO with other languages, I can kindof buy that Go interfaces are often 80% of what you want. Most of what I've been working on is a Rest API. Here's an example of a problem that felt like it should be something for which I'd be able to write an abstraction to deal with, but turned out to be challenging, at least as a n00b: https://groups.google.com/forum/#!topic/golang-nuts/JhsiiGHQ2j4 https://groups.google.com/forum/#!topic/golang-nuts/JhsiiGHQ... (Incidentally, though I moved past my then really poor understanding of Go interfaces, I wasn't able to apply the respondent's answer or my new general knowledge to achieve the abstraction I was looking for, and settled for just grinding out the same code for the dozen entities/endpoints it applied to.) Concurrency: I suspect there's a bit that's hidden in some libraries we're using, and we may yet need to write our own code for some API requests that get processed offline, but I haven't had to explicitly write code for it yet. If you can think of a specific exercise that might serve to illustrate Go's outstanding concurrency strengths, I'd be interested to try it and compare efforts to another language or two.
- ansible 12y ago
  (Incidentally, though I moved past my then really poor understanding of Go interfaces, I wasn't able to apply the respondent's answer or my new general knowledge to achieve the abstraction I was looking for, and settled for just grinding out the same code for the dozen entities/endpoints it applied to.) I definitely can't deny that using interfaces instead of regular OO classes takes some getting used to. Though I don't understand why you had to grind out duplicate code for all the entities / endpoints though. I hacked up things a bit to get it to run on the playground, but as Jesse McNelis wrote, just passing the pointer to foo worked for the code you wrote. http://play.golang.org/p/jNpK5CRBfv http://play.golang.org/p/jNpK5CRBfv

cft 12y ago

Go is the only language that allows one to write very scalable TCP servers fast (i mean development effot). The servers are almost as fast as C (i.e. 15x Python), but the development time is like Python.

tlmr 12y ago
What about Julia?
- FraaJad 12y ago
  Yeah, what about Julia? which makes as much as sense as asking - What about R? - What about GNU DAP? - What about FORTRAN? for writing a TCP server.
est 12y ago
For the record, Go does not allow you to operate on fd, so some fine tuning TCP parameters does not happen unless you do reflection magic and use SysCall. Which is PITA compared to Python.
threeseed 12y ago
There are numerous options for writing very scalable TCP servers on the JVM e.g. Vertx. Then you have the option of using Java, Clojure, Scala, Ruby, Python, Javascript or Groovy languages.

cgag 12y ago

I don't think you're going to come around on it. It's not suddenly going to stop being terrible at abstraction. That essay seems very accurate and applies to Golang. The strengths of Go to me seem to be its extensive standard libary and the fact that you don't need to worry about writing elegant code because it's not really an option. That reduced decision making is actually really appealing to me on some level, but it's not enough for me to consider it over what I consider better tools (Haskell, Rust). I'm currently porting a tiny program a friend wrote in Go to Haskell so we can compare notes, and I think the Haskell is both safer and more elegant, but I'm jealous of the fact that all the libraries he used are from the standard library while I have to evaluate libs of varying quality. However, I would rather put my time in to improving the Haskell ecosystem than using something convenient that makes a lot of decisions I disagree with. edit: I also think there's value in being a conventional imperative language as someone mentioned below. I with there were something between Go and Haskell. Perhaps that'd essentially be Rust with immutable data structures and garbage collection.

nickik 12y ago
I dont know much about go, but I always thought that the problem with 'the standard library does everything' is that it starts to feel heavy and better alternatives pop up. Then you have these dark places in the library that most people avoid, and you cant really throw away. Clojure used to have something called, clojure contrib and it was kind of awsome, it did pretty much everything in just one jar. It was also a huge problem to mentain and everybody wanted to be in contrib, so you had the one json lib in contrib and fasters outside. With clojure 1.3 it got split up into many diffrent parts and it still servs as somewhat of a community standard or recommended library. Overall its much better and much more usful, but sometimes I miss the days when everything was in one jar on on dependency.
- cgag 12y ago
  I started using Clojure just after 1.3 came out so I could be wrong, but my impression was that while contrib was all in one place, it was still maintained by a bunch of random people who got their code into contrib, rather than being treated as a core part of the language the way (I believe) Golang's is.

melvinmt 12y ago

> So I'll ask: What is it I need to read/work through in order to at least "get" Go and really understand its strengths (whether or not I end up liking it)? I highly recommend to read this article where Rob lays out the motivation behind many aspects of Go: http://talks.golang.org/2012/splash.article http://talks.golang.org/2012/splash.article

meowface 12y ago

Going by Paul Graham's "Blub" essay (http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html), I'd say the problem is that languages like Go and Java are simply not high in the rankings when it comes to power.

enneff 12y ago
The underlying assumption is that the problem that modern programming languages should solve is lack of power. But I don't see that problem in modern codebases. In my experience, the problem is complexity.
- pjmlp 12y ago
  > In my experience, the problem is complexity. Simple languages led to complex code bases. Many of the Enterprise Java sins were caused by the language limitations and developers trying to work around them.
  - oblio 12y ago
    True, but in a lot of enterprise situations the complexity is intractable - it is caused by business requirements.
    - pjmlp 12y ago
      Exactly because of that I rather use languages that provide the tools to work with complexity, instead of shunning it into the shoulders of developers. Anyway Go has its use cases, and it is already an improvement if less C code gets written.
  - enneff 12y ago
    I think the enterprise Java sins were caused by cargo cult programming. Java can actually be pretty nice when wielded by someone who isn't afraid to invent new things.
    - 12y ago

Elrac 12y ago

Maybe unlike other respondents, I'm a Go amateur. I've written three projects in Go, one of a few thousand lines and two of a few hundred. Also unlike many others, I consider Go un-elegant to the point of being ugly. In other words, I'm no expert and no fanboy. What makes Go my go-to language for certain kinds of projects (I'll doubtless be using it again) is that it gets shit done. It has the brutal simplicity and hardware proximity (and raw speed) of C combined with the small handful of things that most significantly contribute to make Java better than C: A simple type system, garbage collection, usable string handling and dynamic data structures (arrays and hash maps). Go also has a fairly large, useful library. Multiple return values often including errors make error/exception handling very explicit and in-your-face. When something can go wrong, you the programmer are forced to recognize that and deal with it as soon as the function returns. That's a Good Thing IMO. Java-style exception handling, by comparison, looks to me like an elaborate language hack for passing the buck. There's a ruthless kind of efficiency in Go's surrounding philosophy. There's one way to format Go code, you let the utility take care of it and never worry about formating again. The compiler won't tolerate various kinds of sloppiness, such as unused imports. As somebody else mentioned, in Go, writing elegant code is not a consideration because it's nearly impossible. Well, I'm sure there are "better" and "worse" ways to write Go code, but not so obviously that I'd be tempted to give it a lot of thought. So I tend to just sit there and write code by the bucketful until I'm done. Finally, the tooling gets the job done, and quickly. I can compile for and across various hardware environments and ship executables that don't rely on a JVM or other external dependencies.

coldtea 12y ago

>People who seem to be smart nevertheless keep talking it up... some not even as just a good tool but as their favorite language. Being good enough, not knowing any better PL-wise, and the Stockhold Syndrome explains that.

spotman 12y ago

If you have spent six months, is that just occasionally tinkering and reading things online, or actually using it fairly regularly? If you have developed software in go, and after a couple months you aren't finding its saving you time, or at least pleasant to work with, maybe its not for you. I feel like it is similar to C, but more opinionated, with much less rope to hang yourself, and often things I would have used C or Java, I find doing them in golang saves me plethoras of time. It is opinionated, but for me the aha moment was after I learned enough of the standard libraries to feel comfortable in the language, I find myself getting things done at lightning speed, and it has performance that is as solid as the jvm in your average use case. I find the code is also pleasant to read, and the language lends itself to writing verbose, simple code, which I find easier to debug than overly abstracted systems.

curun1r 12y ago
> I find the code is also pleasant to read This, to me, is what he's missing. On the continuum between readable and expressive, Go falls decidedly on the readable side. If you're working on a project by yourself for 6 months, you might not like Go. But if you work on a team or return to code you wrote 6 months ago and haven't touched since, that's when you'll appreciate Go. Evaluating languages based on simple solo projects will always favor the more expressive languages, but it's a short-sighted evaluation.

jfb 12y ago

It may just not fit for you. I feel the same way about C++ -- I understand the strengths of a pay-for-what-you-use language with a ridiculously powerful template library, but it just never came naturally to hand for me.

MetaCosm 12y ago

Composition. That is the single biggest thing that has impressed me as my codebase has grown. Concurrency and messaging is nice, but I come from Erlang... I am not easily impressed by concurrency and messaging. Composition, the power of interfaces in complex systems is the key for me. It is what makes me stay with Go, and why I will probably stick around for a long time. It is so obnoxiously useful, without ever getting in my way. Let's talk for a second about the tiny little function io.Copy(dst io.Writer, src io.Reader) It reads data from reader and writes to writer... simple. Now what makes this little function so darn useful is it takes anything fulfilling its interfaces (io.Writer and io.Reader). The first way you will probably use it will be to copy between some stream and a file without having to eat up all the memory to store the buffer (not using ioutil.ReadAll for example)... but then you realize you can use a gzip compressor on the writer side, or a network socket, or your own code... and io.Copy works with anything that fulfills its interface. As you build out a complex application, you start by creating your own functions that take advantage of existing interfaces foo.OCR(dst io.Writer, src img.Image). After that you start building out your own interfaces... like a MultiImage interface that has ImageCount and ReadImage methods that returns the count of images and binary data... but then you realize the images could be big, so you make the ReadImage method return an io.Reader... and now you have gone full circle and are using io.Copy to copy imageX from a stack of images to return to your OCR function that will output the data to an io.Writer which you made actually a gzip writer because text compresses well. Beyond composition -- obviously, the concurrency and messaging is nice and when you need it vital. The other thing that will help make Go "click" is being very "data oriented" in your design... be vicious and minimal: http://youtu.be/rX0ItVEVjHc http://youtu.be/rX0ItVEVjHc (great talk on data oriented design) and be absolutely pragmatic, focus on getting shit done, always...

coldtea 12y ago
>It reads data from reader and writes to writer... simple. Now what makes this little function so darn useful is it takes anything fulfilling its interfaces (io.Writer and io.Reader). The first way you will probably use it will be to copy between some stream and a file without having to eat up all the memory to store the buffer (not using ioutil.ReadAll for example)... but then you realize you can use a gzip compressor on the writer side, or a network socket, or your own code... and io.Copy works with anything that fulfills its interface And how is that any different than any language with interfaces? (Besides the implicit thing?).

pasxizeis 12y ago

Tooling, simplicity (eg. lack of features), composition, channels.