Why Go is doomed to succeed

Post by stefantalpalaru » Sat, Jun 13, 2015, 6:59 PM UTC

tptacek wrote: post #87

api wrote: post #71

Earlier quoted context omitted.

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…

Post by gvickers » Sat, Jun 13, 2015, 7:05 PM UTC

fao_ wrote: post #116

vezzy-fnord wrote: post #41

Earlier quoted context omitted.

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

CSP == Continuation Style Passing or?

Post by jjawssd » Sat, Jun 13, 2015, 7:08 PM UTC

latch wrote: post #36

I'm a fan of Go and have been using it for a [relatively] long time across various large and small systems. I really like it. To me, what's been abundantly clear is that: it's a horrible choice for types of apps a lot of people are using it for. Specifically, systems where ror/django/express/php have traditionally excelled at. I'd say "CRUD", but that's too narrow. The expressiveness and productivity of dynamic langu…

Post by xxs » Sat, Jun 13, 2015, 7:13 PM UTC

pcwalton wrote: post #79

kzvezdarov wrote: post #56

Earlier quoted context omitted.

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…

Post by okasaki » Sat, Jun 13, 2015, 7:17 PM UTC

Elrac wrote: post #25

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.

"Between C and Java" hits it very well, I'd say. When I jumped ship from C to Java, Java's object orientation wasn't exciting to me, and its exception handling is an acquired taste. But dynamically growable, garbage collected buffers are something I'd missed for a long time. And the simple ability to concatenate strings without first reserving space for the result. Oh, and hash maps! Remarkably versatile data structu…