7 ms·

Go's aha moment is its low cognitive overhead. It eschews power and conciseness for clarity, everywhere. It takes the exact opposite approach to functional lang

Go's aha moment is its low cognitive overhead. It eschews power and conciseness for clarity, everywhere. It takes the exact opposite approach to functional languages, preferring boring simplicity to powerful but cryptic abstraction. It turns out that an uncompromising devotion to clarity is quite powerful in its own right. It's not right for every use case, but highly compelling for many.

danieldk 14y ago
Go's aha moment is its low cognitive overhead. I think some of us already had that with the first Java versions. Actually, Go looks a lot like old Java versions, minus the VM, plus Goroutines/channels, and static duck typing. I have written a fair share of Go code and ultimately it's a very boring, but predictable language. If it builds a larger ecosystem, it will not be much different than a Java that compiles to native code. Without some of the advantages of the JVM. (What we are really seeing here on HN lately is a hype, pretty much like node.js and FP before. Go has a better chance to stick, because it has a good steward.)
- irrelative 14y ago
  Honest question: what do you consider the advantages of the JVM over native code?
  - hellrich 14y ago
    "Write once, run anywhere"
    - qu4z-2 13y ago
      I've heard this far more commonly from Java programmers as "Write once, debug everywhere", but maybe that's changed. (this was quite some time ago)
  - threeseed 14y ago
    Definitely deployment flexibility. Write on OSX, Test on Linux, Run on Solaris. But also performance. JVM can be faster than say C/C++ code in many cases.
  - danieldk 14y ago
    - "Write once, run everywhere." as the sibling poster mentions. I can build on my Mac, deploy on whatever the server platform is. Snapshot and release builds of our build server are distributed via a Nexus-managed repository. So, everyone codes against exactly the same dependencies, regardless of the platform. - Hotswapping/JRebel. - Good interoperability with other languages. E.g. the Typesafe folks implemented Akka in Scala. Java gets it for (well, almost) free. - Easy monitoring and instrumentation. Obviously, there are downsides as well, such as startup times (twofold: starting the VM and Hotspot detection/compilation), preset heap size, expensive JNI (native interface), etc.
    - dualogy 14y ago
      > Write once, run everywhere Well, so Go is "write once, build 3-9x, run anywhere".. close enough ;)
      - cthackers 14y ago
        i think i would rather build a binary for each platform and run as fast as possible than to build once and run slow on all platforms.
        mercurial 14y ago
        Java is a damn memory hog, but for server-side kind of stuff, not really slow.
        danieldk 14y ago
        Except that Java code typically runs as fast or faster in the JVM than compiled Go code[1]. Of course, Go is still new and gc and gcc-go will be optimized further. But Java bytecode execution is definitely not slow and usually within 2x the execution time of a C implementation, which is faster than the vast majority of other language implementations. [1] At least in the language benchmarks game. Yes, I know that microbenchmarks are not representative, etc. etc. etc. (Until your favorite language is faster ;).)
        coldtea 14y ago
  - lmm 14y ago
    Well-defined semantics, including for "errors" like integer overflow or null dereference. A community that's converged on a deterministic, crossplatform way of representing library dependencies (maven). An ABI that includes a notion of objects, which makes cross-language interoperability with objects easier (though counterbalanced by not having a cross-language notion of functions).
- fauigerzigerk 14y ago
  I kind of agree with that, but Java really needed a reboot. It's more a cultural thing than a technological one. But I'm actually a bit cynical about that. Pretty soon the framework peddlers will descend on Go just as they have descended on Java, JavaScript and Python. Once again a couple of switch statements will be replaced by tens of thousands of lines of framework code. It will be called "beautiful" and "elegant" and "DRY" and those still complaining about the bloat will be told that they don't have to use the features they don't need, but not knowing all the features and all the hooks and all the optimization tricks will once again make you look incompetent and behind the times.
  - threeseed 14y ago
    Java platform has already had plenty of reboots. Play, Grails and Vert.x have shaken up web development. Scala, Groovy and Clojure for languages.
  - fulafel 14y ago
    Yeah, it's the Java culture and the stuff bolted on top by Sun and other business software vendors in an effort to keep relevant and appeal to CIO:s. But I don't agree with the prediction: Python and JavaScript aren't really drowning in BS produced by architecture astronauts. It exists but it's not prevalent.
- pjmlp 14y ago
  > If it builds a larger ecosystem, it will not be much different than a Java that compiles to native code. True, and we already have that for those willing to pay for Java native compilers.
tikhonj 14y ago
You're mistaking familiarity for simplicity. You cannot get much simpler than the lambda calculus, full stop. It has three concepts--lambdas, variables and application--and one evaluation rule. That is all. The rest of the language features are almost always just a thin layer over this. Even when you add types, it's still an amazingly simple model. And the types do not generally affect the runtime behavior of code at all. Functional languages are the very picture of something simple but not necessarily easy. Go, at least for you, is the opposite: it's easy because it's similar to what you're used to, but it also has quite a bit of surface area. My impression is that Go vies for simplicity of implementation over simplicity of semantics. It is a very operational sort of language. Its goal is to make the how clear--the code reflects what it does. Languages like Haskell, on the other hand, are completely the opposite. Haskell values simplicity of semantics over simplicity of implementation. It is a very denotational sort of language. Its goal is to make the what clear--the code reflects what it means. It's a difference in philosophies, certainly, just not quite in the way you construed it to be.
- cgag 14y ago
  Great relevant talk: http://www.infoq.com/presentations/Simple-Made-Easy http://www.infoq.com/presentations/Simple-Made-Easy
- raganwald 14y ago
  Yes! Exceedingly simple semantics combining to form a difficult-to-use language is often called a "Turing Tar Pit," a place where everything is possible but nothing of interest is easy. Conway's Game of Life is even simpler than the lambda calculus, and people build all sorts of amazing things in it, but examples like a calculator that outputs human-readable digits are circus tricks.
  - papsosouid 14y ago
    >Exceedingly simple semantics combining to form a difficult-to-use language Who was suggesting that we should form difficult to use languages on those simple semantics?
pjmlp 14y ago
> Go's aha moment is its low cognitive overhead. Very good for replaceable programmers, the dream of every manager. :)
- delian66 14y ago
  Low cognitive overhead is also good for your future self, that will have to maintain the 'clever' mess which you wrote in a hurry ... In my experience so far, the abstractions that Go offers for writing concurrent code are very nice and easy to understand, and deploying it is really good - it generates static binaries, which you simply upload where you need them. It is a very practical language.
- myg204 14y ago
  Simplicity in design is still a panacea, only good programmers can do it on non trivial systems. Go will allow for better clarity, but beautiful code will not write itself.
coldtea 14y ago
>Go's aha moment is its low cognitive overhead. You mean its strength is that is a Blub language? Because the "low cognitive overhead" is exactly what Java was touted for, back in the day (before the EE madness).
- danenania 14y ago
  It may make the blubs more effective, but that doesn't necessarily mean it can't also make the geniuses more effective too.
  - Roboprog 14y ago
    "Blub" refers to the language itself, rather than the developers. As in "think (no deeper than) in Blub (language concepts)" I can see both sides of the "clever is better/worse" argument, though. E.g. - C++ operator overloading is powerful and harmful.
MetaCosm 14y ago
Go's aha moment IMHO is at the edges. If you have built a complex application (250k+ lines) in C++, Python or Java you know about the quiet undignified pains those projects often suffer. - Horrible build systems (and horrible build times) --- Go compiles fast, and the compile and dependency system is baked in - Impossible to untangle dependencies (don't ever remove an include, who knows where it is used) --- Go forces you to either use a dependency or remove it, stopping dependency cruft from ever building up - Nightmare deploys (system wide assumptions) --- Go deploys with a single platform dependent binary, it is absolutely awesome - Inconsistent formatting, self-directed standards on formatting. --- Gofmt is the one true format, heck, even some bad formatting won't compile (try to uncuddle your else to see) - Inconsistent build systems and build system quality, made worse by using libraries and systems that have their OWN build systems. --- Go get combined with its include system (use it or lose it) really let you tie together systems in a sane way without any custom build routes. - Dealing with modern concurrency --- Go having built in channel communication makes many problems trivial, and allows new methods of abstraction (goes to Go's model of composition).
- danieldk 14y ago
  I'll take Java as an example, since I only use Python for short scripts. - Horrible build systems (and horrible build times) Maven is a great build system, Java has good compile times, and most modern Java IDEs have incremental compilation. And you can specify versions of dependencies, rather than having to maintain a list of SHA1 hashes of versions considered to be stable. (don't ever remove an include, who knows where it is used) This is primarily a problem in C/C++, where one can indirectly get the correct dependencies by accident. Most modern compiled languages don't have this problem. Go forces you to either use a dependency or remove it, stopping dependency cruft from ever building up Which can be annoying for debugging. I'd rather have my IDE or linter give warnings. - Nightmare deploys (system wide assumptions) 'mvn package', it's also easy to configure maven to build an archive with dependencies, configuration files, or whatever you'd like to be in a deploy. In fact, deployments are even easier than in Go, since my package built on OS X will also deploy on a Linux server. My colleagues use different platforms (a mixture of Linux, Windows, and OS X) and it's never a problem. - Inconsistent formatting, self-directed standards on formatting. It's good that the Go team made a standard formatting. That said, my employer has a default layout. It's a matter of importing an XML file in Eclipse or IntelliJ and everything is in company layout (yay). - Inconsistent build systems and build system quality Nearly every Java library is available via Central Maven Repository. Including versioning :), meaning that if upstream changes their API, it's not your problem. In contrast to Go repository/packages. Dealing with modern concurrency Ever heard of Actor models and Akka? Composable concurrency, across more than one machine. With supervision, routing, etc.
papsosouid 14y ago
>It takes the exact opposite approach to functional languages, preferring boring simplicity to powerful but cryptic abstraction. Yes, functional programming is based on the idea that abstractions should be cryptic. That's a very reasonable observation, and not at all ignorant.

danieldk 14y ago

Go's aha moment is its low cognitive overhead. I think some of us already had that with the first Java versions. Actually, Go looks a lot like old Java versions, minus the VM, plus Goroutines/channels, and static duck typing. I have written a fair share of Go code and ultimately it's a very boring, but predictable language. If it builds a larger ecosystem, it will not be much different than a Java that compiles to native code. Without some of the advantages of the JVM. (What we are really seeing here on HN lately is a hype, pretty much like node.js and FP before. Go has a better chance to stick, because it has a good steward.)

irrelative 14y ago
Honest question: what do you consider the advantages of the JVM over native code?
- hellrich 14y ago
  "Write once, run anywhere"
  - qu4z-2 13y ago
    I've heard this far more commonly from Java programmers as "Write once, debug everywhere", but maybe that's changed. (this was quite some time ago)
- threeseed 14y ago
  Definitely deployment flexibility. Write on OSX, Test on Linux, Run on Solaris. But also performance. JVM can be faster than say C/C++ code in many cases.
- danieldk 14y ago
  - "Write once, run everywhere." as the sibling poster mentions. I can build on my Mac, deploy on whatever the server platform is. Snapshot and release builds of our build server are distributed via a Nexus-managed repository. So, everyone codes against exactly the same dependencies, regardless of the platform. - Hotswapping/JRebel. - Good interoperability with other languages. E.g. the Typesafe folks implemented Akka in Scala. Java gets it for (well, almost) free. - Easy monitoring and instrumentation. Obviously, there are downsides as well, such as startup times (twofold: starting the VM and Hotspot detection/compilation), preset heap size, expensive JNI (native interface), etc.
  - dualogy 14y ago
    > Write once, run everywhere Well, so Go is "write once, build 3-9x, run anywhere".. close enough ;)
    - cthackers 14y ago
      i think i would rather build a binary for each platform and run as fast as possible than to build once and run slow on all platforms.
      - mercurial 14y ago
        Java is a damn memory hog, but for server-side kind of stuff, not really slow.
      - danieldk 14y ago
        Except that Java code typically runs as fast or faster in the JVM than compiled Go code[1]. Of course, Go is still new and gc and gcc-go will be optimized further. But Java bytecode execution is definitely not slow and usually within 2x the execution time of a C implementation, which is faster than the vast majority of other language implementations. [1] At least in the language benchmarks game. Yes, I know that microbenchmarks are not representative, etc. etc. etc. (Until your favorite language is faster ;).)
      - coldtea 14y ago
- lmm 14y ago
  Well-defined semantics, including for "errors" like integer overflow or null dereference. A community that's converged on a deterministic, crossplatform way of representing library dependencies (maven). An ABI that includes a notion of objects, which makes cross-language interoperability with objects easier (though counterbalanced by not having a cross-language notion of functions).
fauigerzigerk 14y ago
I kind of agree with that, but Java really needed a reboot. It's more a cultural thing than a technological one. But I'm actually a bit cynical about that. Pretty soon the framework peddlers will descend on Go just as they have descended on Java, JavaScript and Python. Once again a couple of switch statements will be replaced by tens of thousands of lines of framework code. It will be called "beautiful" and "elegant" and "DRY" and those still complaining about the bloat will be told that they don't have to use the features they don't need, but not knowing all the features and all the hooks and all the optimization tricks will once again make you look incompetent and behind the times.
- threeseed 14y ago
  Java platform has already had plenty of reboots. Play, Grails and Vert.x have shaken up web development. Scala, Groovy and Clojure for languages.
- fulafel 14y ago
  Yeah, it's the Java culture and the stuff bolted on top by Sun and other business software vendors in an effort to keep relevant and appeal to CIO:s. But I don't agree with the prediction: Python and JavaScript aren't really drowning in BS produced by architecture astronauts. It exists but it's not prevalent.
pjmlp 14y ago
> If it builds a larger ecosystem, it will not be much different than a Java that compiles to native code. True, and we already have that for those willing to pay for Java native compilers.

tikhonj 14y ago

You're mistaking familiarity for simplicity. You cannot get much simpler than the lambda calculus, full stop. It has three concepts--lambdas, variables and application--and one evaluation rule. That is all. The rest of the language features are almost always just a thin layer over this. Even when you add types, it's still an amazingly simple model. And the types do not generally affect the runtime behavior of code at all. Functional languages are the very picture of something simple but not necessarily easy. Go, at least for you, is the opposite: it's easy because it's similar to what you're used to, but it also has quite a bit of surface area. My impression is that Go vies for simplicity of implementation over simplicity of semantics. It is a very operational sort of language. Its goal is to make the how clear--the code reflects what it does. Languages like Haskell, on the other hand, are completely the opposite. Haskell values simplicity of semantics over simplicity of implementation. It is a very denotational sort of language. Its goal is to make the what clear--the code reflects what it means. It's a difference in philosophies, certainly, just not quite in the way you construed it to be.

cgag 14y ago
Great relevant talk: http://www.infoq.com/presentations/Simple-Made-Easy http://www.infoq.com/presentations/Simple-Made-Easy
raganwald 14y ago
Yes! Exceedingly simple semantics combining to form a difficult-to-use language is often called a "Turing Tar Pit," a place where everything is possible but nothing of interest is easy. Conway's Game of Life is even simpler than the lambda calculus, and people build all sorts of amazing things in it, but examples like a calculator that outputs human-readable digits are circus tricks.
- papsosouid 14y ago
  >Exceedingly simple semantics combining to form a difficult-to-use language Who was suggesting that we should form difficult to use languages on those simple semantics?

pjmlp 14y ago

> Go's aha moment is its low cognitive overhead. Very good for replaceable programmers, the dream of every manager. :)

delian66 14y ago
Low cognitive overhead is also good for your future self, that will have to maintain the 'clever' mess which you wrote in a hurry ... In my experience so far, the abstractions that Go offers for writing concurrent code are very nice and easy to understand, and deploying it is really good - it generates static binaries, which you simply upload where you need them. It is a very practical language.
myg204 14y ago
Simplicity in design is still a panacea, only good programmers can do it on non trivial systems. Go will allow for better clarity, but beautiful code will not write itself.

coldtea 14y ago

>Go's aha moment is its low cognitive overhead. You mean its strength is that is a Blub language? Because the "low cognitive overhead" is exactly what Java was touted for, back in the day (before the EE madness).

danenania 14y ago
It may make the blubs more effective, but that doesn't necessarily mean it can't also make the geniuses more effective too.
- Roboprog 14y ago
  "Blub" refers to the language itself, rather than the developers. As in "think (no deeper than) in Blub (language concepts)" I can see both sides of the "clever is better/worse" argument, though. E.g. - C++ operator overloading is powerful and harmful.

MetaCosm 14y ago

Go's aha moment IMHO is at the edges. If you have built a complex application (250k+ lines) in C++, Python or Java you know about the quiet undignified pains those projects often suffer. - Horrible build systems (and horrible build times) --- Go compiles fast, and the compile and dependency system is baked in - Impossible to untangle dependencies (don't ever remove an include, who knows where it is used) --- Go forces you to either use a dependency or remove it, stopping dependency cruft from ever building up - Nightmare deploys (system wide assumptions) --- Go deploys with a single platform dependent binary, it is absolutely awesome - Inconsistent formatting, self-directed standards on formatting. --- Gofmt is the one true format, heck, even some bad formatting won't compile (try to uncuddle your else to see) - Inconsistent build systems and build system quality, made worse by using libraries and systems that have their OWN build systems. --- Go get combined with its include system (use it or lose it) really let you tie together systems in a sane way without any custom build routes. - Dealing with modern concurrency --- Go having built in channel communication makes many problems trivial, and allows new methods of abstraction (goes to Go's model of composition).

danieldk 14y ago
I'll take Java as an example, since I only use Python for short scripts. - Horrible build systems (and horrible build times) Maven is a great build system, Java has good compile times, and most modern Java IDEs have incremental compilation. And you can specify versions of dependencies, rather than having to maintain a list of SHA1 hashes of versions considered to be stable. (don't ever remove an include, who knows where it is used) This is primarily a problem in C/C++, where one can indirectly get the correct dependencies by accident. Most modern compiled languages don't have this problem. Go forces you to either use a dependency or remove it, stopping dependency cruft from ever building up Which can be annoying for debugging. I'd rather have my IDE or linter give warnings. - Nightmare deploys (system wide assumptions) 'mvn package', it's also easy to configure maven to build an archive with dependencies, configuration files, or whatever you'd like to be in a deploy. In fact, deployments are even easier than in Go, since my package built on OS X will also deploy on a Linux server. My colleagues use different platforms (a mixture of Linux, Windows, and OS X) and it's never a problem. - Inconsistent formatting, self-directed standards on formatting. It's good that the Go team made a standard formatting. That said, my employer has a default layout. It's a matter of importing an XML file in Eclipse or IntelliJ and everything is in company layout (yay). - Inconsistent build systems and build system quality Nearly every Java library is available via Central Maven Repository. Including versioning :), meaning that if upstream changes their API, it's not your problem. In contrast to Go repository/packages. Dealing with modern concurrency Ever heard of Actor models and Akka? Composable concurrency, across more than one machine. With supervision, routing, etc.

papsosouid 14y ago

>It takes the exact opposite approach to functional languages, preferring boring simplicity to powerful but cryptic abstraction. Yes, functional programming is based on the idea that abstractions should be cryptic. That's a very reasonable observation, and not at all ignorant.