Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Go is doomed to succeed

texlution.com

Post reply on HN
Print view View original

241–250 of 330 posts

Re: Why Go is doomed to succeed

#241

Post by biokoda »

ilurk wrote: post #86

I'm curious about two things. (1) where does Rust fit in this? (2) and if Go is lacking in the concurrency department and loses to Erlang in latency. Why don't people use Erlang/Elixir for servers and Python/etc for client side?

(2) People tend to follow the path of least resistance even if not the most optimal. Erlang requires more effort in the beginning, but pays off immensely later on. It's easier to start learning go because it's not as strange. This is also why node.js became so popular. It has the lowest barrier to entry.

Re: Why Go is doomed to succeed

#242

Post by mkramlich »

spopejoy wrote: post #238

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 sup…

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

Re: Why Go is doomed to succeed

#243

Post by freyr »

spopejoy wrote: post #238

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 sup…

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.

Re: Why Go is doomed to succeed

#244

Post by seanp2k2 »

freyr wrote: post #243
spopejoy wrote: post #238

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 sup…

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 cond…

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.

Re: Why Go is doomed to succeed

#245

Post by taeric »

eropple wrote: post #145
microtonal wrote: post #93

Earlier quoted context omitted.

I find it incredibly primitive, well past the point of "stupid code is impossible to misunderstand" and into "stupid code because the language demands it." Since the parent mentioned C and Java. What are you missing in Go compared to Java besides generics? What are you missing in Go compared to C besides manual memory management? To me, Go seems to have about the same amount of expressiveness as C and Java. The diffe…

> Since the parent mentioned C and Java. What are you missing in Go compared to Java besides generics? That's a clever way to attempt to constrain the conversation away from the elephant in the room. "Other than the bullet in your stomach, how are you feeling?" Not having at least Java-style "dumb" generics, in 2015, is unacceptable; the existence of `go generate` should mortify everybody involved with Go. Not having…

This just seems to hit all of the highlights of the "I tried liking your viewpoint, but you are ultimately stupid" manner of rhetoric. You even give praise to the JVM.

For every post like this that has me starting to think "hell yeah, C is really stupid, how can others not see this?" I'm reminded of why Linus Torvalds is glad he didn't choose c++ for git. And... it resonates too bloody well. Especially when I consider all of the ports to other languages that have been attempted for git.

I think it comes down to generalities. The reality is most programs are doing good if they solve one problem. Not just solve it well, but solve it at all. Many algorithms, on the other hand, can be widely adopted.

This leads one to think they could "write with their gloves off" and nail down that algorithm in such a way that it will be usable everywhere. The reality, though, is that it rarely (ever?) works out. What you find is that all of the small corner cases that matter in solving something come back and bite you. Hard.

Re: Why Go is doomed to succeed

#246

Post by MetaCosm »

Veedrac wrote: post #144
pcwalton wrote: post #19

Earlier quoted context omitted.

How is Rust incomplete and too complex (especially "incomplete")? Compiler-enforced-correct manual memory management may not be the right choice for every project, of course, but I think "too complex" is too strong of a way to say that. That implies there was a simpler way Rust could have achieved the same goals, and I've never seen anyone suggest one that works.

Surely the parent comment only meant that Rust was too complex to use, not that Rust was unduly complex. If Go would be a feasible choice, Rust is probably solving problems that aren't too relevant to you. I think http://arewewebyet.com/ speaks to the completeness point sufficiently. Rust-the-language is probably complete enough for all but the most serious use-cases, but Rust-the-ecosystem isn't.

I agree. Also, maybe Rust-the-community isn't ready to honor promises (http://blog.rust-lang.org/2014/10/30/Stability.html) it makes, which is critical for enterprise adoption.

Twenty-two days after release, Rust started talking about making breaking changes (https://internals.rust-lang.org/t/pre-rfc-adjust-default-obj...). This conversation killed a Rust project I had pushed for... it played into all the existing negative ideas about Rust (constantly changing, not worth investing in) and gave the doubters all the ammo they needed to kill the project.

The change wasn't yet implemented, and had ZERO impact on our code-base even if implemented. But Rust-the-community seems too clueless on the importance of APPEARING stable and able to follow promises.

I wonder how many other Rust projects died because Rust-the-community appears like an untrustworthy ally (I am speaking of perception not reality).

Re: Why Go is doomed to succeed

#247

Post by okasaki »

Elrac wrote: post #219
klibertp wrote: post #210

Earlier quoted context omitted.

What do you mean by "the magic concatenation and auto-conversion of strings"? Also, having a map implemented in a library is a Good Thing. It means that your language is extensible and expressive enough for this. AFAIK Go is - by design - not that extensible.

Magic concatenation: the "+" operator is understood by the compiler to be the concatenation operator if either operand is a String. "Magic" in the sense that it's an exceptional affordance made by the language (not the library) for this one data type and operator. Auto-conversion: "2" + 5 = "25". This looks horribly hackish, like some type buggering perl might do, or js. But it comes in handy when you want to build a…

Magic concatenation:

        string hello = "hello";
        string world = "world";
        string hw = hello + ' ' + world;
Auto-conversion:

        stringstream ss;
        ss

Re: Why Go is doomed to succeed

#248

Post by MetaCosm »

BuckRogers wrote: post #147

"TL;DR Golang was explicitly engineered to thrive in projects built by large groups of programmers with different skill levels, and there is no larger such group than the open source community." This would almost be right, but Go has much poorer language interop than C due to the GC and non-C compatible ABI. This means unless we're going to a monoculture of GoAllTheThings (not likely), Go will never succeed C as bein…

Go 1.5 can call C and be called from C. So you can write a Go function to extend your C app.

Re: Why Go is doomed to succeed

#249

Post by 699 »

mkramlich wrote: post #242
spopejoy wrote: post #238

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 sup…

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

I would say Mozilla is backing Rust, and Google is responsible for a lot of Python's success.

Re: Why Go is doomed to succeed

#250

Post by pcwalton »

MetaCosm wrote: post #246
Veedrac wrote: post #144

Earlier quoted context omitted.

Surely the parent comment only meant that Rust was too complex to use, not that Rust was unduly complex. If Go would be a feasible choice, Rust is probably solving problems that aren't too relevant to you. I think http://arewewebyet.com/ speaks to the completeness point sufficiently. Rust-the-language is probably complete enough for all but the most serious use-cases, but Rust-the-ecosystem isn't.

I agree. Also, maybe Rust-the-community isn't ready to honor promises ( http://blog.rust-lang.org/2014/10/30/Stability.html ) it makes, which is critical for enterprise adoption. Twenty-two days after release, Rust started talking about making breaking changes ( https://internals.rust-lang.org/t/pre-rfc-adjust-default-obj... ). This conversation killed a Rust project I had pushed for... it played into all the existin…

The promise was "we won't break your code". The conversation was to determine the answer to the question "is there any code out there that this will break", because we take that compatibility promise seriously and want to honor it. If you're unhappy that we're having that discussion, well, I'm sorry, but we need to have these kinds of discussions if the compatibility promise is going to mean anything. The alternative would be to make these sorts of changes without discussion (or to stop making any kinds of changes that could break code at all, which rules out too many benign improvements; see below).

It's untenable to guarantee that, in a strict sense, the universe of all possible programs that run on 1.0 will always have the exact same behavior on 1.1. With any language, there are plenty of ways to break code in theory on upgrades that are very unlikely to lead to problems in practice; as an obvious example, incorrect unsafe code that depends on undefined behavior can break when the compiler starts optimizing based on that undefined behavior. I think that, instead, what we can realistically guarantee is that code that actually compiles in 1.0 compiles in 1.1. If there's no code out there that actually breaks, then I don't see any problem.

Golang has made many changes that could technically, and actually did, break code as well (just to name a recent example, the GOMAXPROCS default bump; there have been several others).

Post reply on HN