Hacker News Reader

Comment by spopejoy | Hacker News Reader

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.

View on HN

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.

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.

Languages are not products. The analogy is not reasonable.

The analogy holds for Dart at least.

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?

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.

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.

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.

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

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

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

Let me fix that list

CNRI: Python

AT&T: C++

Unisys: Perl

EPFL: Scala

37signals: Ruby

Mozilla: Rust

37signals and ruby? They were involved with Rails, but did they sponsor Ruby?

No, but IIRC Ruby had very little relevance/existence — at least outside Japan — before Rails.

for the point of the parent comment, ruby was chosen for its merits, not designed by 37 signals.

Reply on news.ycombinator.com