Why Go is doomed to succeed • Hacker News Board

Re: Why Go is doomed to succeed

#41

Post by vezzy-fnord » Sat, Jun 13, 2015, 4:58 PM UTC

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.

Not quite. To understand Go, you need to understand the history of the Bell Labs gurus somewhere around the late 9th and 10th editions of Research Unix, when the vestiges of what would become Plan 9 and Inferno began to take shape (the sam editor that would influence acme, the rc shell, mk and the predecessor to 9P [streams] would all originate here - see "Interprocess Communication in the Ninth Edition Unix System" [1]).

Meanwhile, Rob Pike and his contemporaries did language research, particularly related to the semantics of CSP-style concurrency. Syntactically they were all C-like, as the Plan 9/Research Unix community all generally liked it.

Newsqueak was the first and it was a cross between C and with special syntax and semantics for procs (green threads). It was written for GUI workstation environments in mind, the idea being to easily build multi-seat applications. From Newsqueak arose Alef, which refined on it but had manual memory management. Then from Alef came Limbo, the language running on top of the Dis VM that formed the core of the Inferno OS.

Fast forward some years later, Rob Pike and some other Bell Labs vets are at Google. Some event happens which painfully reminds them of mediocrity in computing, that gives them the drive again and they resume right where they left from Limbo.

Go is born.

[1] http://cm.bell-labs.co/who/dmr/ipcpaper.html

Re: Why Go is doomed to succeed

#42

Post by coldtea » Sat, Jun 13, 2015, 4:59 PM UTC

hyperpape wrote: post #34

gnuvince wrote: post #27

Earlier quoted context omitted.

Not the parent, but I've read many comments here on HN from users who feel that if a language doesn't include an HTTP server in the standard library, it's not ready for production work. Ridiculous, of course, but that may be what the parent is referring to.

Does Java meet the criterion you're describing here?

JavaEE sure does.

Re: Why Go is doomed to succeed

#43

Post by r0naa » Sat, Jun 13, 2015, 5:02 PM UTC

vezzy-fnord wrote: post #41

aaggarwal wrote: post #14

Earlier quoted context omitted.

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.

Not quite. To understand Go, you need to understand the history of the Bell Labs gurus somewhere around the late 9th and 10th editions of Research Unix, when the vestiges of what would become Plan 9 and Inferno began to take shape (the sam editor that would influence acme, the rc shell, mk and the predecessor to 9P [streams] would all originate here - see "Interprocess Communication in the Ninth Edition Unix System"…

That was very insightful, thank you for sharing!

Re: Why Go is doomed to succeed

#44

Post by spotman » Sat, Jun 13, 2015, 5:07 PM UTC

coldtea wrote: post #17

> To understands why Go is the way it is you need to know why it came to exist in the first place: "The goals of the Go project were to eliminate the slowness and clumsiness of software development at Google, and thereby to make the process more productive and scalable. The language was designed by and for people who write—and read and debug and maintain—large software systems. source" The problem with this idea is t…

This was my favorite quote/sentence in the article. For me it feels extremely true. I am one of those people that has to write, read, debug and maintain large software systems.

Sure generic's would be nice, but I do not feel they really would change much. After using and supporting Go for years, I would rather keep it how it is. Simple and verbose.

Getting up at 3am in the morning to respond to a page going off in a production system that you didn't write, there is something extremely parseable with Go. It doesn't hide and abstract things in a way where you have to end up digging.

Often the docs are just not enough to really understand software. In the event you end up having to go read the code to understand it, when things get that far, I wish it was Go every time. There is little in the world more frustrating than having to read 18 java files to understand a simple format of a payload because your coming in late to the codebase.

Re: Why Go is doomed to succeed

#45

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

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 much like an offspring of Java and Python to me.

Re: Why Go is doomed to succeed

#46

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

dsymonds wrote: post #37

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

It's not hard to find people switching from Java to Go (e.g. http://www.infoworld.com/article/2608571/application-develop... , which I found within 10 seconds of searching). It's true that Go doesn't have a lot of those powerful JVM features that you listed, but as with any engineering trade-off there are lots of people who judge the benefits of Go to be worth the loss of those things.

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 (multiple return values). Go has the undisputed upper hand when it comes to command-line apps (I really like it that I can use a language so similar to Java for stuff I never liked using Java for, and I was never fond of using scripting languages that require tedious dependency management for standalone programs), but is at a fundamental disadvantage when it comes to long-running important servers.

Re: Why Go is doomed to succeed

#47

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

coldtea wrote: post #40

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.

> Yes, there is more of a learning curve, but I think that's a problem with manual memory management in general. To me, that doesn't mean that the language is "too complex"; rather it means that the space Rust is playing in (and which those other languages are not playing in) is complex. Yes, that's probably the case (Rust caters to more complex needs). Still makes it more difficult to just "dive into it" like you ca…

I agree with all of that. :) I don't think it does Rust any favors to pretend that manual memory management doesn't have cognitive overhead compared to pervasive GC, but at the same time, I don't think that it points to anything wrong with the language; "a safe, modern C++" is just a tough niche to fill, and I think (with the obligatory bias) that Rust did it well.

Re: Why Go is doomed to succeed

#48

Post by scriptproof » Sat, Jun 13, 2015, 5:15 PM UTC

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.

Re: Why Go is doomed to succeed

#49

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

vezzy-fnord wrote: post #41

aaggarwal wrote: post #14

Earlier quoted context omitted.

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.

Not quite. To understand Go, you need to understand the history of the Bell Labs gurus somewhere around the late 9th and 10th editions of Research Unix, when the vestiges of what would become Plan 9 and Inferno began to take shape (the sam editor that would influence acme, the rc shell, mk and the predecessor to 9P [streams] would all originate here - see "Interprocess Communication in the Ninth Edition Unix System"…

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++.

Re: Why Go is doomed to succeed

#50

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

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.

If you took "C" out of that list, I'd agree with it.