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

81–90 of 330 posts

Re: Why Go is doomed to succeed

#81

Post by eropple »

dsymonds wrote: post #38
aaggarwal wrote: post #32

Earlier quoted context omitted.

That's not really my sweet spot, but if it have such a strong inclination towards Java, then would it be much easier for Java programmers to move to Go compared to C programmers? And, what about python programmers, how would Go be for them?

Any decent programmer should be able to switch between {C,Java,Go,Python} without too much difficulty. They each have their own differences and learning curve, but as long as a programmer doesn't identify themselves too tightly as a specific language developer (e.g. some people say "I'm a Java programmer", implying they couldn't possibly learn something else) then it's not hard to pick up Go.

I think that's reductive. I'm a "decent programmer". (I think I'm a little better than that, if I'm being honest.) I regularly use Ruby, Scala, C#, and enough bash to choke a horse. Some C++ too, when I have to, but it's not something I ever want to touch.

I can't deal with Go. And I don't think it's me--I don't do Haskell because of me, I don't do Go because of it. I find it almost impossible to think in Go. 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." This wouldn't bother me, in a very "you do you" sense, if I wasn't stuck debugging faddishly-designed tools like Docker and Terraform written in it. To this end I think Go is a regression for the open source community, because what I see as veneration of stump-dumb languages makes it harder, not easier, to be smart about problems.

Re: Why Go is doomed to succeed

#82

Post by vezzy-fnord »

tptacek wrote: post #72
vezzy-fnord wrote: post #64

Earlier quoted context omitted.

According to Pike's blog, the real motivating factor for Golang was how forbidding and painful Google's C++ build process was. Yes, that was the "spark" that motivated it, as I hinted it. A lot of Golang makes more sense if you look at it through this lens: above all else, don't be like C++. "Don't be like C++" is pretty much a side effect behind much of the Bell Labs and Research Unix philosophy that values composab…

I guess my point is pretty simple: Golang could have succeeded at its core task without channels and "select", but could not have succeeded without an ultra-fast toolchain and a carefully designed standard library that nurtured an idiom of composable APIs defined by nothing more complicated than structs. Having native CSP gives Golang a differentiator that it would not so clearly have without it. People can disagree…

You seem to be analyzing this from a more economic approach, whereas I'm leaning to the historical. I think I can incorporate your position, but I feel as though you undermine the role of CSP. You see it as a "differentiator", whereas I see it as a central research interest of Rob Pike's that permeated all his previous languages and naturally had to make it into Go, as well.

See this excerpt from the Alef reference manual [1]:

        chan(Mesg) keyboard, mouse;

        Mesg m;

        alt {

        case m =
Now where the toolchain is concerned, again that was adapted from the Plan 9 compiler collection (which even OpenBSD at one point was considering but backed off due to licensing) which makes cross-compilation a surprising breeze.

Carefully designed standard library? Plan 9's syscall interface...

Composable APIs defined by one key abstraction? Plan 9 syscalls again, though there it was 9P.

Speed was a motivator, but again - direct side effect of the "5 Principles of Programming" espoused by Rob Pike [2].

[1] http://doc.cat-v.org/plan_9/2nd_edition/papers/alef/ref

[2] http://users.ece.utexas.edu/~adnan/pike.html

Re: Why Go is doomed to succeed

#83

Post by spotman »

pron wrote: post #62
spotman wrote: post #53

Earlier quoted context omitted.

Sure, there is some nice things about the JVM. However, for me, Java was the first language to get ditched when I got comfortable enough with Go to accomplish similar tasks. Reasons are many, but Go definitely wins "single native binary" argument. Java has to be installed, and it has different versions that can be installed. Go you simply compile for whatever platform you want, and you literally have a single native…

I think that those advantages are extremely valuable for command-line apps, and hardly matter at all for servers. Those organizations you've mentioned probably do take advantage of bytecode manipulation (they have undoubtedly used shadowing, and probably some agents) even though they don't write manipulation -- or hot-swapping -- code themselves, and they certainly enjoy the JVMs unmatched monitoring.

I agree that the JVM is way, way ahead when it comes to things like agents and monitoring.

For me personally, those aren't a big of enough of a win. I would rather have simple code that is fast to scale and fast to understand.

Dealing with something like a thundering herd of traffic is much more difficult when your application can take upwards of an entire minute to start up, and to optimize itself to run at decent speeds.

There is likely a sweet spot however. My good experiences with go are working on high scale projects with a handful of other senior level developers. Some other projects I am involved in are with more enterprise shops with many more developers with a wider array of skill levels. In projects like these the other aspects of JVM like how well supported it is and how there is so many other tools for it, it might still win in one of these enterprise environments.

But for many of my use cases, the JVM just feels like it has everything-and-the-kitchen-sink, and sometimes you just want a small, nimble solution that does a few things well.

Re: Why Go is doomed to succeed

#84

Post by tptacek »

vezzy-fnord wrote: post #76
tptacek wrote: post #45

Earlier quoted context omitted.

I'm a 90's C programmer and a Golang programmer now, and while there's some truth to this, it's reductive. A 2000s-era C programmer would not write socket code that worked the way net.Conn does. While C code gave us the "pipes and filters" abstraction of Unix, they are not an idiom in C code --- in fact, Golang's reader/writer interfaces feel more like a refinement of Java than a modernization of C. Golang feels very…

Yes, Go has a heavy focus on interfaces and structural subtyping, as I said. It reflects the trend behind Pike's languages: C-like + some form of CSP + key abstraction. But, even the net package has a noticeable Plan 9 legacy, like the use of dial/listen, as opposed to the clumsy Berkeley socket way. You might recall this was a central complaint of Pike's in his famous presentation "Systems Software Research is Irrel…

I certainly can't deny the Plan9-ism.

Re: Why Go is doomed to succeed

#85

Post by oldmanjay »

aaggarwal wrote: post #14
vezzy-fnord wrote: post #10

Go is doomed to succeed because it extends the mental model of C with a concurrency model that finds a decent compromise between power and ease of use, makes the typing less prone to subversion, adds memory safety via GC, uses a structural subtyping system through interfaces that brings many OO-like benefits while still keeping to the C struct way of thinking, first-class functions, various syntactic rough edges clea…

I have never used Go before. From the sound of it, it looks like Go hits a sweet spot between C and Java? and of course the Google support is a major factor for a possible success.

It doesn't feel right to say go is "between" java and c. There isn't a tremendous amount of expressiveness in go that java can't replicate, and there's enough in java missing from go that makes it a wash, for me anyway.

Re: Why Go is doomed to succeed

#86

Post by ilurk »

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?

Re: Why Go is doomed to succeed

#87

Post by tptacek »

api wrote: post #71
modulus1 wrote: post #61

Go's success has me confused. My team enjoys using Go, but to me it feels like i'm a prisoner. The designer's slavishly followed opinions are laser focused on reducing variation across go codebases. There's definitely less to learn than most languages. Unfortunately, sometimes the blessed way of doing things doesn't work well for your problem and not only are you left with a hammer to cut the wood, but making a saw i…

The article hits on this but doesn't bring up Google's high turnover rate. Google is a resume tick box. Go over to AngelList and look at lists of startups. Take a drink every time you see 'worked at Google' listed as a qualification. You'll be destroyed in an hour or so. Thus people get jobs at Google, put in a year or two, and go off for a higher paying and/or sexier job or a startup of their own. Go is laser focuse…

If this was true, and not a just-so story, then it should be easy to point to several well-known open source projects that started out in Golang and ended up in some other language, or several concepts that were prototyped in Golang and then ported over to some other language.

Like every programming language ever, there are surely many Golang users who've used it solely to add a keyword to their resume. That's not a very interesting observation, because the same thing is true of Rust, Scala, and even Haskell.

Further, that doesn't really address the question of why so many teams select Golang in the first place. A programmer might use Golang to get the keyword on their resume, but a team shipping a new product has no such incentive.

Re: Why Go is doomed to succeed

#89

Post by arielby »

kzvezdarov wrote: post #56
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.

It's rather that Rust's standard library and third party library support is incomplete. E.g.: - last time I checked there was no option to have non-blocking IO which is a pain. - custom JSON serialization/deserialization from/into custom data structures is extremely painful (for reference, rustc_serialize's Decodable trait). - thread::scoped leaking destructors under certain conditions. This is more of an example of…

The leakapocalypse is rather blown-up - I don't think you could observe it unintentionally. Besides, `thread::scoped` is something no other mainstream-imperative language tries to offer - parallelism with essentially no risk of race conditions.

Re: Why Go is doomed to succeed

#90

Post by tptacek »

bkeroack wrote: post #8
gamesbrainiac wrote: post #6

> 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. Very true. This article hits the nail on the head. Most people say that they cannot "express" certain things in go, or have to jump through hoops to do it. The point of go is not to create a highly expressive language, but ra…

I would word it slightly differently--in Go you are free to express yourself in exactly one way: the idiomatic Go way. Anything else will be painful (a good clue is if you find yourself using reflection frequently).

That's true, but it's also (sometimes) liberating. In extremely flexible languages, you can find yourself burning lots of time finding the most "elegant" way to express simple concepts, like "how am I going to write this SQL column to this series of DIVs".

Not coincidentally, Golang sucks at this problem.

But there is something about writing in Golang that makes it easier to dive into meatier code. For instance: I've written programmable assemblers in Ruby and in Golang. With Ruby, I kept refining the assembler until the DSL looked identical to normal X86 assembly (I even hooked the bracket operators to make them behave like dereferences). With Golang, I quickly moved past the assembler into an IR and a compiler.

Post reply on HN