The number one reason for Go’s success is that Google backed it.
There are a lot of very nice languages out there. However, if you look at compiled languages, they largely need a company backing them. Java had Sun. C and C++ had AT&T and later Microsoft for C++. Objective-C had Apple. FORTRAN had IBM.
Don’t underestimate the amount of resources and press that Google’s support brought to Go.
I don't think the backing of Go is even comparable to Java.
Also Dart is a counterexample.
I think the biggest reason for Go's success is that is it incredibly accessible. Everything around and in Go is ergonomic, well documented, easy to understand and clean. It is a language that cares about the tooling and social aspects as first class concepts.
"I think the biggest reason for Go's success is that is it incredibly accessible. Everything around and in Go is ergonomic, well documented, easy to understand and clean. It is a language that cares about the tooling and social aspects as first class concepts."
And most programmers probably wouldn't even know about it having any of those features if it didn't have a famous backer like Google and a famous name like Rob Pike attached to it.
Marketing definitely makes a difference. Whether it made a critical difference in this case is certainly debatable, however, as some languages (like Python) succeeded even before they had buy-in and support from big names. Though, there again, Python had a lot of help from marketing.. it was just that it was marketing of a different kind, from its users rather from any company backing it.
> Python had a lot of help from marketing.. it was just that it was marketing of a different kind, from its users [...]
Perl, Tcl, Python (all scripting, I know) are (iiuc) examples that came to be without a juggernaut behind them, but then to say they had a different kind of marketing behind them is sort of tautological, no? People liked those languages and talked about it. That’s just human nature.
When mention the effect of marketing by users, I mean to distinguish that from choosing a language based on its technical merits. There's a certain amount of buzz and bandwagon effect that plays in to the success of popular languages, and, yes, languages like Perl, Tcl, and Python had it too.
That's a different sort of marketing, though, from the buzz created by having famous/respected names attached to the languges, like Go had in Google and Rob Pike.
There was never any money behind Python, or C++. Both paid their own way, all the way: people actually using one put in sweat because they believed it made things better for them.
Bell Labs paid his salary, but they paid it before C++ as much as after, and would have paid it without. If others had not taken up C++, he would have gone on to other things. C++'s unique contribution was the destructor, not adopted elsewhere until D and then Rust.
The contrast is against Sun spending literally $billions on Java puffery. Go has put a lot more support into Go, by that standard, but still barely $millions, if that.
Dart was abandoned by Chrome and Angular teams, it almost closed down if it wasn't for AdWords team being so heavily invested into Dart that they kind of rescued the project.
Many Google projects that could benefit from Dart ended up migrating to TypeScript instead, oh and all original Dart designers ended up leaving Google.
Naturally in such scenario there is hardly any external confidence to believe in Dart.
Then Flutter came along, decided to pick up Dart from its burning ashes, reboot the type system and add AOT compilation to native code, but the damage to its public image is already done.
However it managed to annoy the Android team enough that now JetPack Compose is a thing.
I think there are a number of factors, but my personal recollection was that Google had a bit more of a magical air about them when Go was released. As an outsider, at the time it seemed like Google could do no wrong, and of course we should all pay attention to this programming language they invented.
Plus it was described as a language to solve Google problems. And we all wanted to be like Google.
In fairness there is a category of systems for which it was about the least-worst fit at the time: distributed concurrent systems where a JVM was unwelcome. Pascal and its progeny were seen as passé, C/C++'s deficiencies well-known by this point, the scripting languages woefully underperformant, the JVM was the punchline of many jokes despite being a phenomenal engineering achievement, D still mired in some kind of civil war over standard libraries and I imagine thousands of other contenders for an undiscovered throne.
But without Google? Pike? There's no chance any of this would've mattered enough.
I think you're exactly right about the "category of systems" thing. If you're "just"[0] moving protobufs across networks, then Go seems like a perfect langauge, esp. if you can just codegen the protobuf code. There's obviously more to it, but that seems to have to been the spark. To be fair, Go does does seem to work quite well for infrastructure code, but in those use cases you're usually just working with very concrete things and are not super-worried about abstracting over "effects" and that sort of thing... because it's all effects and everything is extremely concrete if you're interacting with e.g. the Linux 'container' infrastructure.
Every sufficiently large and profitable technology company eventually sprouts compiler projects. It's as if they hire from an academic pipeline where compilers are a capstone project.
There are now thousands of artificial languages. The sample size for "languages that succeeded and originally came out of Google" may be tiny, but the effect size is pretty bloody spectacular. Considering that the null hypothesis for all programming languages is be swallowed up by a memoryless void, I'm prepared to wager heavily that without the Google halo, Golang would've been no more influential than Newsqueak, Alef or Limbo were.
With Go 1 there was of course go get. With this it became a no-brainer to install code from arbitrary Github repositories. At least the social barrier is really high to properly put in a package at npm or PyPi. But they kind of democratized that.
Also when Go was quite new, many projects had no dependencies or at best a handful. I think that was a learning from other languages with large package repositories, namely Rubygems. People would create gems put them on Github and Rubygems with useful functionalities but abandon them after a few months. So many larger code bases were sometimes rendered unusable because the package became incompatible with new language releases or did even get removed from Rubygems.
Nowadays, since Go has risen so much in popularity and adopted habits from other Programming ecosystems, there are now Go modules which are on par or even better than solutions from other languages.
I'm not going to do that because I don't think Go is a good language and I have no interest in its ecosystem. I'm just here to give people a hard time.
What’s really funny, is that within Google, I don’t think Go was really given much priority for a while. I sure get the picture that the Go team was just smart and trusted, but the project was more of some internal thing.
Basically, the point being, it was Google _developers_ that made the “backing” grow via demand, not some official “initiative”. Initially, this gave me some initial trepidation, but Go has gotten more and more outside engagement each year it’s existed, which is definitely making things just better.
Thus, I don’t really think Google has “backed it” like Sun backed Java. It’s just that Google hires lots of smart people, and those smart people backed it. I’d say Dart is more of an official “google backed” tech. Go is like the language that is succeeding despite their management objectives.
"I don't really think Google has "backed it" like Sun backed Java."
It doesn't have to. For a lot of programmers the very fact that Google (or Rob Pike) made it is enough for them to switch to it or bet that it'll do well and at least take a closer look and try it out, compared to the dozens or hundreds of new languages that come out by completely unknown authors which virtually no one takes a second look at, not because of any deficiencies in those languages since the people that ignore them usually don't even know anything about those languages to begin with.
Very, very true. Sun not only publicized Java heavily, it also invested heavily in a massive library.
> C and C++ had AT&T
Who did no marketing, because they couldn't sell either one. The thing about C and C++ is that you could get them for free, and they were good enough. For many people who had a computer (or at least computer access), but didn't have money yet from a product because they were trying to produce Rev 1, that was magic.
> Objective-C had Apple.
Absolutely.
> FORTRAN had IBM.
This was before my time, but I think that IBM put a lot of technical resources into FORTRAN, but I don't know that they did much marketing. They didn't need to, because the alternative was assembly. Once you knew that FORTRAN existed, that was enough.
> The number one reason for Go’s success is that Google backed it.
Google certainly did not back Go in the way that Sun backed Java. I'm old enough to remember when Java came out. Sun did a lot of marketing that was aimed at managers rather than engineers. I have never seen Google do that for Go. If they have, it has escaped my notice, which is possible, but I'm still going to claim that they haven't done it on anything like the scale that Sun did with Java.
You can claim that holding a conference is marketing. It could be considered so. But getting non-technical puff article after puff article in the trade press is marketing on another level, which, to my knowledge, Google has not done.
What Google has done is put technical effort behind Go. They've written libraries and tools. They've let people give the language direction. Go probably would not have gone far if it was just Rob Pike's side project.
If "marketing" means anything, it means money buying influence, independent of actual users. It might be spent on press, "analyst" puffery, huge library developments, book projects, and lavish conferences, as Sun did for Java.
Money spent developing compilers and libraries to sell at a profit is not marketing, even if the compiler is marketed: that money comes from users already committed.
C didn't need marketing. It rode on Unix, which also got hardly any. Unix rode on workstations, which had to be marketed hard against all the minicomputer and, later, mainframe competition.
C++ got no marketing either. It still has none, yet the number of C++ programmers is growing faster than ever before. Complaining about it is always popular, but as Bjarne says, there are only two kinds of language : the ones people complain about, and the ones no one uses.
Go may be counted a success when it is complained about as much as C++ or Python.
C had free marketing from universities taking an OS for a symbolic price, with source code available, instead of having to pay for something like VMS.
C++ had plenty of marketing, being adopted by all major C compiler vendors, it was adopted by the GUI frameworks used by Apple, IBM, Microsoft, alongside Borland, Zortech, Symantec, Watcom, Microwerks.
"Invading"? Seriously? How many guns did they put to how many peoples' heads?
Universities wanted Unix and C, and not because AT&T spent so much on advertising. Not because AT&T forced it on them. The universities wanted it because, from their perspective, it was better than the other options. That's not marketing. It's not invading. It was pull from the universities that made it happen, not push from AT&T.
Producing something that people want is not the same as marketing, no matter how much you want to conflate the two.
Universities did not want to pay. Therefore, of the available options, they wanted UNIX. Why is that so hard for you to accept? [Edit: On reflection, my comment here is unjustly harsh. That is the gist of your second paragraph.]
Yes, AT&T shipped them a tape. Yes, technically that falls under the grounds of "marketing". The impression you are giving of how this played out, though, is totally false. You're making it sound like AT&T was aggressively pushing UNIX. It wasn't. It was much more passive - shipping a tape when requested. People were coming to them; they weren't going to people.
> The Unix operating system was first presented formally to the outside world at the 1973 Symposium on Operating Systems Principles, where Ritchie and Thompson delivered a paper. This led to requests for the system, but under a 1956 consent decree in settlement of an antitrust case, the Bell System (the parent organization of Bell Labs) was forbidden from entering any business other than "common carrier communications services", and was required to license any patents it had upon request.[6] Unix could not, therefore, be turned into a product. Bell Labs instead shipped the system for the cost of media and shipping.[6] Ken Thompson quietly began answering requests by shipping out tapes and disks, each accompanied by – according to legend – a note signed, "Love, Ken”
So: They gave a talk at an OS conference. When people asked, they shipped a tape. The only thing less than that they could have done is not give the talk and not shipped the tapes. Which, had they done so, it is true that UNIX would not have taken off.
Which technically makes your claim true. But if you define marketing that broadly, it also makes your claim completely uninteresting. It boils down to "Things that are developed in house, and never talked about to anyone outside, and never shipped to anyone outside, do not take over the outside world". That's true, but it's trivially uninteresting.
You seem to be much more focused on the technical definition of marketing than on the very real differences between the "marketing" of C and UNIX vs. that of, say, Java.
And back to the original point: The marketing of Go has been much closer to the "marketing" of C than to the slick sales job of Java.
I mean on one hand, sure. Google undoutably provided Go with a much needed ingredient, developers.
But on the other hand, I think it is unfair to attribute Go's success solely to Google. If that was the case, where's Dart's massive success? This isn't like Swift either, where Swift is the key to modern iOS development; Go is just another option for a few types of targets.
I don't understand the unwillingness of people to accept the success of Go as being more or less natural. There's articles from entities like Digital Ocean explaining how Go naturally invaded their stacks. There's a lot of merit in Go. It being backed by Google is actually going to deter some from wanting to use it, no doubt.
Google is one of many companies that had the resources to create Go. I don't believe it was out of reach of many larger tech companies. Including Mozilla. Nobody attributes Rust's appeal or success to Mozilla, because they are comfortable pointing to its many benefits as reasons. And that is correct in my mind. But when it comes to Go, people are unwilling to admit that it is simply an appealing option with its own merits, and I think that is unfortunate.
Full disclosure: I speak as someone who works for Google now. But, I adopted Go before joining Google, back in around 2013, where it went to take over many important roles we'd otherwise had used Python or Node.JS for. I did not learn it was a Google product until later down the road.
I agree that there are many intrinsic reasons for Go's success, but I would argue that there's no way it would have the popularity it does today without Google.
There are dozens of interesting languages out there. D, for example, seems like an interesting language, and I would love to try it out in a professional project. But if I wanted to use D at work, it would probably take weeks of convincing my team to try it in production. Go already seems like a safe choice, largely because of the "seal of approval" granted to it as coming from a tech giant like Google.
I understand this line of logic, but are you suggesting you’d get the same approval to use, say, Dart?
(I am not talking down Dart - I think it’s underrated. But it’s a good counter example to the “it’s Google so it’s OK” logic. I suspect people say Google is the reason Go is OK even when it’s actually more word of mouth.)
I think it's always a mix of things which lead to the success of any language ecosystem. I think Go has at least 3 things going for it:
1. It got the *initial push* from its Google pedigree which allowed it to gain attention and traction
2. It meets the *merit threshold* so that when people gave it a try, they wanted to continue using it
3. It had a good *product market fit*: in the world where Go was released, *a lot* of server-side software was being written in scripting languages and there was a clear value proposition for a fast, compiled, statically typed language with good tooling for handing server work.
I think Dart fell down on that third point. Front-end development is very different from back-end, and people already had toolsets they were familiar with based in Javascript. Switching to Dart would have meant throwing out all these separate inter-operable tools and betting on a new paradigm.
I think that's why something like React or Typescript could really explode in that space: they could be added incrementally to a project while still keeping most things familiar.
You can benchmark it against Dart, which came out of Google around the same time. Go seems to be doing about twice as well: https://www.tiobe.com/tiobe-index/
Dart is practically a DOA project, just like NaCl. These projects failed for the same reasons - they were trying to radically change how you built software on the web, and the world was absolutely not ready for it. DART was going to be a separate VM in your browser and, of course, only Chrome supported it. It never could have succeeded in that role.
No language has usurped Javascript for frontend, and the only two approaches that may work are:
a) Typescript, which intends to be very close to javascript
b) Webassembly, which has taken years to get off the ground
Go didn't have that problem to contend with. I don't think it's fair to say that because Dart failed to take off quickly that proves that Google isn't the main reason for Go's success.
edit: I see lots of "Dart is a counterexample" posts. It really shouldn't be considered one.
Also I think that Go didn't come out of nowhere. It is closely related to past languages that were used in production and research, like C or Limbo.
Of course Dart adopts a lot of concepts people love from other languages. But to me it feels really artificial and disconnected from what developers successfully used in the past. It maybe worked in the 70s that people came up with a completely new language and people used it because there was nothing else.
Dart has gained more success since moving away from the "new browser language", which was an impossible task in retrospect.
I think Dart is, in fact, an excellent example of how much power Google is willing to throw behind a language. Dart was constantly marketed on the Chrome blog, for example.
I think that’s also why angularjs was so successful. Fast forward a couple of years and despite everyone having to switch to vue or angularX, and it having a 40% “used but would avoid in future” reviews, it lives on as it’s commonly disliked successor. It’s main competitors/successors are created by another big name tech company and a former employee of one.
On my phone so I can’t find a link to the “would not use again” stat, but there are a few surveys with similar results that are easy to find
I don't think having a big internet company backing it is a sure success. Google also backed Dart and as far as I'm aware it's still a niche language.
Facebook created Hack, which I have yet to see in the wild (mind you I'm not really in the PHP bubble at the moment).
Apple used Objective-C and created Swift, but you don't see either of those outside of the Apple bubble and as far as I know Swift is just not used for back-end.
So I mean I hear what you're saying, but there's plenty of counterexamples.
Thinking about your point, it does mostly seem to be true. But I'm wondering why it's true only for compiled languages, and not true at all for interpreted languages.
my guess would be that compiled languages are very heavily used in enterprise environments and companies will look for corporate long-term backing before they commit resources to a language.
Dynamic languages are more generally used and often have been favoured by small companies and teams, so the barrier is lower.
dynamic languages are languages who perform many central operations, like type checking at run-time rather than at compile type. They facilitate changing the object system, and a host of other things too long for the post. (https://en.wikipedia.org/wiki/Dynamic_programming_language)
I was playing a little lose with language because the OP was talking about interpreted and compiled languages, and not all interpreted languages are necessarily dynamic, but in practise the fault lines are about the same.
This is changing because of LLVM. It is now very easy to implement AOT compilation for your programming language.
However, implementing an efficient garbage collector in an AOT compiled program is still challenging compared to an interpreter where the stack and each object is just an array of object references. With raw memory you don't know whether something is a number or a reference unless you store extra information that describes the memory layout of every single function or object.
I'd say it's actually because of Graal. LLVM is helpful for writing a compiler but only changes the difficulty by say, one or two orders of magnitude. But the difficulty of making a fully statically typed compiled language is many orders of magnitude larger than one guy hacking together an interpreter.
The nice thing about GraalVM and modern gradual typing techniques is you can actually start by writing an interpreter, fully dynamic, no type system at all. Graal turns the interpreter into JIT compiled code on the fly, you can even create a standalone (no JVM) AOT compiled binary containing your language runtime, all with one command. Then as your language evolves you can add interpreter hints to gain extra performance, but, it's totally pay-as-you-go. There are no walls of effort facing you: you do a little work to get a little benefit, and a lot more to get to V8 type speeds. You can also introduce a type system gradually these days, as CoffeeScript/TypeScript or Groovy style languages do, again incrementally as your language evolves and gains usage.
Also with Graal you get the world's best GCs for free, plus access (if you want it) to the JDK class libraries for things like files/sockets/time&date handling. Oh, and language interop with other languages for free, no complex FFIs. It's pretty neat.
That said, are there lots of programmers itching to write dynamically typed scripting languages these days? Probably not. Languages like Kotlin deliver most of the benefits with very few of the downsides.
I'm assuming by success you mean some adoption, like top 20 languages maybe? Marketing is, of course, necessary for that, but far from the whole story. Because we also had Perl, PHP, Python and Ruby that don't fit your explanation. It's just more complicated, the language competes with other languages, has to somewhat address some of the obvious easy to understand problems of competing languages and be not scarily unfamiliar, but easy to pick up, and so on.
> Because we also had Perl, PHP, Python and Ruby that don't fit your explanation.
That is why I specifically called out compiled languages. Perl, PHP, Python, and Ruby are all interpreted languages. For some reason, interpreted languages seem to be able to do ok without a big company backing them, but compiled languages seem need a big company to back them.
I think the distinction is between statically typed and dynamically typed languages, which for other reasons lines up with compiled vs. interpreted.
A lot of the benefit of statically typed languages are the tooling around them (IDE integration/autocomplete/error messages). These represent a fairly expensive (resource wise) area of investment and so the resources of a large company has high ROI.
I'd say Go's success is almost nothing to do with its design, and everything to do with social factors.
Rob Pike was famous before its creation (within the relevant community). The language was designed within Google, and gained much hype from that. The effort to foster a community paid dividends.
Writing Go code for a living, I find it a very mediocre language. It's largely redeemed by its library ecosystem, which reflects not on the language, but the enormous size of its community and commercial backing.
If anything is noteworthy about its design, it's that it's simple (crucially, to those already familiar with C-like languages), and easy to bring people on board. What is lost for want of features and abstractions, is gained in human resource.
I have the perception that Go is more optimized for meeting organizational needs than programmer needs: it's simplicity and limited abstraction make it more difficult to write complex, serpentine code which is difficult to understand without a deep knowledge of the codebases.
For an experienced developer that might feel a bit like handcuffs: like you have to write more redundant code and handle things at a more literal level than you could get away with in other languages.
However, it tends to result in a codebase that's more resilient to turnover: if someone new joins the team there's going to be less specific understanding about the inner workings of the codebase they need to sit down and understand what they're looking at. It also limits the damage a mediocre developer can do through overuse of bad abstractions.
I agree with your last paragraph. However, I assert that the virtues you name there are in fact more for meeting organizational needs than programmer needs.
And that's fine. As a software system gets bigger, the organizational issues come to outweigh the programming ones.
I think we are in agreement. My assertion is exactly that Go favors organizational needs over programmer needs, and the examples I gave are evidence of that.
I'm not making a value judgement over whether that priority is a good or a bad thing, just an observation about the nature of Go.
I think your last paragraph is key here. Go is a simple language, which makes it practical for large projects, with many collaborators, some of whom might be fresh out of school. Google must have benefited internally a lot by Go.
Exactly. Scheme has not been a success in part because it lacks needed features. Go has just enough for its uses, and no more. It's not powerful enough for really serious projects, but (1) there are already other languages for those, and (2) the overwhelming majority of projects aren't.
Early adopters of a language tend to be relatively highly skilled and tend to write better code, while when language becomes enormously popular the majority of software written in it tends to revert to the mean.
I'm not sure that principle applies well to JavaScript. It was popular almost from the get-go, being the only language of the Web. A lot of bad practises were popular in the early days.
JavaScript has changed a lot as a language over time -- ECMAScript 2019 makes it a lot easier to write good code than the original JavaScript. It's now better understood how to write JavaScript code, and how not to.
IMHO, Oberon-2 WithStmt has much cleaner syntax than Go TypeSwitchStmt.
WithStmt is easier to parse, more general and it doesn't need the Primary "." "(" "type" ")" at the beginning which appears only needed to distinguish Go ExpressionSwitchStmt from Go TypeSwitchStmt.
Don't discount ease of distribution due to creating giant rolled up binaries.
The size of binaries isn't that big of a deal for servers any more. On the other hand, setting up a python or whatever env can be a pain, especially before docker really took off. Being able to push a Go binary and it Just Works is awesome.
It amazes me that Python is used in production back-ends. It's a neat language with a lot of nice libraries, but the environment management story feels so janky to me. Not to mention all the money you're spending on just the overhead of a relatively fat, slow interpreted language.
One point I would add is how easy it is to onboard people.
With minimal training every programmer can learn go very quickly and be productive in it.
This is very important for companies because you don't hire a Java, C# or whatever dev but someone who is a good fit for the company. And then you have him trained in no time.
That fact alone was the easyest sell I ever made to my boss.
It's backwards. Attributing things to Go's success vs. attributing Go's success to things.
Things someone attributes to Go's success would be things caused by Go's success. For example, the proliferation of stuff written in Go, the number of people making money as Go experts, the appearance of a Go entry in Wikipedia.
Things to which someone attributes Go's success (i.e. so-and-so attributes Go's success to these things) would be things that caused Go's success - such as the things in the article.
Headline could've been done correctly, but perhaps the problems started with digesting something by Rob Pike and turning it into a listicle. Which then has to have both its listicleness ("five things") and the presence of Rob Pike, advertised in the headline. But I might be being cynical.
The way it's written means "things we believe are the result of Go's success", not "things we believe are the cause of Go's success". It's a word order issue. You attribute the smoke to the fire.
The reason why Go is successful is because it's a very, very opinionated language, and for the most part its users agree with those opinions. And the opinions that they don't agree with don't detract as much as the opinions that they like.
By being highly opinionated and predictable, it makes it easier to digest. I especially like the reformatting capabilities so everyone's code looks the same. The more people program the same, the more predictably the code behaves and the less overall problems.
By that I mean it isn't the best in any criteria that you'd use to evaluate a programming language: not the best type system, not the fastest, not the safest, not the best concurrency, not the best package manager, not the largest ecosystem, not the easiest, and so on.
However, it's very good, sometimes great, in many of these criteria. Many languages try to be the best at one thing, while Go is good enough in many things.
Incidentally the title (and similar line in the body) are incorrect descriptions of the content; these are not things that Rob Pike attributes to Go’s success, but things to which Pike attributes Go’s success. The current phrasing literally reverses cause and effect.
Probably in that it's the language with first-class support on that platform. Adoption of the language is encouraged more by the target platform's support for it, than by its independent merits as a programming language.
I'm not sure I'd agree though; Swift shares this position with its predecessor Objective-C. Swift's success versus Objective-C can be attributed to its relative merits as a programming language.
Despite the fact that what's written is the title of the linked article, it seems that these are "[5] Things Rob Pike Attributes Go's Success to" (i.e., the causes of the success), rather than "[5] Things Rob Pike Attributes to Go's Success" (i.e., things caused by that success).
"Things to which Rob Pike attributes Go's success", whatevs. My point is that the direction of attribution according to the title is the other way around from that in the article.
I find this list a bit disappointing and not particularly insightful. I think that its because a lot of success is timing and luck (in addition to something being good), so it's like asking a startup founder why their startup was successful and not another.
For example:
- is errors on unused variables/imports really such a bold new stroke or that controversial?
- is a formal spec that unusual? how many Go developers have ever looked at the spec?
- was getting Docker that big of a deal other than having a good dogfooder (vs it being "killer")
I agree with the open source process, kudos for them for allowing the community to help them get things right (well, some things, Go has a bunch of rough edges).
IMHO, its:
- Good runtime perf
- Great built in libs
- Built in cross-compilation and shrinkwrap binary that does not require a runtime installed on target machines
- Good use of opinionated tooling (go fmt, go test, etc) that take a bunch of concerns off developers plates
Having formal spec, and focusing on code stability is important, and puts them apart from 9 out of 10 of every new programming languages, but that is only one item on the long "not suck" list.
The lack of proper package management at the start left too much of a bad aftertaste.
I believe they must have knew that shipping go with git as a makeshift package manager was a bad idea, but for some reason did it anyway. I think this alone turned away half of early adopters.
Then golang went through a long epopeia of making the package ecosystem work outside of a single company deployment, and lost a lot of developers along the way again.
He forgot the most important factor to Go's success: ignorance is bliss. Imagine releasing such a mediocre language only a decade ago an still be very popular
Golang has shortcomings a plenty, although that doesn't necessarily make it a poor language to use.
It's a fairly simple language, which makes it relatively easy to grasp and understand the majority of Go code. This is particularly useful for group development (i.e. in companies), where you want everyone to understand each others' work.
Anecdotally, although I prefer to write Rust, and consider it a better language in many ways, it took me a lot longer to learn the language, and longer still to write idiomatic Rust code. I was up to speed with Golang relatively quickly.
Not the OP, but I think a good contrast is with Rust. Both languages purportedly emphasise memory safety and concurrency. Rust achieves this within the type system at compile-time; no nil pointers (conditional destructuring is used instead), no garbage collection is required, and concurrency is safe by virtue of compile-time checks. In Golang nil pointers exist and can be dereferenced, you can make a mistake when using concurrency primatives, and clobber shared memory.
On the other hand, Golang is a much simpler language. It's relatively easy to learn and understand.
Some popular Rust projects include actix-web (HTTP serving), diesel (database ORM), Firecracker (micro VMs for serverless). Web APIs and virtualisation / cloud computing are also areas where Go is popular.
They're both statically typed compiled system programming languages; both trying to provide solutions for safe memory and concurrency.
Criticizing Golang here in HN will get me banned for causing flamewar. However, you can find lots of reasonable criticism on Golang just by googling. IMO Golang is one of the worst languages I've ever seen considering it was only started a decade ago.
Once I listed around 10 technical criticism points here a year ago without insulting and I got banned. I am just not going to waste a day trying to convince anybody with anything while most of the criticism has been stated a million times by a million people all over the internet.
Well, I haven't read it, nor have I seen much other criticism of Go. If you post here, it is up to you to make your argument, not for your readers to seek it out.
I have seen plenty... but not all that much substance. Much of it had the form of "How could they be so stupid to make those design choices!", as if the author's preferred approach was The Only Right Way. I've seen criticism that said "They couldn't have known anything about Modula 3 for them to make that choice!", when in fact Rob Pike talked about stealing an aspect of the object file format from Modula 3. Yeah, he knew it, and probably knew it in more detail than the critic did.
Apart from "They should have done it the way I like!", the main criticism I have seen is lack of generics. That's a pretty common complaint, from a lot of different people.
> Criticizing Golang here in HN will get me banned for causing flamewar
that's either reductive or a strawman, if not both. afaict golang doesn't lack for criticism on hn, but most people do so without being insulting or hostile.
If the rules are consistent and persistent, then you should be banned again as you have criticized Golang, but furthermore, provided zero substance to back your criticism.
Yours is not criticism, it's just ignorant bashing of a perfectly productive language that people adopted not because they're more stupid than you but because it made them more productive for whatever reason.
No one forces you to code in Go if you don't like it. Fine, but don't belittle others if you're not prepared to understand why it's got so popular. Ignorance is bliss.
It is way, way too early for him to proclaim Go a success.
The time for that is ten years on. Imagine reading something so self-congratulatory, today, if the creator of Ruby had written one back when Ruby was only as old as Go is now. It would be poignant.
Go will be a success when it is complained about as much as other languages, by people who would really rather be using something better. It is nowhere near that point.
There are a lot of very nice languages out there. However, if you look at compiled languages, they largely need a company backing them. Java had Sun. C and C++ had AT&T and later Microsoft for C++. Objective-C had Apple. FORTRAN had IBM.
Don’t underestimate the amount of resources and press that Google’s support brought to Go.