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

181–190 of 330 posts

Re: Why Go is doomed to succeed

#181

Post by reagency »

serge2k wrote: post #173
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…

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

Often Java is too slow too. (Slow == overhead from GC of unwanted object metadata and heap allocated objects)

Re: Why Go is doomed to succeed

#182

Post by reagency »

Elrac wrote: post #142
okasaki wrote: post #129

Earlier quoted context omitted.

Well, C++ has all of that.

Only for small values of "all." The magic of concatenation and auto-conversion of strings that's baked into the Java compiler and, to a lesser extent, the Go compiler, is missing in C++ - not vital but convenient. Similarly, hashmaps, while built directly into the language in Go, are a library class in C++. Finally, garbage collection will likely never be part of C++.

The main problem of C++ is that it has far too large values of "all".

Re: Why Go is doomed to succeed

#183

Post by reagency »

Elrac wrote: post #142
okasaki wrote: post #129

Earlier quoted context omitted.

Well, C++ has all of that.

Only for small values of "all." The magic of concatenation and auto-conversion of strings that's baked into the Java compiler and, to a lesser extent, the Go compiler, is missing in C++ - not vital but convenient. Similarly, hashmaps, while built directly into the language in Go, are a library class in C++. Finally, garbage collection will likely never be part of C++.

The main problem of C++ is that it has far too large values of "all".

Re: Why Go is doomed to succeed

#184

Post by laumars »

serge2k wrote: post #173
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…

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

Re: Why Go is doomed to succeed

#185

Post by Gurkenmaster »

reagency wrote: post #181
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.

Often Java is too slow too. (Slow == overhead from GC of unwanted object metadata and heap allocated objects)

Go has a gc. That doesn't seem to be the problem. Google also uses Java quite often.

Re: Why Go is doomed to succeed

#186

Post by latch »

jjawssd wrote: post #125
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…

Please tell me more about the pain-driven lessons Hibernate and their ilk taught us

We learned that you can't configure your way out of impedance mismatches. You can certainly make your life easier, but only at the cost of also making it harder.

You essentially need language-level support for dealing with data at your boundaries. Even with Java's strong reflection (Go's reflection is horrible) capabilities and generics (and C# extending that with lambdas and expression trees), there's still tremendous friction and boilerplate configuration and code.

Consider Dependency Injection, an ilk. In most (all?) dynamic languages, DI is a language concern, as opposed to a library concern. By having support for it within the language, the problems DI frameworks attempted to solve in Java (or C#) via messy configurations, legalese-like unit tests and quantities of code dedicated to nothing but the infrastructure of the codebase, simply vanishes. Now people are going to Go and discovering the awesomeness of interfaces.

Re: Why Go is doomed to succeed

#187

Post by tptacek »

justthistime_ wrote: post #175
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…

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.

Re: Why Go is doomed to succeed

#188

Post by lucidguppy2000 »

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.

How does go prevent complexity?

Re: Why Go is doomed to succeed

#189

Post by vorg »

> accept that they won’t change anything. The Go team has said time and again that the language is done for the foreseeable future. You are too late to the party. Some might cry about this, but this stability promise brings more long term benefits than any language improvement could. Breaking changes, even if for the better, are not always welcome

The promise of stability from a large software corp puts in place a solid language foundation people can rely on when building apps in the language. Someone building a successful app using the language shouldn't be able to dictate future changes to the language based on their own needs only, ignoring smaller or less popular apps. Golang's language spec is a big help with this.

When you've tried working with a language whose backers cancel work on a spec for 10 years, then tailor the language's functionality for the one application they themselves are building, you appreciate the promise of stability. When the language's backers open up their AST to programmer addons via annotations, then later duplicate the functionality of the most popular addon, you appreciate the backing company's understanding that long term benefits come from nurturing the community.

When you see a backing company suddenly retrench all the staff working on a programming language, you appreciate that Google is using Golang internally and is unlikely to do the same. Although Golang was born of a Google internal need, let's hope the needs of their own systems won't dictate future changes at the expense of the external community, and that they keep their stability promise.

Re: Why Go is doomed to succeed

#190

Post by codygman »

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…

> program in Haskell for fun.

What about the people who program in Haskell for work?

> Go is for people who have a job to do.

People use Go for fun.

Post reply on HN