Go's success has me confused. My team enjoys using Go, but to me it feels like i'm a prisoner. The designer's slavishly followed opinions are laser focused on reducing variation across go codebases. There's definitely less to learn than most languages. Unfortunately, sometimes the blessed way of doing things doesn't work well for your problem and not only are you left with a hammer to cut the wood, but making a saw is outlawed.
Why Go is doomed to succeed
61–70 of 330 posts
Re: Why Go is doomed to succeed
#62Go seems to be attracting a lot of developers from Python, Ruby and Node because Go offers them the easy path to getting started that they place a premium on, combined with speed, but relatively few people from the order-of-magnitude-larger JVM world. Coming from Java I like that there's a very similar language that I can use for command line applications (a JVM sore-spot) or a simple daemon -- both because it doesn'…
Sure, there is some nice things about the JVM. However, for me, Java was the first language to get ditched when I got comfortable enough with Go to accomplish similar tasks. Reasons are many, but Go definitely wins "single native binary" argument. Java has to be installed, and it has different versions that can be installed. Go you simply compile for whatever platform you want, and you literally have a single native…
I think that those advantages are extremely valuable for command-line apps, and hardly matter at all for servers. Those organizations you've mentioned probably do take advantage of bytecode manipulation (they have undoubtedly used shadowing, and probably some agents) even though they don't write manipulation -- or hot-swapping -- code themselves, and they certainly enjoy the JVMs unmatched monitoring.
Re: Why Go is doomed to succeed
#63Earlier quoted context omitted.
Not quite. To understand Go, you need to understand the history of the Bell Labs gurus somewhere around the late 9th and 10th editions of Research Unix, when the vestiges of what would become Plan 9 and Inferno began to take shape (the sam editor that would influence acme, the rc shell, mk and the predecessor to 9P [streams] would all originate here - see "Interprocess Communication in the Ninth Edition Unix System"…
I feel like "bringing CSP into a modern language" gave Pike's team social permission to launch Golang, but the parent comment is closer to the truth than this summary. According to Pike's blog, the real motivating factor for Golang was how forbidding and painful Google's C++ build process was. A lot of Golang makes more sense if you look at it through this lens: above all else, don't be like C++.
> According to Pike's blog, the real motivating factor for Golang was how forbidding and painful Google's C++ build process was. A lot of Golang makes more sense if you look at it through this lens: above all else, don't be like C++.
You and I disagree in regards to a lot about Golang, but I think you're spot-on here. I've thought for years that it was interesting how yosefk's criticisms of C++ in the "Frequently Questioned Answers" directly correspond to decisions in Golang: "compile times are long" → "use the Plan 9 toolchain", "memory management is difficult and unsafe" → "garbage collection", "templates are a mess" → "no generics", "exceptions interact badly with RAII" → "no traditional exceptions", "header files are a pain" → "use packages and forbid circular dependencies", etc.
Re: Why Go is doomed to succeed
#64Earlier quoted context omitted.
Not quite. To understand Go, you need to understand the history of the Bell Labs gurus somewhere around the late 9th and 10th editions of Research Unix, when the vestiges of what would become Plan 9 and Inferno began to take shape (the sam editor that would influence acme, the rc shell, mk and the predecessor to 9P [streams] would all originate here - see "Interprocess Communication in the Ninth Edition Unix System"…
I feel like "bringing CSP into a modern language" gave Pike's team social permission to launch Golang, but the parent comment is closer to the truth than this summary. According to Pike's blog, the real motivating factor for Golang was how forbidding and painful Google's C++ build process was. A lot of Golang makes more sense if you look at it through this lens: above all else, don't be like C++.
According to Pike's blog, the real motivating factor for Golang was how forbidding and painful Google's C++ build process was.
Yes, that was the "spark" that motivated it, as I hinted it.
A lot of Golang makes more sense if you look at it through this lens: above all else, don't be like C++.
"Don't be like C++" is pretty much a side effect behind much of the Bell Labs and Research Unix philosophy that values composable byte stream interfaces and liberally using a small number of abstractions.
The historical context behind Go that I wrote about is quite undeniable, though. I feel that you're being a tad too contrarian here, but I'd love to know more from your viewpoint.
Re: Why Go is doomed to succeed
#65Earlier quoted context omitted.
It's not hard to find people switching from Java to Go (e.g. http://www.infoworld.com/article/2608571/application-develop... , which I found within 10 seconds of searching). It's true that Go doesn't have a lot of those powerful JVM features that you listed, but as with any engineering trade-off there are lots of people who judge the benefits of Go to be worth the loss of those things.
Of course there are people making the switch, but the numbers are not nearly as substantial at as people switching over from scripting languages (even in nominal figures, let alone percentage) -- which perfectly makes sense. You'll also note that since that article was published, all the advantages listed in in it have either found their way into Java (lambdas, fibers) or to other similar languages like Kotlin (multi…
Maybe it's just that Python/Ruby programmers are more inclined to publicly discuss their switching?
Re: Why Go is doomed to succeed
#66Earlier quoted context omitted.
It's not hard to find people switching from Java to Go (e.g. http://www.infoworld.com/article/2608571/application-develop... , which I found within 10 seconds of searching). It's true that Go doesn't have a lot of those powerful JVM features that you listed, but as with any engineering trade-off there are lots of people who judge the benefits of Go to be worth the loss of those things.
Of course there are people making the switch, but the numbers are not nearly as substantial at as people switching over from scripting languages (even in nominal figures, let alone percentage) -- which perfectly makes sense. You'll also note that since that article was published, all the advantages listed in in it have either found their way into Java (lambdas, fibers) or to other similar languages like Kotlin (multi…
Go is particularly well suited to long-running critical server apps. It has fewer GC issues compared to Java and is also simpler language (making it harder to screw things up - Java generics can get very complex).
Re: Why Go is doomed to succeed
#67Earlier quoted context omitted.
More like "... whether you've used any more modern languages than C" (such as ML and many other functional and research languages).
I have used SML, OCaml, Haskell, and many other languages, and I like Go, and use it for almost anything I do these days. So your statement is false. The only thing I did like more in functional languages was writing compilers (which ironically happens to be what I'm doing now in Go).
I didn't carry out a scientific study -- to my knowledge, no one is bringing any hard facts to the table when they talk about programming language preferences -- so you can't evaluate what I said as logically true or false.
For reference, I have used OCaml, Haskell, Golang and C extensively. I think Golang is a wasted opportunity to replace C. It's a mediocre language with a bunch of annoyances.
Re: Why Go is doomed to succeed
#68Go is doomed to succeed because it extends the mental model of C with a concurrency model that finds a decent compromise between power and ease of use, makes the typing less prone to subversion, adds memory safety via GC, uses a structural subtyping system through interfaces that brings many OO-like benefits while still keeping to the C struct way of thinking, first-class functions, various syntactic rough edges clea…
I'm a 90's C programmer and a Golang programmer now, and while there's some truth to this, it's reductive. A 2000s-era C programmer would not write socket code that worked the way net.Conn does. While C code gave us the "pipes and filters" abstraction of Unix, they are not an idiom in C code --- in fact, Golang's reader/writer interfaces feel more like a refinement of Java than a modernization of C. Golang feels very…
When I looked it over it struck me as a stripped down Java that's friendlier for systems programming and could interoperate with C without the torture of JNI.
Re: Why Go is doomed to succeed
#69Earlier quoted context omitted.
I feel like "bringing CSP into a modern language" gave Pike's team social permission to launch Golang, but the parent comment is closer to the truth than this summary. According to Pike's blog, the real motivating factor for Golang was how forbidding and painful Google's C++ build process was. A lot of Golang makes more sense if you look at it through this lens: above all else, don't be like C++.
> According to Pike's blog, the real motivating factor for Golang was how forbidding and painful Google's C++ build process was. A lot of Golang makes more sense if you look at it through this lens: above all else, don't be like C++. You and I disagree in regards to a lot about Golang, but I think you're spot-on here. I've thought for years that it was interesting how yosefk's criticisms of C++ in the "Frequently Que…
Oh, wow. I love the C++ FQA (I'm a C++ refugee, from the nadir of C++, when Alexandrescu's book had just come out and template error messages were still 10 pages long).
I never though to evaluate Golang against it. Great point.
Re: Why Go is doomed to succeed
#70> TL;DR Golang was explicitly engineered to thrive in projects built by large groups of programmers with different skill levels, and there is no larger such group than the open source community. Very true. This article hits the nail on the head. Most people say that they cannot "express" certain things in go, or have to jump through hoops to do it. The point of go is not to create a highly expressive language, but ra…
"explicitly engineered to thrive in projects built by large groups of programmers with different skill levels" Reminds me of Java. Although, Java gets increasingly complex these days. It also started out without generics.
I don't think you can say "Reminds me of Java" with "Simple enough". Java is too complicated now.