Why Go is doomed to succeed • Hacker News Board

Re: Why Go is doomed to succeed

#71

Post by api » Sat, Jun 13, 2015, 5:29 PM UTC

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 focused on simplicity, maintainable code bases, and uniformity to allow the next crop of Valley recruits to pick up where the last crop left off.

Re: Why Go is doomed to succeed

#72

Post by tptacek » Sat, Jun 13, 2015, 5:29 PM UTC

vezzy-fnord wrote: post #64

tptacek wrote: post #49

Earlier quoted context omitted.

I feel like "bringing CSP into a modern language" gave Pike's team social permission to launch Golang, but the parent comment is closer to the truth than this summary. According to Pike's blog, the real motivating factor for Golang was how forbidding and painful Google's C++ build process was. A lot of Golang makes more sense if you look at it through this lens: above all else, don't be like C++.

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 about toolchain quality, and for every person that appreciates a well designed stdlib, there are 3 that appreciate CPAN more. It's harder to disagree with a facility that few mainstream languages provide in any form. So CSP is very important to Golang's identity.

It's just not the "why" of Golang (or at least, I don't think it is.)

Re: Why Go is doomed to succeed

#73

Post by pron » Sat, Jun 13, 2015, 5:29 PM UTC

vorklerta wrote: post #58

pron wrote: post #31

Go seems to be attracting a lot of developers from Python, Ruby and Node because Go offers them the easy path to getting started that they place a premium on, combined with speed, but relatively few people from the order-of-magnitude-larger JVM world. Coming from Java I like that there's a very similar language that I can use for command line applications (a JVM sore-spot) or a simple daemon -- both because it doesn'…

Many of the Java monitoring is only critical because of the garbage collection issues with large heaps. Since switching away from Java we don't miss any of the features you've listed. The problem with Java is the mountain of bloated frameworks which have become standard over the last 10+ years - things like Spring, Hibernate etc. which new developers are expected to learn. With Go new developers which join the team a…

> Many of the Java monitoring is only critical because of the garbage collection issues with large heaps.

That's not true. All JVM libraries expose a ton of monitoring information through the standard JMX interface at every level of the stack, from deep inside the JVM, through logging framework, DB drivers, schedulers etc., and all the way through the application.

And I can only guess that you've yet to encounter Go's even worse GC problems with large heaps.

> Java unfortunately has a mountain of legacy cruft which makes it a pretty terrible choice for new hires to ramp up on.

True, but only in legacy codebases. A new Java project is as pristine as a new Go project, and new Java libraries are just as lean (because there's a lot of cross-influence between the two environments).

Re: Why Go is doomed to succeed

#74

Post by Dewie3 » Sat, Jun 13, 2015, 5:30 PM UTC

pron wrote: post #31

Go seems to be attracting a lot of developers from Python, Ruby and Node because Go offers them the easy path to getting started that they place a premium on, combined with speed, but relatively few people from the order-of-magnitude-larger JVM world. Coming from Java I like that there's a very similar language that I can use for command line applications (a JVM sore-spot) or a simple daemon -- both because it doesn'…

When pron posts on a thread about lang X, it tends to be 30% about lang X and 70% raving about the JVM platform.

Re: Why Go is doomed to succeed

#75

Post by pron » Sat, Jun 13, 2015, 5:31 PM UTC

vorklerta wrote: post #66

pron wrote: post #46

Earlier quoted context omitted.

Of course there are people making the switch, but the numbers are not nearly as substantial at as people switching over from scripting languages (even in nominal figures, let alone percentage) -- which perfectly makes sense. You'll also note that since that article was published, all the advantages listed in in it have either found their way into Java (lambdas, fibers) or to other similar languages like Kotlin (multi…

Go is particularly well suited to long-running critical server apps. It has fewer GC issues compared to Java and is also simpler language (making it harder to screw things up - Java generics can get very complex).

> It has fewer GC issues compared to Java

No, it has more GC issues. It's just that there aren't yet enough libraries and big applications to make that apparent. It hasn't been stressed enough just yet.

Re: Why Go is doomed to succeed

#76

Post by vezzy-fnord » Sat, Jun 13, 2015, 5:32 PM UTC

tptacek wrote: post #45

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'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 Irrelevant".

Obviously it's nowhere near as pure as ndb, but that's the reality of being in Unix.

Re: Why Go is doomed to succeed

#77

Post by pmahoney » Sat, Jun 13, 2015, 5:33 PM UTC

bkeroack wrote: post #33

nobullet wrote: post #9

Earlier quoted context omitted.

What's wrong with JVM?

Among other things, an unnecessary VM layer if all you ever run on is x86.

The VM part of the JVM allows for really great monitoring: there are standard ways for tools to hook into bytecode and add instrumentation without needing the source. There are also lots of mature tools available, but that's mostly because the JVM has been around for so long.

We're looking at Go right now, and our instrumentation is currently done manually at the source level. Are there, or will there be, tools to add instrumentation similar to those available on the JVM? I'm sure it's possible...

Re: Why Go is doomed to succeed

#78

Post by doomrobo » Sat, Jun 13, 2015, 5:33 PM UTC

scriptproof wrote: post #48

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…

But you are lucky if your project has a large group of programmers. There is more probably a large group of projects with a small group of programmers. There are also some large projects: Linux, KDE, LibreOffice, VLC, LLVM, etc... and none is written in Go.

>Linux (1991)

>KDE (1996)

>LibreOffice (based on StarOffice, 6.0 released in 2002)

>VLC (2001)

>LLVM (2003)

I think you have a point r.e there being more smaller projects than large projects with large teams. But this is a terrible argument. Go was released in 2007. Are you being facetious or are you suggesting that porting a mature codebase to Go is that easy? CoreOS was released in 2013 and so was Docker. I know that Docker actually ported to Go after the fact, but it was still relatively young and Go was already mature by then.

Re: Why Go is doomed to succeed

#79

Post by pcwalton » Sat, Jun 13, 2015, 5:39 PM UTC

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…

There are mio and serde respectively for your first two points, and mio in particular is really popular.

Regarding thread::scoped, I think that kind of issue isn't unique to Rust (Java, a language with a simpler memory model, has had all kinds of weird corner case bugs, especially around memory and concurrency). It's also, again, more an issue of "safe manual memory management is hard": the simple ways to avoid that issue would have been "GC everything", "sacrifice memory safety", or "remove reference counted smart pointers", which contradict Rust's goals.

Re: Why Go is doomed to succeed

#80

Post by sz4kerto » Sat, Jun 13, 2015, 5:39 PM UTC

discardorama wrote: post #70

qznc wrote: post #59

Earlier quoted context omitted.

"explicitly engineered to thrive in projects built by large groups of programmers with different skill levels" Reminds me of Java. Although, Java gets increasingly complex these days. It also started out without generics.

I don't think you can say "Reminds me of Java" with "Simple enough". Java is too complicated now.

Java as a language is still very simple. Frameworks are complicated -- but I doubt this can be avoided in the long run, Go will have similar problems.