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

191–200 of 330 posts

Re: Why Go is doomed to succeed

#191

Post by dkuntz2 »

reagency wrote: post #179
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…

Does Google use Go in any high-load services?

download.google.com is completely powered by Go at this point, iirc.

Re: Why Go is doomed to succeed

#192

Post by maffyoo »

laumars wrote: post #184
serge2k wrote: post #173

Earlier quoted context omitted.

> 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.") Which is why Java gets used instead.

In some situations, yes. But Java can suffer from similar complexity and maintainability issues too. Go, for all it's short comings and missing features, is closer to the "instant gratification" state that Python and it's ilk enjoy while having performance closer to that of Java. I'm not trying to say one language is better or worse than the other though. Just my observations as to why Go is gaining popularity.

I think its a bit premature to predict critical mass for Go and maybe your python comparison is a reasonable prediction of where Go will finish up.

Re: Why Go is doomed to succeed

#193

Post by pcwalton »

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…

That last paragraph is ridiculous. Name one feature in Rust that you think is too much complexity and I'll tell you where I need it to get my job done in Servo.

Without generics and traits, for example, there would literally be no reason for Servo to exist, because it would be too slow. Performance is not optional. Safety is not optional. They are my job. If I opposed language features that are needed for competitive performance or safety on the grounds of complexity, I would be failing to do my job.

I'm responsible for a lot of Rust's features. I have never posted on LTU, and I've never written more than 50 lines of Haskell. I find most of the Rust community's philosophical language debates tiring and pointless; languages to me are tools, not philosophies. The entire core team is largely with me here. I think you have a deep misunderstanding of the language design if you believe Rust has features "just because".

Re: Why Go is doomed to succeed

#194

Post by laumars »

lucidguppy2000 wrote: post #188
laumars wrote: post #184

Earlier quoted context omitted.

In some situations, yes. But Java can suffer from similar complexity and maintainability issues too. Go, for all it's short comings and missing features, is closer to the "instant gratification" state that Python and it's ilk enjoy while having performance closer to that of Java. I'm not trying to say one language is better or worse than the other though. Just my observations as to why Go is gaining popularity.

How does go prevent complexity?

I'm not sure it does. On the one hand Go generally requires less boilerplate code than Java does. But that's only if you're writing simple models; once you factor in stuff like generics you can quickly find the simple becomes unnecessarily complex within Go.

Like with most things, it really depends on what problems you're specifically trying to solve.

Re: Why Go is doomed to succeed

#195

Post by stefantalpalaru »

mst wrote: post #171
stefantalpalaru wrote: post #121

Earlier quoted context omitted.

Let's not do SEO in HN comments. The language's name is "Go", not "Golang".

It's also useful for e.g. using Ctrl-F on your own comments or similar. Searchability optimisation can be valuable on its own.

By that logic you should also say Dlang, Rustlang, Nimlang and so on. Let's optimize for human readers instead.

Re: Why Go is doomed to succeed

#196

Post by kasey_junk »

tptacek wrote: post #187
justthistime_ wrote: post #175

Earlier quoted context omitted.

I think people who use Go in the first place are not those who think much about "can this be done in a better way?". It's quite similar to the notion of "I'm a PHP developer and I don't understand why everyone says it is terribly designed! I learned to work with it and never tried anything else, so it can't be that bad!!!". Not every developer cares about software development. There are plenty of people who chose thi…

I think this comment does a pretty good job of summing up my perception of Golang's opposition.

To be fair, its no more ham-handed or insulting than the common refrain from the Golang proponents: "Go is for getting work done."

Re: Why Go is doomed to succeed

#197

Post by tptacek »

kasey_junk wrote: post #196
tptacek wrote: post #187

Earlier quoted context omitted.

I think this comment does a pretty good job of summing up my perception of Golang's opposition.

To be fair, its no more ham-handed or insulting than the common refrain from the Golang proponents: "Go is for getting work done."

Fair point.

Re: Why Go is doomed to succeed

#198

Post by tptacek »

kasey_junk wrote: post #176
tptacek wrote: post #87

Earlier quoted context omitted.

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…

A team might pick golang to check a box. Particularly the "our boss/organization/PR team wanted it" box. I largely dislike Go but keep picking it because it is the lowest common denominator of languages my team will use and I really like them. Even the proponents of Go on my team are moving away from it as their preferred choice, but for now it remains the only consensus fallback.

If it wasn't going to be Golang, what's the next most likely choice?

Re: Why Go is doomed to succeed

#199

Post by mentat »

pcwalton wrote: post #193
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…

That last paragraph is ridiculous. Name one feature in Rust that you think is too much complexity and I'll tell you where I need it to get my job done in Servo. Without generics and traits, for example, there would literally be no reason for Servo to exist, because it would be too slow. Performance is not optional . Safety is not optional . They are my job . If I opposed language features that are needed for competit…

I don't read his/her criticism that way. It's that users of Rust tend to make over complex systems.

Re: Why Go is doomed to succeed

#200

Post by kasey_junk »

tptacek wrote: post #198
kasey_junk wrote: post #176

Earlier quoted context omitted.

A team might pick golang to check a box. Particularly the "our boss/organization/PR team wanted it" box. I largely dislike Go but keep picking it because it is the lowest common denominator of languages my team will use and I really like them. Even the proponents of Go on my team are moving away from it as their preferred choice, but for now it remains the only consensus fallback.

If it wasn't going to be Golang, what's the next most likely choice?

Some combination of Scala and C++ probably. Golang's central value to me right now is that I can keep a team that is split on those lines happy and cohesive. Which is more than enough of a benefit for me to put my own distaste in the background

The next language I want to learn is OCaml, but thats because I'm sort of obsessed with unikernels.

Post reply on HN