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

161–170 of 330 posts

Re: Why Go is doomed to succeed

#161

Post by ads_are_shite »

Animats wrote: post #154

It's very clear what Go is for. Go is for the kind of stuff Google runs on their servers. C++ is too complex, too unsafe, and too hard to maintain, and Python is too slow. (Remember that "slow" at that scale means "we have to add another acre of servers.") Go is an OK language for server-side stuff. It's not perfect. The concurrency isn't as airtight as its proponents originally claimed. Reflection and type "interfac…

So, if we tread the same well worn steps as Google, drink from the same fountains we see their guilded staff drink from, we will be ok, but anything off the beaten path, we will be fucked? And good luck getting anything else as go is basically what Google say (see versioning and generics for examples).

Re: Why Go is doomed to succeed

#162

Post by neverminder »

Animats wrote: post #154

It's very clear what Go is for. Go is for the kind of stuff Google runs on their servers. C++ is too complex, too unsafe, and too hard to maintain, and Python is too slow. (Remember that "slow" at that scale means "we have to add another acre of servers.") Go is an OK language for server-side stuff. It's not perfect. The concurrency isn't as airtight as its proponents originally claimed. Reflection and type "interfac…

I brought Rust into my job for some non-essential stuff and so far it obliterated my usual tools (Scala, Python to be more specific) in shear speed and low memory consumption. I've written no more than a thousand LOC of it and most of it is still clumsy bearing it mind the fact that I'm new to it, but the potential that it has cannot be denied. To me it's a missing link I was waiting for - a low level language that feels like a high level one.

Re: Why Go is doomed to succeed

#163

Post by biggerbob »

Animats wrote: post #154

It's very clear what Go is for. Go is for the kind of stuff Google runs on their servers. C++ is too complex, too unsafe, and too hard to maintain, and Python is too slow. (Remember that "slow" at that scale means "we have to add another acre of servers.") Go is an OK language for server-side stuff. It's not perfect. The concurrency isn't as airtight as its proponents originally claimed. Reflection and type "interfac…

> Rust is for people who […] program in Haskell for fun. Go is for people who have a job to do.

Typical condescending PL bullshit. So many programmers like to say that their PL of choice is meant for work and the rest are cute toys. Such widespread ignorance and stupidity saddens me.

Re: Why Go is doomed to succeed

#164

Post by kyrra »

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…

Any sources that say Google had a high turnover rate? Only things I can find is that most employees have a short tenure, which seems to be due to lots of hiring.

Re: Why Go is doomed to succeed

#166

Post by xamuel »

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…

>And the simple ability to concatenate strings without first reserving space for the result

Not exactly the same thing, but routine string manipulation in C gets considerably easier once you discover a highly underrated function called asprintf (basically combines sprintf and malloc, calculating the buffer size for you).

Re: Why Go is doomed to succeed

#167

Post by spotman »

pron wrote: post #141
spotman wrote: post #83

Earlier quoted context omitted.

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

I can see your point, and it's the best one I've heard so far in favor of Go over the JVM. But I feel that there are two serious fundamental problems with Go -- or rather two classes of problems -- that are likely to hinder progress as a Go project grows: 1. Go's over-fitting to Google's development style, especially the over-reliance on dependencies as source-code. 2. Go's lack of hackability that might bite you dow…

Interesting points. I guess time will tell. Having used go for awhile now, these points just don't bother me.

Least hackable is a hard thing to define, but as you've defined it I suppose I agree, albeit in this context it often comes across as a feature to me.

Monkey patches are always monkey patches, and in golang your forced to fork a library to modify how it works. To me this is a good thing. It means that as the codebase evolves, the amount of "hacks" (if you will) are more often than not more clearly defined, and to maintain these hacks its easier to collaborate back and make a pull request, rather than just build up a collection of hacks that have to be maintained separately.

The fact that there is a higher barrier to entry to make these kind of changes, is simply not always a bad thing. Choose your poison, I guess. Golang is all about trade offs. In this case the trade off is its harder to simply add arbitrary code all over the place, but in exchange the culture of golang is more simple.

Re: Why Go is doomed to succeed

#168

Post by mst »

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…

I keep wondering whether the lack of generics is in part intended to make people not even try and implement Hibernate but to accept using a lower level of abstraction instead.

Re: Why Go is doomed to succeed

#169

Post by justthistime_ »

pcwalton wrote: post #158
pron wrote: post #155

Earlier quoted context omitted.

Why do you think generics are more relevant for concurrent data structures?

Because "programs don't need more than one type of dictionary, so the language can just hard code one implementation in" is at least a defensible position in a single-threaded setting (although I don't agree with it), but it definitely isn't in a scalable parallel setting.

Yeah. Go. The concurrent language with a single, mutable, thread-unsafe dictionary implementation.

Re: Why Go is doomed to succeed

#170

Post by Artemis2 »

jamesfisher wrote: post #115
dawkins wrote: post #5

"Go won’t let you abstract yourself in the foot." :)

What a strange idea. The whole point of a programming language is to enable abstraction. I suppose assembler doesn't let you "abstract yourself in the foot" (whatever that means) either.

There is such a thing as too much abstraction. That's partly why Java has now that huge reputation of being a very enterprisey language.
Post reply on HN