10 ms·

I think it misses * Made by really famous veteran language designers * Backed by Google Not saying it doesn't deserve its popularity, but most of the things

I think it misses * Made by really famous veteran language designers * Backed by Google Not saying it doesn't deserve its popularity, but most of the things listed are not necessary for explaining its popularity, and none of them (even taken together) are sufficient.

eb0la 4y ago
In my case "backed by Google" was a deterrent, not a feature. I gave the language a chance after trying Rust (backed by Mozilla - which was a feature to me ;-) and I found it easy to start. Go is very well documented: That was the killer feature for me. No more search tutorials / videos etc. - just get the go book, read it, and start coding. Of course there are tutorials and videos everywhere for fun stuff. But good documentation is more important than we think - even in the 21st century!
- intothemild 4y ago
  I agree here. Using the two examples go and rust, Go's documentation is on another level compared to rust, it's more common to see examples in Godoc's than in Rust documentation... That's not a failure of Rust or the maintainers, it's just a different culture I guess. If I want to do something in Go with a new lib, i can easily put together what I need to do using the documentation. Where as with Rust, it's often confusing to the point where if they don't have an examples folder on the library, I'm shit out of luck understanding how to do something.
  - gameswithgo 4y ago
    I don't think Go's documentation is better than Rust, Go is just a lot simpler than Rust. Especially if you are a programmer with a background in any of the C-ish syntax languages (C,C++, javascript, Java, C#, etc), its just really easy to pick up. Rust is a mind bending ordeal by comparison with both the borrow checker and other foreign ideas that take a while to come to terms with.
    - tptacek 4y ago
      They both have good patches of documentation and bad ones. They're both better documented than, say, Ruby. Go has multiple edges, not just simplicity, but also a larger user base. You couldn't reasonably disqualify either language basd on their documentation. Certainly, Go is easier to pick up than Rust, but nobody's arguing that.
    - Matl 4y ago
      > I don't think Go's documentation is better than Rust, Go is just a lot simpler than Rust. Having used both I disagree; Go's stdlib is extremely well documented, even unexported types are along with examples etc. Rust docs are useful but more often feel like there's many things you're expected to figure out from the source and only minimal examples are given. I am a fan of Rust, but I think Go's docs are an example to follow. The more complex the language, the richer docs it should have imo. Quite aside from docs, Go's tooling situation is also better.
  - deleted 4y ago
    [deleted]
- pornel 4y ago
  Note that Golang is older than Rust. When it came out it made a splash, despite not having any books or videos yet, despite not having any libraries available yet. It didn't die in obscurity (like someone else's "Go" language that existed before!) precisely because it had names of Rob Pike & Google associated with it.
  - johannes1234321 4y ago
    Yes! The "killed by Google" meme is young. Back in the days it was like "i want to be like Google" (ignoring the fact that most people don't have scale like Google and very different problems) and anything out of Google must be good!
    - vintermann 4y ago
      It still is. Google may be killing off its site-products, but not its own software. A lot of open source software Google made for its own consumption (Kubernetes, Tensorflow, etc.) has become pretty much industry standards, despite everyone saying they're a lot more awkward to use outside of Google than inside.
    - jerf 4y ago
      Google also can't really "kill" Go. The license doesn't permit it. They could stop supporting it, at which point the community may or may not pick it up. (I'm inclined to think they would, but I can't guarantee that.) They could try to drag it in some hypothetical super-Google oriented direction (integrating Google Cloud somehow deeply into the language?) but they haven't yet, and at this point, again I think the community would fork and move on. It's not a service they can pull the plug on, it's a software package that would still exist even if the entire Google organization went poof tomorrow. Because if it was a service they could just pull the plug on I would never have started using it.
      - johannes1234321 4y ago
        I can't judge, as I have neither any insight into the development structure (how many non-Googler so relevant work) nor complexity (how many understand the deepest details of the compiler etc.) but I have seen different Open Sources Projects die a slow death after the primary developer went way. Everybody depended on the "free" labour being done and once gone one couldn't find agreement on how to go on. But yes, Go's spread is big enough that it won't immediately die and Google would probably be responsible enough to transfer to Linux foundation or ASF or somebody who can help to organize a new structure. Anyways, key point was that Google reputation was different, when Go took up. I can imagine if it would launch now it would find different reaction, which could prevent a community forming, thus less of safety.
- bakuninsbart 4y ago
  Google doesn't have the best track record of maintaining their projects, but I've had a similar experience with Android/Kotlin. Always had a dislike for "strong" OOP, but then had to do a small android app for a university project, and the tutorials, documentation and tooling for Android with Kotlin were pretty amazing. This took away most of the problems of understanding the syntax/language and gave me the leeway and motivation to get a better understanding of the concepts. My dislike for OOP is now at least partially cured.
  - usrusr 4y ago
    Surprised to read that! Android has that "initialization through mutation in a set of lifecycle callbacks resembling plate tectonics" so deeply baked in that even kotlin just shrugs and learns to love the lateinit. I consider that a prime example of how OOP can lead one astray.
- traceroute66 4y ago
  To me, in the old Go vs Rust debate, there are two things that are abundantly clear in making a compelling case for Go. First, I don't think even the most devoted rustacean can deny that Rust has a hell of a learning curve. But perhaps most importantly is that Go has a strong and extensive standard library that covers many 21st century applications (e.g. talking to REST APIs). The problem to me with the Rust "no stdlib" model is it leaves you with two equally unattractive options: 1) Write the library yourself (and leave yourself with the associated technical debt of maintaining it) 2) Figure out which of the often dozens of third-party Rust crates you want to use (and rinse and repeat the selection process for every library, and then expose yourself to third-party maintenance debt).
  - usrusr 4y ago
    The most interesting thing about the go vs rust debate is that it happened. In hindsight it seems abundantly clear that they aim for entirely different fields with negligible overlap, almost as if you'd lump together tennis and golf because they are both ball games with a somewhat upperclass bias ("how different can they be? And I hear polo is the same but with horses!"). But back then? Yeah, I was kind of expecting one of them to "win".
    - kjksf 4y ago
      Rust and Go are both general purpose languages. They overlap way more than they don't i.e. there is way more software that you can write in both languages than software that you can write in only one of them. The "best language for the job" is mostly a myth. The choice of language is mostly dictated by what you cannot do, rather than what you can do. Can I use Go or Java to program a micro-controller with 128 kB of RAM? Not really (at least no using the official, non-crippled implementation) because even "hello world" in those languages exceeds that 128 kB limit. If I'm writing a cmd-line app that I want to ship as a single binary for Windows and Mac and Linux, I'm not using Python. Technically it's possible but very few are doing it while Go gives me out of the box multi-platform compilation. The reality is that the majority of software written today falls into one of those categories: * web frontend, running in the browser, by necessity written in JavaScript or something that transpiles to JavaScript. Both Go and Rust are out of this game * web backend and similar server software: both Rust and Go compete for that * command line apps : both Rust and Go compete for that * games : AAA games are pretty much C++, Go and Rust are out (although Rust could, in principle, work) So in most cases both Rust and Go are unsuitable for the task or they compete for the task.
- usrusr 4y ago
  I suspect that documentation quality is part of "by veterans", people old enough to have a considerable part of their programming biography set in the days before Google driven development. Slightly ironic.
- christophilus 4y ago
  > In my case "backed by Google" was a deterrent, not a feature. I'm the same. For me, it was some combination of: - I can build useful stuff with few dependencies - I don't have to wait seconds for compilation - I can trivially build, scp the build artifact, and run it
- krylon 4y ago
  The documentation is a big point, but to me, two other points are just as important, maybe (probably) more so: 1. The standard library is very good in the sense it covers a fairly wide range of areas and gives you some idea of how to use Go idiomatically (I feel this is more important in Go than in other languages I've used). 2. The language just feels right to me. I have not met any other language that feels like it was optimized for my brain that well. I recently made an attempt at learning Rust, and I kind of got it, but I eventually gave up because the benefits did not seem worth it to me in light of the steep learning curve. Go just clicks with me. It's not the best language ever by whatever metric you choose, but for my needs, it is the right language.
CraigJPerry 4y ago
>> Made by really famous veteran language designers Yeah that’s a positive >> Backed by Google But that’s a negative, https://killedbygoogle.com/ https://killedbygoogle.com/ I definitely think you’re too fast to dismiss the language features contributing to popularity. As an example: Fast builds are a positive developers immediately warm to when they experience them (stand by for rustacean “i need time to make tea and my compile times are exactly the right length for tea break” type comment). The example of the 4.4mb c++ project that results in the compiler ingesting 8Gb of data is eye opening. C++ needs to resolve type information for all includes and all their includes and all their includes… go only needs the interface so compilation can be done without all that effort.
- ampersandy 4y ago
  I really dislike this meme of pointing out that Google has deprecated a lot of projects. Do people actually expect Google to staff people & resources running every project they've released forever? A more interesting comparison would be open source projects that Google has abandoned or failed to properly hand over control of to the community, especially if we're talking about Go.
  - UncleMeat 4y ago
    I agree. It is true that Google has some poor product management and has some hilariously inept examples or product coherency (chat being the biggest disaster). But people praise startups for pivoting (read: killing a product) and (in general) demand innovation over glacial iteration. Trying new stuff necessarily means killing things that don't work (or paying a whole bunch of engineers to maintain a dead product for eternity).
    - cy_hauser 4y ago
      >> But people praise startups for pivoting ... Yes, but you discount the size of Google. Some of the things Google has killed have been large enough to have been considered successful products for a startup. They kill a "tiny" product because it's only large enough to be what some startup hopes to become. Google Reader is my favorite example of this. Multiple companies now exist in the soil on top of that grave.
jasode 4y ago
>- Made by really famous veteran language designers - Backed by Google Looking at decades of how various programming languages gain popularity, those proposed reasons don't seem that convincing when we look at counterexamples. E.g. counterexamples of unknown (at the time) creators creating popular languages : Bjarne Stroustrup (C++), James Gosling (Java), Rasmus Lerdorf (PHP). E.g. counterexamples of famous computer scientists creating languages that were not widely adopted : Alan Kay famous for Smalltalk but Squeak is not widely used, and Niklaus Wirth famous for Pascal but later Oberon not widely used. I think Go's popularity is mostly explained by technical reasons: 1) compiles to a single executable that's easy to deploy. This is a compelling advantage over Java,C#,Python,Ruby that require runtimes or complicated virtual environments. 2) a good enough standard library that's useful for quickly programming middleware type of apps on servers. Server-side infrastructure apps are Go's sweetspot. Go's a better productivity baseline than C++ and Javascript with their bare standard libraries that requires researching "what's the best library?" on Stackoverflow or browsing NPM repos. 3) "go routines" which some think of as the "killer feature" because that concurrency mental model is easier than threads or async/await. I'm guessing those 3 tech reasons attract more programmers than people that think "Rob Pike and Ken Thompson are famous guys at Google so I'll use Go". Regardless of celebrities, the language itself still has to have some compelling technical advantages for it to grow in usage.
- pjmlp 4y ago
  C++ was born at AT&T, shared the UNIX throne with C, adoption grew from there. Java was created by Sun, was remarkable in having the JDK available as free beer in the age of comercial compilers, Sun bankrupt themselves pushing Java everywhere. PHP provide a saner way to use a Perl like language on ISPs, whithout the mess of mod_perl, while most ISPs would charge extra for something else. Smalltalk was gaining adoption, before its main backer outside Xerox (IBM) decided to join forces with Sun and Oracle, and move into Java instead, famously rewriting their flagship product into Eclipse. One of the main architects behind this effort is now leading Visual Studio Code development. Compiling to single executables has been the way compilers worked before dynamic libraries became widespread in 32 bit platforms.
  - 4y ago
Zababa 4y ago
We can sort of evaluate of much "backed by Google" means by looking at other languages backed by Google. The main one I have in mind is Dart. Here's a few links: - https://madnight.github.io/githut/#/pull_requests/2021/4 https://madnight.github.io/githut/#/pull_requests/2021/4 - https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/ - https://redmonk.com/sogrady/2022/03/28/language-rankings-1-22/ https://redmonk.com/sogrady/2022/03/28/language-rankings-1-2... Dart seems to be doing relatively well. Considering Go has more things in its favor than Dart, it's logical that it's doing better. Still, the Google boost seems to be really big.
- mikymoothrowa 4y ago
  Dart is barely doing well. It was pretty much dead before Flutter kind of imposed it. Dart is actually the counter example for “ Backed by Google “
- kyrra 4y ago
  (Googler, opinions are my own) Similar to the peer comment to me, Dart languished for a long time. You have to remember Dart was created as a replacement for Javascript and that they wanted other browsers to embed the DartVM in their browsers. This got absolutely rejected by Mozilla, Apple, and Microsoft. They then attempted to use it as a transpiled language, but it always generated larger javascript files than most other solutions. It still exists and is used, but Typescript ended up being a better solution. (note: there is AngularDart, which is a bit of a fork/mirror of Angular, but for Dart). This has some uses within Google as I understand it, but it's usage outside of that is rather small. Flutter using Dart ended up being a large boon for the language and drives much of the changes to the DartVM. Dart had to go through various targeted usages before it really found a home.
  - Zababa 4y ago
    And even with all those troubles, it's still doing better than many many programming language, which was my point. The Google boost seems to be real and big.
dang 4y ago
(Submitted title was "What made Golang so popular? The language’s creators look back". We changed the title when we changed the URL - see https://news.ycombinator.com/item?id=31571574 https://news.ycombinator.com/item?id=31571574)
lifefeed 4y ago
The "Backed by Google" is an under-appreciated social piece of the puzzle. It's not just that Go has institutional backing, it's that googlers produce a lot of startups, and they bring their favorite things with them, and quite often one of those things is Go.
- earthboundkid 4y ago
  That's why we all use Dart today.
  - zero_shift 4y ago
    Dart created a lot of interest at the time. The main reason it didn't take off was that Google couldn't convince MS or Mozilla to embed the DartVM in the browser. Golang obviously didn't have that constraint, it didn't depend on any external runtime. After the browser rebuff Google had a meandering approach to figuring out where Dart could fit in instead. Whereas Go slotted quite easily into one specific niche, building microservices at Google. I think the lesson is that clear positioning is crucial
deleted 4y ago
[deleted]
paskozdilar 4y ago
For me, Go solved a lot of issues that I've had with both C and Python. C is a nice language because there's no magic happening - functions are only executed if they are explicitly called. However, C had problems with strings, memory management, resource cleanup, undefined behavior, and probably a few other things I can't recall at the moment. It was also not designed with concurrency in mind, and glibc for some reason doesn't support static linking. Python is a very nice language to work in, but there is a lot magic going around with all those Python protocols and magic methods. I also find myself making a lot of errors using exceptions - exceptions can happen at any point and there is no way to anticipate them, other than documentation, which leads to try/except boilerplate. And if I want to handle exceptions on a more granular level, I find myself writing try/except for every line I call, which is 2 lines of boilerplate - same as "if err != nil {" and "}". Also, CPython has a lot of dynamically linked dependencies, which makes containerization more difficult. There's PyInstaller, but PyInstalled doesn't seem to play well with non-pure-Python modules (uwsgi, for example). And concurrency in Python is terrible because of GIL, and asyncio is far from perfect, considering function coloring and inherent single-threadedness. Go managed to become a language with a feel of Python but with certainty of C. It's like someone took C, fixed strings, added anonymous functions, automatic memory management, defer keyword for resource cleanup, sane concurrency model with channels and select. I think the name "select" comes from the Linux select syscall which allows you to wait for multiple file descriptors until one of them is ready - same thing happens with select and channels in Go. The select syscall (and its descendants) is the bedrock on which the whole asyncio world relies upon, so Go's concurrency design is already proven in practice. When I write Go code, I'm rarely worrying about an exception popping out of somewhere. Panics do happen, but in most cases, they are caused by truly exceptional errors and warrant a crash. And even though it's not a "systems language" in a kernel sense of the word, I've used Go to write video4linux applications, so it is certainly capable of making ioctls and manipulating C-like structures. Also it's statically linked, so it's possible to make really small containers with it, and easily cross-compiled, which is nice for portability.

eb0la 4y ago

In my case "backed by Google" was a deterrent, not a feature. I gave the language a chance after trying Rust (backed by Mozilla - which was a feature to me ;-) and I found it easy to start. Go is very well documented: That was the killer feature for me. No more search tutorials / videos etc. - just get the go book, read it, and start coding. Of course there are tutorials and videos everywhere for fun stuff. But good documentation is more important than we think - even in the 21st century!

intothemild 4y ago
I agree here. Using the two examples go and rust, Go's documentation is on another level compared to rust, it's more common to see examples in Godoc's than in Rust documentation... That's not a failure of Rust or the maintainers, it's just a different culture I guess. If I want to do something in Go with a new lib, i can easily put together what I need to do using the documentation. Where as with Rust, it's often confusing to the point where if they don't have an examples folder on the library, I'm shit out of luck understanding how to do something.
- gameswithgo 4y ago
  I don't think Go's documentation is better than Rust, Go is just a lot simpler than Rust. Especially if you are a programmer with a background in any of the C-ish syntax languages (C,C++, javascript, Java, C#, etc), its just really easy to pick up. Rust is a mind bending ordeal by comparison with both the borrow checker and other foreign ideas that take a while to come to terms with.
  - tptacek 4y ago
    They both have good patches of documentation and bad ones. They're both better documented than, say, Ruby. Go has multiple edges, not just simplicity, but also a larger user base. You couldn't reasonably disqualify either language basd on their documentation. Certainly, Go is easier to pick up than Rust, but nobody's arguing that.
  - Matl 4y ago
    > I don't think Go's documentation is better than Rust, Go is just a lot simpler than Rust. Having used both I disagree; Go's stdlib is extremely well documented, even unexported types are along with examples etc. Rust docs are useful but more often feel like there's many things you're expected to figure out from the source and only minimal examples are given. I am a fan of Rust, but I think Go's docs are an example to follow. The more complex the language, the richer docs it should have imo. Quite aside from docs, Go's tooling situation is also better.
- deleted 4y ago
  [deleted]
pornel 4y ago
Note that Golang is older than Rust. When it came out it made a splash, despite not having any books or videos yet, despite not having any libraries available yet. It didn't die in obscurity (like someone else's "Go" language that existed before!) precisely because it had names of Rob Pike & Google associated with it.
- johannes1234321 4y ago
  Yes! The "killed by Google" meme is young. Back in the days it was like "i want to be like Google" (ignoring the fact that most people don't have scale like Google and very different problems) and anything out of Google must be good!
  - vintermann 4y ago
    It still is. Google may be killing off its site-products, but not its own software. A lot of open source software Google made for its own consumption (Kubernetes, Tensorflow, etc.) has become pretty much industry standards, despite everyone saying they're a lot more awkward to use outside of Google than inside.
  - jerf 4y ago
    Google also can't really "kill" Go. The license doesn't permit it. They could stop supporting it, at which point the community may or may not pick it up. (I'm inclined to think they would, but I can't guarantee that.) They could try to drag it in some hypothetical super-Google oriented direction (integrating Google Cloud somehow deeply into the language?) but they haven't yet, and at this point, again I think the community would fork and move on. It's not a service they can pull the plug on, it's a software package that would still exist even if the entire Google organization went poof tomorrow. Because if it was a service they could just pull the plug on I would never have started using it.
    - johannes1234321 4y ago
      I can't judge, as I have neither any insight into the development structure (how many non-Googler so relevant work) nor complexity (how many understand the deepest details of the compiler etc.) but I have seen different Open Sources Projects die a slow death after the primary developer went way. Everybody depended on the "free" labour being done and once gone one couldn't find agreement on how to go on. But yes, Go's spread is big enough that it won't immediately die and Google would probably be responsible enough to transfer to Linux foundation or ASF or somebody who can help to organize a new structure. Anyways, key point was that Google reputation was different, when Go took up. I can imagine if it would launch now it would find different reaction, which could prevent a community forming, thus less of safety.
bakuninsbart 4y ago
Google doesn't have the best track record of maintaining their projects, but I've had a similar experience with Android/Kotlin. Always had a dislike for "strong" OOP, but then had to do a small android app for a university project, and the tutorials, documentation and tooling for Android with Kotlin were pretty amazing. This took away most of the problems of understanding the syntax/language and gave me the leeway and motivation to get a better understanding of the concepts. My dislike for OOP is now at least partially cured.
- usrusr 4y ago
  Surprised to read that! Android has that "initialization through mutation in a set of lifecycle callbacks resembling plate tectonics" so deeply baked in that even kotlin just shrugs and learns to love the lateinit. I consider that a prime example of how OOP can lead one astray.
traceroute66 4y ago
To me, in the old Go vs Rust debate, there are two things that are abundantly clear in making a compelling case for Go. First, I don't think even the most devoted rustacean can deny that Rust has a hell of a learning curve. But perhaps most importantly is that Go has a strong and extensive standard library that covers many 21st century applications (e.g. talking to REST APIs). The problem to me with the Rust "no stdlib" model is it leaves you with two equally unattractive options: 1) Write the library yourself (and leave yourself with the associated technical debt of maintaining it) 2) Figure out which of the often dozens of third-party Rust crates you want to use (and rinse and repeat the selection process for every library, and then expose yourself to third-party maintenance debt).
- usrusr 4y ago
  The most interesting thing about the go vs rust debate is that it happened. In hindsight it seems abundantly clear that they aim for entirely different fields with negligible overlap, almost as if you'd lump together tennis and golf because they are both ball games with a somewhat upperclass bias ("how different can they be? And I hear polo is the same but with horses!"). But back then? Yeah, I was kind of expecting one of them to "win".
  - kjksf 4y ago
    Rust and Go are both general purpose languages. They overlap way more than they don't i.e. there is way more software that you can write in both languages than software that you can write in only one of them. The "best language for the job" is mostly a myth. The choice of language is mostly dictated by what you cannot do, rather than what you can do. Can I use Go or Java to program a micro-controller with 128 kB of RAM? Not really (at least no using the official, non-crippled implementation) because even "hello world" in those languages exceeds that 128 kB limit. If I'm writing a cmd-line app that I want to ship as a single binary for Windows and Mac and Linux, I'm not using Python. Technically it's possible but very few are doing it while Go gives me out of the box multi-platform compilation. The reality is that the majority of software written today falls into one of those categories: * web frontend, running in the browser, by necessity written in JavaScript or something that transpiles to JavaScript. Both Go and Rust are out of this game * web backend and similar server software: both Rust and Go compete for that * command line apps : both Rust and Go compete for that * games : AAA games are pretty much C++, Go and Rust are out (although Rust could, in principle, work) So in most cases both Rust and Go are unsuitable for the task or they compete for the task.
usrusr 4y ago
I suspect that documentation quality is part of "by veterans", people old enough to have a considerable part of their programming biography set in the days before Google driven development. Slightly ironic.
christophilus 4y ago
> In my case "backed by Google" was a deterrent, not a feature. I'm the same. For me, it was some combination of: - I can build useful stuff with few dependencies - I don't have to wait seconds for compilation - I can trivially build, scp the build artifact, and run it
krylon 4y ago
The documentation is a big point, but to me, two other points are just as important, maybe (probably) more so: 1. The standard library is very good in the sense it covers a fairly wide range of areas and gives you some idea of how to use Go idiomatically (I feel this is more important in Go than in other languages I've used). 2. The language just feels right to me. I have not met any other language that feels like it was optimized for my brain that well. I recently made an attempt at learning Rust, and I kind of got it, but I eventually gave up because the benefits did not seem worth it to me in light of the steep learning curve. Go just clicks with me. It's not the best language ever by whatever metric you choose, but for my needs, it is the right language.

CraigJPerry 4y ago

>> Made by really famous veteran language designers Yeah that’s a positive >> Backed by Google But that’s a negative, https://killedbygoogle.com/ https://killedbygoogle.com/ I definitely think you’re too fast to dismiss the language features contributing to popularity. As an example: Fast builds are a positive developers immediately warm to when they experience them (stand by for rustacean “i need time to make tea and my compile times are exactly the right length for tea break” type comment). The example of the 4.4mb c++ project that results in the compiler ingesting 8Gb of data is eye opening. C++ needs to resolve type information for all includes and all their includes and all their includes… go only needs the interface so compilation can be done without all that effort.

ampersandy 4y ago
I really dislike this meme of pointing out that Google has deprecated a lot of projects. Do people actually expect Google to staff people & resources running every project they've released forever? A more interesting comparison would be open source projects that Google has abandoned or failed to properly hand over control of to the community, especially if we're talking about Go.
- UncleMeat 4y ago
  I agree. It is true that Google has some poor product management and has some hilariously inept examples or product coherency (chat being the biggest disaster). But people praise startups for pivoting (read: killing a product) and (in general) demand innovation over glacial iteration. Trying new stuff necessarily means killing things that don't work (or paying a whole bunch of engineers to maintain a dead product for eternity).
  - cy_hauser 4y ago
    >> But people praise startups for pivoting ... Yes, but you discount the size of Google. Some of the things Google has killed have been large enough to have been considered successful products for a startup. They kill a "tiny" product because it's only large enough to be what some startup hopes to become. Google Reader is my favorite example of this. Multiple companies now exist in the soil on top of that grave.

jasode 4y ago

>- Made by really famous veteran language designers - Backed by Google Looking at decades of how various programming languages gain popularity, those proposed reasons don't seem that convincing when we look at counterexamples. E.g. counterexamples of unknown (at the time) creators creating popular languages : Bjarne Stroustrup (C++), James Gosling (Java), Rasmus Lerdorf (PHP). E.g. counterexamples of famous computer scientists creating languages that were not widely adopted : Alan Kay famous for Smalltalk but Squeak is not widely used, and Niklaus Wirth famous for Pascal but later Oberon not widely used. I think Go's popularity is mostly explained by technical reasons: 1) compiles to a single executable that's easy to deploy. This is a compelling advantage over Java,C#,Python,Ruby that require runtimes or complicated virtual environments. 2) a good enough standard library that's useful for quickly programming middleware type of apps on servers. Server-side infrastructure apps are Go's sweetspot. Go's a better productivity baseline than C++ and Javascript with their bare standard libraries that requires researching "what's the best library?" on Stackoverflow or browsing NPM repos. 3) "go routines" which some think of as the "killer feature" because that concurrency mental model is easier than threads or async/await. I'm guessing those 3 tech reasons attract more programmers than people that think "Rob Pike and Ken Thompson are famous guys at Google so I'll use Go". Regardless of celebrities, the language itself still has to have some compelling technical advantages for it to grow in usage.

pjmlp 4y ago
C++ was born at AT&T, shared the UNIX throne with C, adoption grew from there. Java was created by Sun, was remarkable in having the JDK available as free beer in the age of comercial compilers, Sun bankrupt themselves pushing Java everywhere. PHP provide a saner way to use a Perl like language on ISPs, whithout the mess of mod_perl, while most ISPs would charge extra for something else. Smalltalk was gaining adoption, before its main backer outside Xerox (IBM) decided to join forces with Sun and Oracle, and move into Java instead, famously rewriting their flagship product into Eclipse. One of the main architects behind this effort is now leading Visual Studio Code development. Compiling to single executables has been the way compilers worked before dynamic libraries became widespread in 32 bit platforms.
- 4y ago

Zababa 4y ago

We can sort of evaluate of much "backed by Google" means by looking at other languages backed by Google. The main one I have in mind is Dart. Here's a few links: - https://madnight.github.io/githut/#/pull_requests/2021/4 https://madnight.github.io/githut/#/pull_requests/2021/4 - https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/ - https://redmonk.com/sogrady/2022/03/28/language-rankings-1-22/ https://redmonk.com/sogrady/2022/03/28/language-rankings-1-2... Dart seems to be doing relatively well. Considering Go has more things in its favor than Dart, it's logical that it's doing better. Still, the Google boost seems to be really big.

mikymoothrowa 4y ago
Dart is barely doing well. It was pretty much dead before Flutter kind of imposed it. Dart is actually the counter example for “ Backed by Google “
kyrra 4y ago
(Googler, opinions are my own) Similar to the peer comment to me, Dart languished for a long time. You have to remember Dart was created as a replacement for Javascript and that they wanted other browsers to embed the DartVM in their browsers. This got absolutely rejected by Mozilla, Apple, and Microsoft. They then attempted to use it as a transpiled language, but it always generated larger javascript files than most other solutions. It still exists and is used, but Typescript ended up being a better solution. (note: there is AngularDart, which is a bit of a fork/mirror of Angular, but for Dart). This has some uses within Google as I understand it, but it's usage outside of that is rather small. Flutter using Dart ended up being a large boon for the language and drives much of the changes to the DartVM. Dart had to go through various targeted usages before it really found a home.
- Zababa 4y ago
  And even with all those troubles, it's still doing better than many many programming language, which was my point. The Google boost seems to be real and big.

dang 4y ago

(Submitted title was "What made Golang so popular? The language’s creators look back". We changed the title when we changed the URL - see https://news.ycombinator.com/item?id=31571574 https://news.ycombinator.com/item?id=31571574)

lifefeed 4y ago

The "Backed by Google" is an under-appreciated social piece of the puzzle. It's not just that Go has institutional backing, it's that googlers produce a lot of startups, and they bring their favorite things with them, and quite often one of those things is Go.

earthboundkid 4y ago
That's why we all use Dart today.
- zero_shift 4y ago
  Dart created a lot of interest at the time. The main reason it didn't take off was that Google couldn't convince MS or Mozilla to embed the DartVM in the browser. Golang obviously didn't have that constraint, it didn't depend on any external runtime. After the browser rebuff Google had a meandering approach to figuring out where Dart could fit in instead. Whereas Go slotted quite easily into one specific niche, building microservices at Google. I think the lesson is that clear positioning is crucial

deleted 4y ago

[deleted]

paskozdilar 4y ago

For me, Go solved a lot of issues that I've had with both C and Python. C is a nice language because there's no magic happening - functions are only executed if they are explicitly called. However, C had problems with strings, memory management, resource cleanup, undefined behavior, and probably a few other things I can't recall at the moment. It was also not designed with concurrency in mind, and glibc for some reason doesn't support static linking. Python is a very nice language to work in, but there is a lot magic going around with all those Python protocols and magic methods. I also find myself making a lot of errors using exceptions - exceptions can happen at any point and there is no way to anticipate them, other than documentation, which leads to try/except boilerplate. And if I want to handle exceptions on a more granular level, I find myself writing try/except for every line I call, which is 2 lines of boilerplate - same as "if err != nil {" and "}". Also, CPython has a lot of dynamically linked dependencies, which makes containerization more difficult. There's PyInstaller, but PyInstalled doesn't seem to play well with non-pure-Python modules (uwsgi, for example). And concurrency in Python is terrible because of GIL, and asyncio is far from perfect, considering function coloring and inherent single-threadedness. Go managed to become a language with a feel of Python but with certainty of C. It's like someone took C, fixed strings, added anonymous functions, automatic memory management, defer keyword for resource cleanup, sane concurrency model with channels and select. I think the name "select" comes from the Linux select syscall which allows you to wait for multiple file descriptors until one of them is ready - same thing happens with select and channels in Go. The select syscall (and its descendants) is the bedrock on which the whole asyncio world relies upon, so Go's concurrency design is already proven in practice. When I write Go code, I'm rarely worrying about an exception popping out of somewhere. Panics do happen, but in most cases, they are caused by truly exceptional errors and warrant a crash. And even though it's not a "systems language" in a kernel sense of the word, I've used Go to write video4linux applications, so it is certainly capable of making ioctls and manipulating C-like structures. Also it's statically linked, so it's possible to make really small containers with it, and easily cross-compiled, which is nice for portability.