Is this true? Go was built specifically for C++ developers, which, even when Go was first release, was a pretty unpopular language for writing web services (though maybe not at Google?). That a non-trivial number of Ruby/Python/Node developers switched was unexpected. (1)
> I don't remember where I saw it, but someone talked about using Go in contrast with Java, and the overwhelming reaction was "that's cool but I'm a Python programmer, I'm curious what Python programmers think", so I was just trying to give it that angle.
I have seen more Python/Ruby programmers interested in Go than Java or C++ programmers. Rob Pike seems to have observed it as well.
I was asked a few weeks ago, "What was the biggest surprise you encountered rolling out Go?" I knew the answer instantly: Although we expected C++ programmers to see Go as an alternative, instead most Go programmers come from languages like Python and Ruby. Very few come from C++.
> Somewhere, however, that has been extrapolated to the idea that Go is a good language for writing web apps. I don't believe that's the case.
I have always had this feeling and thought why isn't more people speaking up about that.
For me it's a good improvement from C++ (and maybe C as well), somehow well-suited for systems programming.
I never understood how people can claim it to be natural "upgrade" from Python or Ruby. I have a feeling the opposite is actually the case. This of course is all in the web-development context, not in general one.
> Google has been steadily moving away from "Go is a C++ replacement" (because it's not) and toward "Go is a Python/Ruby replacement." (which fits it _much_ better)
I don't see that Go is particularly good general replacement for C++ or Python/Ruby, it seems more of a good tool for the place where Python or Ruby's performance characteristics and less well developed support for concurrency/parallelism make them unattractive, but at the same time the relative heaviness and complexity of C++ makes it unattractive, and so neither seems to be the right choice.
>I remember reading somewhere that Go was originally intended to take over a lot of projects that are currently C++, and that it was kind of a surprise that more Go programmers ended up coming from languages like Python.
Yes, I think that was in an article by Rob Pike, might have been his article titled "Less is exponentially more."
Excerpt:
[ I was asked a few weeks ago, "What was the biggest surprise you encountered rolling out Go?" I knew the answer instantly: Although we expected C++ programmers to see Go as an alternative, instead most Go programmers come from languages like Python and Ruby. Very few come from C++. ]
>Are there people with experience in a wide variety of languages that prefer Go?
Other than Go, I have varying levels of experience in C, C#, Common Lisp, Python, (embedded) assembler, as well as minor hacking with Fortran, Tcl, PHP, and maybe a few other languages I screwed around with for fun.
At first I really really liked Go, and I grew to loathe it. I still think Go probably excels in large software development shops where some of its design decisions make a little bit more sense. For a solo project, unless you're trying to get hired to write Go professionally, I would avoid it.
Some complaints in no particular order:
- An unused import is a compile error, which means every time you comment out a variable while debugging, you also have to go fuck with your imports
- SemVer is baked right into the language, but Go simply cannot handle major versions > 1.x in any sane way. The documentation[0] actually recommends that you copy-paste your entire codebase into a separate v2/ subdirectory and then maintain that. There's apparently a facility to use git tags for major versions, but I tried for like 3 days and could not get it to work so I just gave up.
- No function overloading
- Annoying type/interface system
- Smug, snotty community (mostly #go-nuts on freenode/libera)
That's about all off the top of my head but it was enough to turn me away from go for good. If I was writing an httpd or something similar, as part of a large team, I might choose Go. For just about any other use case I would not, because it sucks for those use cases.
Yes, that is one big area - networked servers - a superset of HTTP servers. The Google site that serves the Chrome browser is supposed to be a Go app, and I've read Google uses Go a lot internally. (I'm sure Rob Pike and his team must be using it, after developing it for that very purpose.) Reading up on the goals of Go will give some insight into that. Part of the reason was that they wanted it to write big systems at Google, including networked ones, and wanted a better experience than they had with C++ (build times [1] and also other issues). Rob Pike has written some about it, others may have too).
[1] This video that I blogged about:
Video: C++, Rust, D and Go: Panel at LangNext '14:
has many interesting language-related discussions; one of them is the discussion about the build times of C++ vs. those of more modern language. There are concrete reasons why C++ build times are relatively so large - the use of include files is part of the reason - those are discussed some in the video, between the panelists, including some of the language (co-)inventors, such as C++'s Bjarne Stroustrup, Go's Rob Pike and D's Walter Bright.
There is a nice moment or two near the end where Stroustrup responds about C++ build times - okay, won't spoil it for you and others - go see it :)
Command-line tools is another area where Go is used a lot. Getting the convenience of deploying a simple single binary (maybe at the most a config file or two with it) even by just copying to the deploy target - unlike what you have to do with interpreted languages like Python and Ruby (unless you use something like PyInstaller or py2exe for Python, but that is not officially supported and may or not work for all Python apps [2]). This gives us back some of the convenience of older compiled languages like C where this was the normal way of deploying - but with some benefits over languages such as C (see Go vs. C topics), plus goroutines, channels, etc., I guess. Though I have not come across any examples of what things command line apps using goroutines and channels could be used for - it would be interesting to hear/read about some. I mean apart from a few somewhat obvious ones such as a web client to download multiple URLs in different goroutines, concurrently.
[2] I've tried out PyInstaller on a few Python apps, including command-line apps, and a simple wxPython app or two - it did work okay for those, in the limited testing I did.
> If I switch to anything, I'll probably switch to Go.
I think this is what is often happening, given that Go is attracting more Perl/Python/Ruby types than its original target audience of C/C++ developers.
> Go was created at Google to solve Google problems
Still, the vast majority of critical and infrastructure code at Google remains written in C++ and Java. Languages with superior performance, ecosystems, and that have actually proven to work in large scale programming (as opposed to hand wavy incorrect claims about being that).
golang is more or less a hobby project with a lot of bad design decisions that went too far.
> Go is successful for other reasons, mainly it plays into the biases of certain class of developers and managers.
While there is definitely an element of that, I think the main reason Go is successful are completely unrelated to the language itself. The main advantage of Go is that it is the one GC language with a slim runtime. Go programs are tiny compared to Java, C#, Python, Haskell etc. They start instantly. And they do so even if they are implementing an HTTP server or other non-trivial things.
So Go is excellent at something like containerized microservices, where you want to easily run dozens of containers on a single host, and rely on quick restarts for the occasional bug.
> Go was always intended for writing the type of networked application servers that are common in Google's infrastructure. [I was at Google when it was released - I thought you were too?]
I was (2010-2017 to be exact) so I remember how this was communicated but internally and externally. This HN submission [1] to HN from 2011 reflects my recollection of that messaging that Go was a better C.
Even better, Rob in his own words [2]:
> I was asked a few weeks ago, "What was the biggest surprise you encountered rolling out Go?" I knew the answer instantly: Although we expected C++ programmers to see Go as an alternative, instead most Go programmers come from languages like Python and Ruby. Very few come from C++.
> Go is still inferior to Python in prototyping, in web development, and in data-science
On the data science point, I certainly agree that nothing looks likely to displace numpy/scipy anytime soon. Python's much-maligned GIL does simplify C module extensions and, I believe, was a key contributor in Facebook choosing to move to Mercurial many years ago (long before my time).
I wrote a fairly significant internal app at Google in Python and essentially swore I'd never do it again. The way I like to put it is that I don't want to write unit tests for spelling mistakes. I haven't used Go for Web development but I'd already choose it over Python just for static typing.
As an aside, I found the protobuf integration in Python to be basically terrible. Perhaps it's improved in the last 7+ years though.
>Go is good for what it was intended for which is concurrent programming and server/web application.
I absolutely agree that Go is nice for writing web servers! However, there is no reason that it can't still be nice for that and also a well-designed language in general.
For example, Haskell has awesome concurrency features, and writing a web server in Haskell is reasonably nice (not quite as nice as in Go, IMO).
> Feels like a scripting language, but you get static typing and the performance of a compiled language.
Exactly. I'm a longtime enthusiastic Python programmer and reluctant C++ programmer, and for me Go is the first language that could realistically replace both Python and C++ for my programming.
For me the killer features of Go are:
- Go code is almost as compact as Python but--especially for numeric code--much, much faster.
- You never have to wait for the compiler! Everything I've written compiles and links in a fraction of a second.
Note too that, apart from the C runtime and low-level OS interfacing stuff, the entire Go standard library is written in Go itself. Contrast this w/ "scripting"/dynamic languages like Python or Ruby where much of the standard library has to be written in C for performance.
> Go was originally written to replace the things C++ is usually used for.
Go was originally written to replace the things C++ is usually used for within Google. C++ is used for many other things (embedded programming, games and graphics engines, etc.) that it doesn't seem like the Go authors were targeting. In fact, Pike said "we were pleased and a little surprised to find [Go] suitable for general-purpose programming" [1]. This suggests they weren't intending to create an across-the-board replacement of C++, since C++ is certainly a general-purpose programming language. Perhaps to a fault.
> I think the motivation behind creating Go was there weren't many new languages made to make writing systems level software easier.
The authors ran into issues describing it as a "systems language," since it's not really a systems language in the conventional sense (i.e., low-level language with fine-grained control over hardware and memory) [1]. Because C++ is used for conventional systems programming, and the Go team described Go as a C++ replacement, this probably ended up doing Go's reputation more harm than good.
Pike and the Go team have essentially redefined "systems language" for their purpose, as a language targeting servers and interconnected systems. And it excels there.
> Go has both faster run-time performance and stricter type checking than Ruby, Python, or JS, competitors in the server space.
I don't dispute that, but those aren't the only competitors. If you're willing to give up the extreme dynamicism of those languages, you gain a lot more type-safety and expressiveness, and similar performance, from a modern strongly typed functional language like OCaml/F#/Scala/Haskell.
> Once you've made it, you certainly don't want to recode.
Yes and no. You probably want to accumulate a lot of technical debt during the early stages, meaning you're going to be doing substantial rewriting in any case. The rewrite strategy has worked out pretty well for e.g. Twitter.
> The Go Authors say one of the motives for building Go was the very long compile times of building C++ apps for large-scale web development. One thing they mentioned in particular was the large compile times due to processing and reprocessing of #include files. We know Microsoft ran into the same problem because they put Pre-Compiled Headers (PCH files) into their C family tools. Go has an import facility that prevents the problems of the #include file design.
Sure, like pretty much any language from the past 20 years. The C++ header recompilation problem is basically unique to C++. I can understand Go would seem good if C++ (and Ruby/Python et al) were the only alternatives, but that's really not the case.
> Go strikes me as one of the most conservative programming languages available today. It’s small and simple, and every detail is carefully thought out.
This article is wrong in many ways, but I thought I'd point out this particular one. There are many really weird warts in Go, in fact its about average in "wartiness". Here is one example https://dave.cheney.net/2017/08/09/typed-nils-in-go-2
Go biggest advantage isn't the language, its the decent documentation and standard library design. The language is a bit mediocre. I wish the Go community accepted this and moved on - a mediocre language with good documentation and well done standard library is still an acceptable contender since so many other languages get those two wrong.
Is this true? Go was built specifically for C++ developers, which, even when Go was first release, was a pretty unpopular language for writing web services (though maybe not at Google?). That a non-trivial number of Ruby/Python/Node developers switched was unexpected. (1)
https://commandcenter.blogspot.com/2012/06/less-is-exponenti...
reply