3 ms·

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

by serge2k 11y ago

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

reagency 11y ago
Often Java is too slow too. (Slow == overhead from GC of unwanted object metadata and heap allocated objects)
- Gurkenmaster 11y ago
  Go has a gc. That doesn't seem to be the problem. Google also uses Java quite often.
- threeseed 11y ago
  In those Techempower benchmarks Java destroyed Go for web app style requests. And given that the JVM is so dominant in big data (e.g. Spark, Storm), online betting and applications like high frequency trading you could make the reasonable assumption that Java is anything but slow.
laumars 11y ago
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.
- lucidguppy2000 11y ago
  How does go prevent complexity?
  - laumars 11y ago
    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.
  - not_with_retard 11y ago
    By avoiding complex constructs, and having an extremely easy-to-parse (humanly, as well as electronically) syntax. Not to mention the beautiful way that composition functions.
  - Merovius 11y ago
    Mostly by making abstractions harder. By making it pointless to think about "what is the best type-hierarchy for this software" or "what is the most general way this problem can be formulated and solved", it forces you to focus and solve the problem at hand, which leads to more straightforward and easier to understand code. Most people I've seen, that are frustrated with go, are people who want to have an impact on the community by writing a package that a) solves a simple-ish problem with the simplest API possible (e.g. "password-hashing libraries") or b) solves a complicated-ish problem in the most general way possible (e.g. "generic containers" or "graph algorithms"). As go makes both of these very hard, these kinds of people get frustrated with it. go generally agrees with people who want to solve complicated specific problems, e.g. "I want to find all dead links on a website", because it gives you a relatively straight way from A to B.
    - iamcreasy 11y ago
      Is there any detailed article on this topic that you know of?
      - Merovius 11y ago
        The canonical answer is [0], though unfortunately, that's not very good to illustrate this specific point :) I came to this conclusion from reading the golang-{nuts,dev} mailing lists and whan pops up in the community. The usual answer to a proposal of a new language feature (most famously some form of generics) is "what real-world problem is this trying to solve and maybe we can solve it in other ways". And "real-world" always means "real-world", i.e. code that is currently running in some real project out there. And the answer of the people propositioning is almost always something in the neighborhood of "I want to write a foo-library, that makes bar simpler". I remember reading an article a while back by someone explaining exactly that very well, but I can't seem to find it… [0] https://talks.golang.org/2012/splash.article https://talks.golang.org/2012/splash.article
- maffyoo 11y ago
  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.
  - laumars 11y ago
    > I think its a bit premature to predict critical mass for Go If Go was only used by it's sponsoring company and a few "language-whores" on non-critical systems, then I might have agreed with you. But in spite of Go being one of the "new kids on the block", there are already quite a few sizeable projects and organisations outside of Google who are using Go for fundamental parts of their software stack (eg Cloudflare, Canonical and Docker). So like or loathe the language, I'd argue that it's already reached critical mass.

by serge2k 11y ago

reagency 11y ago

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

Gurkenmaster 11y ago
Go has a gc. That doesn't seem to be the problem. Google also uses Java quite often.
threeseed 11y ago
In those Techempower benchmarks Java destroyed Go for web app style requests. And given that the JVM is so dominant in big data (e.g. Spark, Storm), online betting and applications like high frequency trading you could make the reasonable assumption that Java is anything but slow.

laumars 11y ago

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.

lucidguppy2000 11y ago
How does go prevent complexity?
- laumars 11y ago
  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.
- not_with_retard 11y ago
  By avoiding complex constructs, and having an extremely easy-to-parse (humanly, as well as electronically) syntax. Not to mention the beautiful way that composition functions.
- Merovius 11y ago
  Mostly by making abstractions harder. By making it pointless to think about "what is the best type-hierarchy for this software" or "what is the most general way this problem can be formulated and solved", it forces you to focus and solve the problem at hand, which leads to more straightforward and easier to understand code. Most people I've seen, that are frustrated with go, are people who want to have an impact on the community by writing a package that a) solves a simple-ish problem with the simplest API possible (e.g. "password-hashing libraries") or b) solves a complicated-ish problem in the most general way possible (e.g. "generic containers" or "graph algorithms"). As go makes both of these very hard, these kinds of people get frustrated with it. go generally agrees with people who want to solve complicated specific problems, e.g. "I want to find all dead links on a website", because it gives you a relatively straight way from A to B.
  - iamcreasy 11y ago
    Is there any detailed article on this topic that you know of?
    - Merovius 11y ago
      The canonical answer is [0], though unfortunately, that's not very good to illustrate this specific point :) I came to this conclusion from reading the golang-{nuts,dev} mailing lists and whan pops up in the community. The usual answer to a proposal of a new language feature (most famously some form of generics) is "what real-world problem is this trying to solve and maybe we can solve it in other ways". And "real-world" always means "real-world", i.e. code that is currently running in some real project out there. And the answer of the people propositioning is almost always something in the neighborhood of "I want to write a foo-library, that makes bar simpler". I remember reading an article a while back by someone explaining exactly that very well, but I can't seem to find it… [0] https://talks.golang.org/2012/splash.article https://talks.golang.org/2012/splash.article
maffyoo 11y ago
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.
- laumars 11y ago
  > I think its a bit premature to predict critical mass for Go If Go was only used by it's sponsoring company and a few "language-whores" on non-critical systems, then I might have agreed with you. But in spite of Go being one of the "new kids on the block", there are already quite a few sizeable projects and organisations outside of Google who are using Go for fundamental parts of their software stack (eg Cloudflare, Canonical and Docker). So like or loathe the language, I'd argue that it's already reached critical mass.