5 ms·

Go succeeds because Google's behind it. Go certainly doesn't succeed because of smug/boring articles like this one. The potshot at Erlang early on (also cf. sl

Go succeeds because Google's behind it. Go certainly doesn't succeed because of smug/boring articles like this one. The potshot at Erlang early on (also cf. slurs on Rust and Haskell in some of these comments) betrays the same old "we like it here in our cave" bias of Go boosters whenever confronted with its glaring warts. Go is a great choice for certain workloads, is reasonably fun to code in, and has great doc support on the web. I suspect however it's popular also because it isn't FP and doesn't favor immutability. It plays well with the haters who refuse to understand how good GC/list fusion/stronger types/better abstraction can make code easier to understand and way faster. But the bottom line is no Google, no Go. Just like no Sun, no Java. It's simply unbeatable to have a mega tech corp paying folks to write docs libs and patches. But it doesn't save it from being yet another turing tarpit.

MetaCosm 11y ago
Yep, just like Dart... oh, wait.
mkramlich 11y ago
bingo Google: Go Microsoft: C# Sun/Oracle: Java almost all others: more on their own merits, from developers eyes (Python, Perl, C++, Ruby, Rust, D, Scala, LUA, JS, etc.) a language should have innate merits, of course, but never discount the advantages of having a single corporate entity with lots of cash and focus and a built-in install base of eyes
- 699 11y ago
  I would say Mozilla is backing Rust, and Google is responsible for a lot of Python's success.
- pjmlp 11y ago
  Let me fix that list CNRI: Python AT&T: C++ Unisys: Perl EPFL: Scala 37signals: Ruby Mozilla: Rust
  - wirrbel 11y ago
    37signals and ruby? They were involved with Rails, but did they sponsor Ruby?
    - masklinn 11y ago
      No, but IIRC Ruby had very little relevance/existence — at least outside Japan — before Rails.
      - wirrbel 11y ago
        for the point of the parent comment, ruby was chosen for its merits, not designed by 37 signals.
freyr 11y ago
Right, Google just needs to will something to succeed, and poof, the world rallies around it. Like Dart, and Google Wave, and Google+, and Google Glass, and Google Answers, and Google Buzz. It doesn't matter if it's good or bad, because if it has Google's stamp on it, it's destined to be a wild success. Certainly, having a big corporate sponsor doesn't hurt, but it's clearly neither a necessary nor a sufficient condition.
- seanp2k2 11y ago
  Yes, but Go solves a real problem for many people and isn't attempting to turn a profit. I wonder when it would be at the point where it could sustain relevance without further funding.
  - deleted 11y ago
    [deleted]
- wyager 11y ago
  Languages are not products. The analogy is not reasonable.
  - ngrilly 11y ago
    The analogy holds for Dart at least.
ngrilly 11y ago
The article claims, and tries to "prove", that Go succeeds because it was designed from the very beginning to be a mainstream language, trying to stay simple enough to be accessible to most programmers. You're not discussing this in your comment. You claim that Go succeeds because Google's behind it. Maybe, maybe not. Then write your own article to make your point. The paragraph about Erlang was not a "potshot". The author is just pointing out a tradeoff, which is real. There is no question that Erlang is a great language and system.
- spopejoy 11y ago
  Yes, it won’t always keep you safe from data races as Erlang will, but Erlang keeps you safe by copying your data over and over, making it significantly slower, TANSTAAFL. Potshot. Defend it at your peril.
  - ngrilly 11y ago
    Erlang processes are shared-nothing and, by design, data must be copied when processes communicate: > All data in messages between Erlang processes is copied, with the exception of refc binaries on the same Erlang node. [1] But I have to agree with you that the paragraph about Erlang in the article overstates the issue. In most cases, messages should be relatively light and then the copy is not issue. It's an issue only when you need to transfer or share a complex data structure. If I'm not mistaken, in the current implementation of BEAM, each lightweight process has its own heap and this is the reason why data must be copied. But it could be possible to allocate memory from an arena shared by all processes, and because Erlang data structures are immutable, messages exchanged by processes could contain only references. The cost would be a more complex garbage collector, with the related latency issues. [1] http://www.erlang.org/doc/efficiency_guide/processes.html http://www.erlang.org/doc/efficiency_guide/processes.html
muraiki 11y ago
You characterize certain language features as objectively better. Indeed, those who do not use the particular approach you advocate (FP) or the feature you desire are "haters who refuse to understand". Is this really a charitable way to look at other programmers? As people who, because they do not use your preferred language or languages, are apparently full of hatred and -- not a lack of understanding, but a _refusal_ to understand? How about we consider the author of the blog post, the Go community, and the Go language's designers in a more charitable light. Perhaps the points made in the article are actually valid: that language features involve tradeoffs, some of which are measured not just in terms of performance, and that languages are designed to achieve certain goals that might not align with yours. Yes, I imagine that "Go certainly doesn't succeed because of smug/boring articles like this one" although I'd remove "smug/boring." Before I used Go I hated it "from first principles", because I had used Scala and Clojure and Haskell and Reactive Extensions and all sorts of FP goodness. But to make a long story short, once I started using Go I really enjoyed it and now I willingly choose to use it to solve problems. It was the use of Go that convinced me that perhaps these absolutes from FP I believed in weren't quite absolutes after all. But this doesn't mean that I consider Go to be some kind of perfect holy grail of programming, either. Does that make me a hater who refuses to understand? Does it make me some kind of idiot for regressing from FP? Or perhaps the goals of Go aligned with my team's goals, and that was really helpful and valuable to us?
- spopejoy 11y ago
  I characterize FP as not worse, which of course implies that it must be better in some scenarios to even compete. I characterize Go as having glaring warts. ":=" will bomb on reassignment UNLESS you destructure alongside a new variable. Wart. Try to close over a variable in a loop; wince in pain as you make a throwaway anonymous function to do so. Wart. Don't get me started on "interface {}". Nonetheless, I think Go is a great tool for the right job. I don't think it's "better for open source" (WTF???). I wouldn't want to write a massively-concurrent (not parallel: concurrent) system in such a loose-goosey, non-polymorphic language. But that's just me, knock yourself out.

MetaCosm 11y ago

Yep, just like Dart... oh, wait.

mkramlich 11y ago

bingo Google: Go Microsoft: C# Sun/Oracle: Java almost all others: more on their own merits, from developers eyes (Python, Perl, C++, Ruby, Rust, D, Scala, LUA, JS, etc.) a language should have innate merits, of course, but never discount the advantages of having a single corporate entity with lots of cash and focus and a built-in install base of eyes

699 11y ago
I would say Mozilla is backing Rust, and Google is responsible for a lot of Python's success.
pjmlp 11y ago
Let me fix that list CNRI: Python AT&T: C++ Unisys: Perl EPFL: Scala 37signals: Ruby Mozilla: Rust
- wirrbel 11y ago
  37signals and ruby? They were involved with Rails, but did they sponsor Ruby?
  - masklinn 11y ago
    No, but IIRC Ruby had very little relevance/existence — at least outside Japan — before Rails.
    - wirrbel 11y ago
      for the point of the parent comment, ruby was chosen for its merits, not designed by 37 signals.

freyr 11y ago

Right, Google just needs to will something to succeed, and poof, the world rallies around it. Like Dart, and Google Wave, and Google+, and Google Glass, and Google Answers, and Google Buzz. It doesn't matter if it's good or bad, because if it has Google's stamp on it, it's destined to be a wild success. Certainly, having a big corporate sponsor doesn't hurt, but it's clearly neither a necessary nor a sufficient condition.

seanp2k2 11y ago
Yes, but Go solves a real problem for many people and isn't attempting to turn a profit. I wonder when it would be at the point where it could sustain relevance without further funding.
- deleted 11y ago
  [deleted]
wyager 11y ago
Languages are not products. The analogy is not reasonable.
- ngrilly 11y ago
  The analogy holds for Dart at least.

ngrilly 11y ago

The article claims, and tries to "prove", that Go succeeds because it was designed from the very beginning to be a mainstream language, trying to stay simple enough to be accessible to most programmers. You're not discussing this in your comment. You claim that Go succeeds because Google's behind it. Maybe, maybe not. Then write your own article to make your point. The paragraph about Erlang was not a "potshot". The author is just pointing out a tradeoff, which is real. There is no question that Erlang is a great language and system.

spopejoy 11y ago
Yes, it won’t always keep you safe from data races as Erlang will, but Erlang keeps you safe by copying your data over and over, making it significantly slower, TANSTAAFL. Potshot. Defend it at your peril.
- ngrilly 11y ago
  Erlang processes are shared-nothing and, by design, data must be copied when processes communicate: > All data in messages between Erlang processes is copied, with the exception of refc binaries on the same Erlang node. [1] But I have to agree with you that the paragraph about Erlang in the article overstates the issue. In most cases, messages should be relatively light and then the copy is not issue. It's an issue only when you need to transfer or share a complex data structure. If I'm not mistaken, in the current implementation of BEAM, each lightweight process has its own heap and this is the reason why data must be copied. But it could be possible to allocate memory from an arena shared by all processes, and because Erlang data structures are immutable, messages exchanged by processes could contain only references. The cost would be a more complex garbage collector, with the related latency issues. [1] http://www.erlang.org/doc/efficiency_guide/processes.html http://www.erlang.org/doc/efficiency_guide/processes.html

muraiki 11y ago

You characterize certain language features as objectively better. Indeed, those who do not use the particular approach you advocate (FP) or the feature you desire are "haters who refuse to understand". Is this really a charitable way to look at other programmers? As people who, because they do not use your preferred language or languages, are apparently full of hatred and -- not a lack of understanding, but a _refusal_ to understand? How about we consider the author of the blog post, the Go community, and the Go language's designers in a more charitable light. Perhaps the points made in the article are actually valid: that language features involve tradeoffs, some of which are measured not just in terms of performance, and that languages are designed to achieve certain goals that might not align with yours. Yes, I imagine that "Go certainly doesn't succeed because of smug/boring articles like this one" although I'd remove "smug/boring." Before I used Go I hated it "from first principles", because I had used Scala and Clojure and Haskell and Reactive Extensions and all sorts of FP goodness. But to make a long story short, once I started using Go I really enjoyed it and now I willingly choose to use it to solve problems. It was the use of Go that convinced me that perhaps these absolutes from FP I believed in weren't quite absolutes after all. But this doesn't mean that I consider Go to be some kind of perfect holy grail of programming, either. Does that make me a hater who refuses to understand? Does it make me some kind of idiot for regressing from FP? Or perhaps the goals of Go aligned with my team's goals, and that was really helpful and valuable to us?

spopejoy 11y ago
I characterize FP as not worse, which of course implies that it must be better in some scenarios to even compete. I characterize Go as having glaring warts. ":=" will bomb on reassignment UNLESS you destructure alongside a new variable. Wart. Try to close over a variable in a loop; wince in pain as you make a throwaway anonymous function to do so. Wart. Don't get me started on "interface {}". Nonetheless, I think Go is a great tool for the right job. I don't think it's "better for open source" (WTF???). I wouldn't want to write a massively-concurrent (not parallel: concurrent) system in such a loose-goosey, non-polymorphic language. But that's just me, knock yourself out.