Earlier quoted context omitted.
> The issue, then, is that Go's success would contradict their world view. I call BS. The parent explanation is much better: for a lot of the kinds of jobs C++ is good for, Go is not that good, whereas for a lot of things Python is good for, Go is as good and has better performance.
C++ is better for abstraction, as Go does not have generics yet, and C++ is better for performance. Go is faster to compile. Maybe Go is better for concurrent programming, but this is hard to measure.
"100% of our production system is now running Go"
91–100 of 189 posts
Re: "100% of our production system is now running Go"
#92Earlier quoted context omitted.
"I think that Mozilla's Rust is aiming squarely at C++ developers, whereas Go is more of a Java replacement." I basically agree with this as a Rust developer (although I'm not sure about Go being in Java's niche; I think of it more as in node.js's niche -- highly scalable web apps). Early on, I think both Rust and Go were thought to be targeting the same segment, but it turned out that we really weren't. Personally,…
As someone who's tried (and failed) to learn Rust in the past: I'm going to elide any commentary about the syntax for now, as I know why it is the way it is (the type system/annotations). I'm basically just going to expound on one thing for the sake of emphasis. For the love of god make Rust more accessible . I don't mean dumbing down the type system or abandoning regions (I really hope that works out). I mean the fr…
And Patrick(reminding), People are asking for a good beginer's tutorial...
Re: "100% of our production system is now running Go"
#93Earlier quoted context omitted.
In hindsight it doesn't seem so surprising. Go really isn't a good alternative to C++ for the kinds of things that really need the low-level control and direct memory access C++ provides. And if you don't really need those things you probably should have moved on to Java or Ruby/Python/etc already. And since a lot of Java shops are fantastically risk averse I'm not at all surprised that the same kind of people that w…
Straight from Rob Pike -- http://commandcenter.blogspot.com/2012/06/less-is-exponentia... Python and Ruby programmers come to Go because they don't have to surrender much expressiveness, but gain performance and get to play with concurrency. C++ programmers don't come to Go because they have fought hard to gain exquisite control of their programming domain, and don't want to surrender any of it. To them, software isn…
I just can't see Go as an alternative to C or C++, and I'm quite surprised that anyone (especially someone such as Rob Pike) could.
Sure there are situations where a program that typically would have been written in C/C++ could benefit from Go (so there is a place for it), but the reasons for choosing C/C++ are often the same that makes Go a really bad fit.
My dreams of a C-like language where the dangerous parts have been removed (and in this context I don't consider having control of your memory dangerous) took a hit with the introduction of Go :(
Re: "100% of our production system is now running Go"
#94Earlier quoted context omitted.
I think there's a bit of truth in both And you can't use go outside of the "PC" (that is, embedded systems).
> And you can't use go outside of the "PC" (that is, embedded systems). Why not? It runs on Arm.
But the issue is twofold, you need a specialized GC for systems with memory limitations (and/or some realtime requirements)
Re: "100% of our production system is now running Go"
#95Earlier quoted context omitted.
C++ is better for abstraction, as Go does not have generics yet, and C++ is better for performance. Go is faster to compile. Maybe Go is better for concurrent programming, but this is hard to measure.
Go has interfaces, which can be used to write generic code. Go performance is not on par with optimized C++ but for me it's fast enough and the performance / dev_time ratio is higher.
Casting every list element to "interface{}" is not generic.
Re: "100% of our production system is now running Go"
#96Re: "100% of our production system is now running Go"
#97Earlier quoted context omitted.
I think that Mozilla's Rust is aiming squarely at C++ developers, whereas Go is more of a Java replacement. And it's interesting to see Python and Ruby being squeezed lately, from various directions; Clojure, Go, other languages. Since Python went mainstream and started being picked up for serious projects, it naturally came under the spotlight a lot more than it had previously, and I think many people have started t…
> Furthermore, although Python is a pretty good all-round language, it doesn't really excel at anything in particular, unlike for example Perl which continues to maintain a strong niche in the areas of text processing and system administration, despite its popularity having fallen away in some of the other areas it was formerly strong in. Well, it does excel in scientific computing. Biologists, astronomers and such u…
links: http://en.wikipedia.org/wiki/BioPerl | http://pdl.perl.org/
Re: "100% of our production system is now running Go"
#98Earlier quoted context omitted.
> And you can't use go outside of the "PC" (that is, embedded systems). Why not? It runs on Arm.
PPC, MIPS, SH? But the issue is twofold, you need a specialized GC for systems with memory limitations (and/or some realtime requirements)
Re: "100% of our production system is now running Go"
#99Earlier quoted context omitted.
> And you can't use go outside of the "PC" (that is, embedded systems). Why not? It runs on Arm.
PPC, MIPS, SH? But the issue is twofold, you need a specialized GC for systems with memory limitations (and/or some realtime requirements)
Re: "100% of our production system is now running Go"
#100Creator of SASS and Haml now using Go for whole production system. When asked about surprising things about Go, its creators have said that they expected to recruit people from c++ communities, instead it seems to be more ruby/python people.
In hindsight it doesn't seem so surprising. Go really isn't a good alternative to C++ for the kinds of things that really need the low-level control and direct memory access C++ provides. And if you don't really need those things you probably should have moved on to Java or Ruby/Python/etc already. And since a lot of Java shops are fantastically risk averse I'm not at all surprised that the same kind of people that w…
Most things don't seem surprising in hindsight. That's why you don't judge surprises by it.
If C++ programmers did flock to Go, would you then say that that was surprising? If not, you've just fallen victim to hindsight bias (because a model that predicts everything is useless).