5 ms·

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 ;-)

• 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.