9 ms·

This quote: "Russ: The most important thing I learned is that a successful programming language is about far more than the language itself." and the article li

This quote: "Russ: The most important thing I learned is that a successful programming language is about far more than the language itself." and the article linked from that comment is why I think Go is posed to become dominant over other new languages like Rust. Go's documentation, tutorials, videos, support, community - what forms the ecosystem, basically - is really the reason why I keep coming back to it. The core language might not be super-exciting, and it might not be as fast as others, as elegant as others, as "powerful" as others, as feature-rich as others, but the overall experience is very, very pleasant.

reallyRaoul 12y ago
Your concept of pleasant / your uses of Go must drastically diverge from mine! :-} I find Go to be needlessly obtuse in the language, the configuration, the tools, and the documentation. This is turning into another horror: it used to be that lots of jobs required javascript; now I fear the kool aid is making people push for Go. Note that I have not used Go for the concurrency stuff. Some might say that means I'm not allowed to have an opinion ;-) whereas I think it means I see the crappy foundation more clearly exposed.
- andrewchambers 12y ago
  I dont think there is any configuration? Building your own working Go installation from source is one command, then building a Go project, yours or someone else is one more command.
  - reallyRaoul 12y ago
    Except for how that didn't work for me. Yes, I have a "reverse midas touch" when it comes to technology, but I think that makes me a good UX critic. :-) And even if/when it does work, I detest the whole GOPATH idea. I know the alternatives are not perfect. I know. But still...
    - andrewchambers 12y ago
      So the extent of the obtuse configuration you are talking about is a single environment variable?
      - deleted 12y ago
        [deleted]
    - spotman 12y ago
      curious then, what in your opinion solves these "ux" problems better?
    - lloeki 12y ago
      > I detest the whole GOPATH idea Maybe (or maybe not) you'll find this[0] useful: touch .gopath in some project directory, your GOPATH and PATH will be set automatically upon cding inside. Then, work straight on the root for simplest projects or prototyping, or inside src for multi-package projects. In any case, deps will go in src, and you can readily vendor them, or use git submodule, or a simple shell script containing a sequence of "git clone", or not at all. No tool like godep, no import rewriting, no global workspace, per project dependencies, zero overhead. [0]: https://github.com/lloeki/dotfiles/blob/master/shell/go https://github.com/lloeki/dotfiles/blob/master/shell/go
      - ngrilly 12y ago
        I concur. This is an easy and efficient solution. We do that in my company with one difference: instead of setting the GOPATH depending on the current working directory, we use a Makefile.
    - laumars 12y ago
      Having coded in more than a dozen different languages, I think the Go ecosystem is the easiest I've used - when you look at the entire development and deployment stack. You're right that GOPATH needs to be set, but is that really any different to having Python, Perl, Ruby, etc JIT's in your PATH env var? And GOPATH is certainly more convenient when it comes to the distribution of program (ie copying the compiled PE / ELF) than having to ensure that you have a Perl et al run time environment (and particularly any required non-standard imports) installed on the destination system. But Go isn't a JIT / scripting language, so that's probably not a far comparison. So let's compare it to it's closer relatives: C# and Java. Java is just a mess from a UX perspective. It's a mess to install, it's a mess to redistribute. It's just a complete mess compared with Go. C#, however, is a very friendly language to approach as a new developer - if you're writing applications on Windows and for Windows. I will grant you that .NET is open source and cross platform, and that recent reports suggest .NET projects will become more portable in future years, but you still need a Mono runtime on non-Windows platforms. Go compiles it's dependencies into it's binary (hence the size of the binary). I'm by no means saying Go is perfect, but lots of people have tried to solve the problem you're raising and more often the case is their attempts are less user friendly than Go. Which leads me to think that maybe the minor inconvenience of having to define GOPATH (and it really only needs to be defined once in the entire lifetime of your Go development machine) is a pretty good usability solution.
  - deleted 12y ago
    [deleted]
- MetaCosm 12y ago
  What language is simpler to setup? 1. Download tar.gz (or zip) 2. Extract to <place> 3. export GOROOT=<place> 4. export GOPATH=<some_other_place> ... if you want to get fancy and make sure all your binaries are automatically in your path 5. export PATH=$PATH:$GOPATH/bin ... at this point setup is done, to build your first project using an external library 6. go get github.com/<user>/<library> 7. code, code, use <library>, zug, zug... save code in $GOPATH/src/<your_package> 8. go install <your_package> 9. $ <your_package> # runs it this package can be shared because it is a static binary -- share with your friends, run on other servers, heck -- even cross-compile for other platforms with ease. Working on Linux -- but want to ship a utility to do X for a friend on Windows, no problem!
barsonme 12y ago
Admittedly I'm a new programmer, but learning Go has taught me far more than just Go. For me, Go seemed very low level -- I mean, it even had pointers! But then I tried to rewrite some GNU utilities in Go (still not sure _why_) and I had to translate C to Go, which flipped my world upside down. Simply because Go was easy enough for me to write as a beginner but close enough to the hardware for me to want to explore, I've learned a lot about the Linux kernel, C, GNU, programming best practices, and so on. And the best part is everybody is do damn friendly. If I'd ask a dumb question about Go I'd get a friendly response, along with RTFM. With C? Usually just RTFM. Robert, Rob, and Ken did a fine job. (Along with Brad, Russ, et al.)
copsarebastards 12y ago
Apparently creating a successful programming language is about sticking "Google" in front of the name.
- mseepgood 12y ago
  There's no "Google" in front of the name "Go", see https://golang.org https://golang.org
  - copsarebastards 12y ago
    People never cease to amaze me with their ability to be so technically correct while entirely missing the point.
    - pstuart 12y ago
      Maybe the "Google" part has to do with the fact that the language has some backing and isn't going to disappear overnight because the lone developer decided to abandon it. p.s. Your hatred of Go is kind of funny to this outsider. I may be just a stupid coder w/o a CS degree but spent a couple of decades in the trenches. Since a superior language would naturally eliminate the puny offerings of Go, I await your wisdom in the language that will save me and other mindless drones from futile coding. Please enlighten me with the language that will save me from this programming plague.
      - copsarebastards 12y ago
        > Maybe the "Google" part has to do with the fact that the language has some backing and isn't going to disappear overnight because the lone developer decided to abandon it. ...which is also true of numerous alternatives to Go. > p.s. Your hatred of Go is kind of funny to this outsider. I may be just a stupid coder w/o a CS degree but spent a couple of decades in the trenches. Since a superior language would naturally eliminate the puny offerings of Go, I await your wisdom in the language that will save me and other mindless drones from futile coding. Please enlighten me with the language that will save me from this programming plague. Yes that's very witty. I don't believe there's one true language--if I have a choice of languages I choose the one I feel is most appropriate to the job. However, I would like to see the industry move forward. I want to be able to find work with better programming languages. I'd love to see Rust replace C/C++ in spaces where performance, memory, size, etc. are priorities. I'd love to see one of the handful of higher-performance scripting languages that have come about in the last few years gain the maturity and library support that Ruby and Python have. Seeing Go become popular is frustrating because it's a step back, not a step forward. If the industry goes in that direction, it will affect the industry negatively, but it will also affect me negatively. And if you're still working in the industry it will affect you negatively too, so I'm not sure why you think it's funny.
worklogin 12y ago
>I think Go is posed to become dominant over other new languages like Rust. I agree that complete documentation, good stdlib, intuitive build/package system, and friendly community are part of a language's success. But how does Rust fail at those compared to go, considering it hasn't released 1.0 stable?
- ioddly 12y ago
  Well, not having a stable release at this point could be considered a downside. Clearly there's some ground to steal from C & C++ and some advantage to getting there first. Just playing devil's advocate here as I am a rust fan.
  - deleted 12y ago
    [deleted]
- PopsiclePete 12y ago
  I started following Go in 2009. It was pretty much "stable" in r59 or whatever they called it, a good 2-3 years before Go 1.0. There were a few breaking changes, a few new keywords, and one package - container/vector - disappeared (since the "append" built-in was added). So every tutorial, every article, every video, every blog post is still an excellent source of information, 5 years later. Rust? Anything you read that is more than a week old is basically wrong. Entire language features, syntax, keywords have been ripped and thrown into oblivion - the @ qualifier, the ~ qualifier, the entire i/o library is being rethought... These aren't bad things. I'm a huge fan of not maintaining infinite backwards compatibility. But it leaves a strange taste in my mouth. Go was basically "done" in the general sense in early 2010. Rust reinvents itself every 3 months. You could say that the Go authors knew better what they wanted from the get-go, maybe? There's a sense of "they know exactly what they wanted" vs "these guys are shooting in the dark and hoping to hit the bulls-eye" which is kind of the impression Rust leaves me with.
  - Jweb_Guru 12y ago
    Go made the (pragmatic) decision to go with concurrent garbage collection. This meant they could use very familiar solutions to problems that Rust was struggling with at the time. It also meant that they failed at their initial goal to attract C++ programmers. That doesn't make Go a failure as a language, but I sometimes get the sense that people don't realize just how much Go relies on the GC, or how much of Rust's changing design revolved around its changing relationship with GC. As one example, without GC, Go would likely have had to abandon green threads for performance reasons (the switch away from segmented stacks relies entirely on being able to trace pointers).
Dewie 12y ago
> and the article linked from that comment is why I think Go is posed to become dominant over other new languages like Rust. Is there some law that says that any top comment on HN that mentions either Rust or Go, a mention of the other is bound to happen in the same sentence? Like some kind of magnetic, rhetorical force. Heh. If either, or both, Rust or Go succeeds, it will be for widely different reasons. edit: to whoever is adamant about downvoting my questions for today; you forgot the one previous to this one.
- worklogin 12y ago
  I think your comment had enough respect/content not to warrant a downvote. Sorry to see the haters out today, comrade. Rust and Go seem to have the potential for some overlap. But it seems Rust will be successful as a lower level systems language while Go may be easier to maintain when building highly concurrent, networked applications.
azth 12y ago
> and the article linked from that comment is why I think Go is posed to become dominant over other new languages like Rust. Apples to oranges. Rust is aiming to be a C++ replacement.
- en4bz 12y ago
  Go was originally designed as C++ replacement to be used at Google but its lack important C++ features lead to little interest from C++ programmers. Pike found much more interest from Ruby/Python programmers. http://commandcenter.blogspot.it/2012/06/less-is-exponentially-more.html http://commandcenter.blogspot.it/2012/06/less-is-exponential...
  - pcwalton 12y ago
    And Rust is different, since it does incorporate the features that current C++ programmers need (such as GC-free memory management and generics). So I don't see how that refutes the comment you replied to.
    - en4bz 12y ago
      I just wanted to point out that Go was trying to be a C++ replacement. Most people tend to forget this. While apple and oranges is an appropriate metaphor for the approach that the two languages take, Go and Rust are vastly different, their goal of being systems programming languages is not.
      - pcwalton 12y ago
        The point of objecting to the comparison is that there are lots of important aspects of Rust's design that Go's design doesn't account for, and many C++ developers (for example, me) depend on those. (In my case, those are memory safety in parallel mode, GC freedom, data race freedom, fast interop with C code, and zero-overhead generics.) The languages have wildly different designs. So saying "Go is going to beat Rust" like the OP did is pointless cheerleading, and the "apples to oranges" comment is correct to point that out. A useful thought experiment is: If Rust completely failed to garner any mindshare, could I switch to Go for the project I work on (Servo)? The answer is no: Go's design goals are totally incompatible with the project. C++ would be more appropriate than Go (though it would mean sacrificing many of Rust's advantages, of course). That's why I, and the Rust community as a whole, tend to dislike the comparison. Go is a fantastic language that works really well for lots of use cases, but a C++ replacement for all niches needs a lot of things that Go doesn't have. And this isn't a knock against Go: as I said, Go is a great language for lots of things that could also be written in C++.
brooksbp 12y ago
> Go's documentation, tutorials, videos, support, community - what forms the ecosystem, basically - is really the reason why I keep coming back to it. One way to put it is that this highlights Go from a user's perspective. The very same thing is true from the compiler developer's perspective. I've found that the process of installing dependencies, pulling source, navigating source, building, testing, contributing patches, etc is important for success--as well as the user experience. I've had bug-fix patches accepted into Clang, GHC, and Rust. I found Rust to be a bit pricklier than Clang and GHC. I'd like to make time to get a similar experience with Go--I suspect it would be good.
vlunkr 12y ago
I haven't done anything big in Go yet, but I loved that in their tutorial they talk in depth about the design choices they made for the language. It really feels like a language that was designed with a purpose, and they are a little obsessive about keeping it pure, not letting it get bloated with features, which suits it nicely. On a side note, why does every discussion about Go seem to turn immediately into a comparison/argument between Go and Rust? I'm not an expert in either language, but I don't see why the two languages can't coexist.
- Jweb_Guru 12y ago
  If you were an expert in either language, you also wouldn't see why the two languages couldn't coexist. Outside of some nebulous sense that both languages are aimed at "systems programming," and the fact that neither of them existed ten years ago, I have yet to read a convincing explanation of why they have more in common than, say, OCaml and Fortran. We clearly need more OCaml-Fortran comparisons. Or hell, let's do some Rust-Fortran comparisons, at least those might be mildly entertaining like the Go-Algol one.
616c 12y ago
I do not want to pick a fight, but how is Rust not doing that? Check out /r/lang_name subs on Reddit, you will not find many other communities as vibrant (maybe some, but not the majority). Then check out rust_gamedev, dedicated to game programming. I have not checked out their IRC but excerpts from IRC on /r/rust tells me the community is vibrant on both ends of the hose. They also had like one bad incident on IRC about a gender issue, and they shut that crap down with a strict Code of Conduct imposed everywhere. Whether or not your are into that, I think they take community management very seriously, and regardless of politics, I applaud that. They have done every single thing about the language through RFCs and discussions of bugs and PRs on Github from almost project inception, where the community drives a lot. There are very talented people writing tutorials on writing Rust, from tooling, to the Servo web browser experimentation, to http server libraries like Chris Morgan's work, to work on the Piston game dev library. Granted, I have not checked for videos yet. Others correct me if I am wrong. I mean, I understand that Go has these things, but maybe I am reading too much into your comment. I just think Rust has a wonderful community, media and all, about what you can do with it. Rust is nonetheless a work in progress. I am not saying this to be judgemental, but Googlers released Go after work was complete at some stage. Volunteers and a few Mozillans have worked on Rust iteratively, on many iterations and revisions, out in the open. This makes a big difference in perception and how easy it is to get started. Granted, I have not started with either. But what keeps me interested in Rust, even though it is way out of my comfort zone and I have terrible systems programming knowledge, is exactly about what you describe with Go. For me, I look Rust more, personally, because of my perception they are willing to try simple, try complicated, but as long as it is a reasoned discussion about language design. And the best part: IF X IN RUST DOES NOT WORK, OUR BAD, WE THROW IT AWAY. I caps that because it is so refreshing to see that. People have complained a lot. Some of the complaints are there, but many redundant or irritating features were removed simply because they were not useful or outlived usefulness. I wish this honest experimentation was more frequent in the industry, but my myopic view, as largely an outsider, is that it is not the norm. (And to be clear, I am not saying Go or language X does not do these things, but observing Rust you see they are briskly paced but willing to make deliberate changes at a pace and keep reviewing the drawing board; I cannot pass judgement on other langs, and this is just my impression.)
kristianp 12y ago
"and the article linked from that comment is why I think Go is posed to become dominant over other new languages like Rust." Why does every Go posting have to have the same argument about the pros and cons of the language against other languages, and peoples opinions of why they like or dislike go? It's so repetitive.

reallyRaoul 12y ago

Your concept of pleasant / your uses of Go must drastically diverge from mine! :-} I find Go to be needlessly obtuse in the language, the configuration, the tools, and the documentation. This is turning into another horror: it used to be that lots of jobs required javascript; now I fear the kool aid is making people push for Go. Note that I have not used Go for the concurrency stuff. Some might say that means I'm not allowed to have an opinion ;-) whereas I think it means I see the crappy foundation more clearly exposed.

andrewchambers 12y ago
I dont think there is any configuration? Building your own working Go installation from source is one command, then building a Go project, yours or someone else is one more command.
- reallyRaoul 12y ago
  Except for how that didn't work for me. Yes, I have a "reverse midas touch" when it comes to technology, but I think that makes me a good UX critic. :-) And even if/when it does work, I detest the whole GOPATH idea. I know the alternatives are not perfect. I know. But still...
  - andrewchambers 12y ago
    So the extent of the obtuse configuration you are talking about is a single environment variable?
    - deleted 12y ago
      [deleted]
  - spotman 12y ago
    curious then, what in your opinion solves these "ux" problems better?
  - lloeki 12y ago
    > I detest the whole GOPATH idea Maybe (or maybe not) you'll find this[0] useful: touch .gopath in some project directory, your GOPATH and PATH will be set automatically upon cding inside. Then, work straight on the root for simplest projects or prototyping, or inside src for multi-package projects. In any case, deps will go in src, and you can readily vendor them, or use git submodule, or a simple shell script containing a sequence of "git clone", or not at all. No tool like godep, no import rewriting, no global workspace, per project dependencies, zero overhead. [0]: https://github.com/lloeki/dotfiles/blob/master/shell/go https://github.com/lloeki/dotfiles/blob/master/shell/go
    - ngrilly 12y ago
      I concur. This is an easy and efficient solution. We do that in my company with one difference: instead of setting the GOPATH depending on the current working directory, we use a Makefile.
  - laumars 12y ago
    Having coded in more than a dozen different languages, I think the Go ecosystem is the easiest I've used - when you look at the entire development and deployment stack. You're right that GOPATH needs to be set, but is that really any different to having Python, Perl, Ruby, etc JIT's in your PATH env var? And GOPATH is certainly more convenient when it comes to the distribution of program (ie copying the compiled PE / ELF) than having to ensure that you have a Perl et al run time environment (and particularly any required non-standard imports) installed on the destination system. But Go isn't a JIT / scripting language, so that's probably not a far comparison. So let's compare it to it's closer relatives: C# and Java. Java is just a mess from a UX perspective. It's a mess to install, it's a mess to redistribute. It's just a complete mess compared with Go. C#, however, is a very friendly language to approach as a new developer - if you're writing applications on Windows and for Windows. I will grant you that .NET is open source and cross platform, and that recent reports suggest .NET projects will become more portable in future years, but you still need a Mono runtime on non-Windows platforms. Go compiles it's dependencies into it's binary (hence the size of the binary). I'm by no means saying Go is perfect, but lots of people have tried to solve the problem you're raising and more often the case is their attempts are less user friendly than Go. Which leads me to think that maybe the minor inconvenience of having to define GOPATH (and it really only needs to be defined once in the entire lifetime of your Go development machine) is a pretty good usability solution.
- deleted 12y ago
  [deleted]
MetaCosm 12y ago
What language is simpler to setup? 1. Download tar.gz (or zip) 2. Extract to <place> 3. export GOROOT=<place> 4. export GOPATH=<some_other_place> ... if you want to get fancy and make sure all your binaries are automatically in your path 5. export PATH=$PATH:$GOPATH/bin ... at this point setup is done, to build your first project using an external library 6. go get github.com/<user>/<library> 7. code, code, use <library>, zug, zug... save code in $GOPATH/src/<your_package> 8. go install <your_package> 9. $ <your_package> # runs it this package can be shared because it is a static binary -- share with your friends, run on other servers, heck -- even cross-compile for other platforms with ease. Working on Linux -- but want to ship a utility to do X for a friend on Windows, no problem!

barsonme 12y ago

Admittedly I'm a new programmer, but learning Go has taught me far more than just Go. For me, Go seemed very low level -- I mean, it even had pointers! But then I tried to rewrite some GNU utilities in Go (still not sure _why_) and I had to translate C to Go, which flipped my world upside down. Simply because Go was easy enough for me to write as a beginner but close enough to the hardware for me to want to explore, I've learned a lot about the Linux kernel, C, GNU, programming best practices, and so on. And the best part is everybody is do damn friendly. If I'd ask a dumb question about Go I'd get a friendly response, along with RTFM. With C? Usually just RTFM. Robert, Rob, and Ken did a fine job. (Along with Brad, Russ, et al.)

copsarebastards 12y ago

Apparently creating a successful programming language is about sticking "Google" in front of the name.

mseepgood 12y ago
There's no "Google" in front of the name "Go", see https://golang.org https://golang.org
- copsarebastards 12y ago
  People never cease to amaze me with their ability to be so technically correct while entirely missing the point.
  - pstuart 12y ago
    Maybe the "Google" part has to do with the fact that the language has some backing and isn't going to disappear overnight because the lone developer decided to abandon it. p.s. Your hatred of Go is kind of funny to this outsider. I may be just a stupid coder w/o a CS degree but spent a couple of decades in the trenches. Since a superior language would naturally eliminate the puny offerings of Go, I await your wisdom in the language that will save me and other mindless drones from futile coding. Please enlighten me with the language that will save me from this programming plague.
    - copsarebastards 12y ago
      > Maybe the "Google" part has to do with the fact that the language has some backing and isn't going to disappear overnight because the lone developer decided to abandon it. ...which is also true of numerous alternatives to Go. > p.s. Your hatred of Go is kind of funny to this outsider. I may be just a stupid coder w/o a CS degree but spent a couple of decades in the trenches. Since a superior language would naturally eliminate the puny offerings of Go, I await your wisdom in the language that will save me and other mindless drones from futile coding. Please enlighten me with the language that will save me from this programming plague. Yes that's very witty. I don't believe there's one true language--if I have a choice of languages I choose the one I feel is most appropriate to the job. However, I would like to see the industry move forward. I want to be able to find work with better programming languages. I'd love to see Rust replace C/C++ in spaces where performance, memory, size, etc. are priorities. I'd love to see one of the handful of higher-performance scripting languages that have come about in the last few years gain the maturity and library support that Ruby and Python have. Seeing Go become popular is frustrating because it's a step back, not a step forward. If the industry goes in that direction, it will affect the industry negatively, but it will also affect me negatively. And if you're still working in the industry it will affect you negatively too, so I'm not sure why you think it's funny.

worklogin 12y ago

>I think Go is posed to become dominant over other new languages like Rust. I agree that complete documentation, good stdlib, intuitive build/package system, and friendly community are part of a language's success. But how does Rust fail at those compared to go, considering it hasn't released 1.0 stable?

ioddly 12y ago
Well, not having a stable release at this point could be considered a downside. Clearly there's some ground to steal from C & C++ and some advantage to getting there first. Just playing devil's advocate here as I am a rust fan.
- deleted 12y ago
  [deleted]
PopsiclePete 12y ago
I started following Go in 2009. It was pretty much "stable" in r59 or whatever they called it, a good 2-3 years before Go 1.0. There were a few breaking changes, a few new keywords, and one package - container/vector - disappeared (since the "append" built-in was added). So every tutorial, every article, every video, every blog post is still an excellent source of information, 5 years later. Rust? Anything you read that is more than a week old is basically wrong. Entire language features, syntax, keywords have been ripped and thrown into oblivion - the @ qualifier, the ~ qualifier, the entire i/o library is being rethought... These aren't bad things. I'm a huge fan of not maintaining infinite backwards compatibility. But it leaves a strange taste in my mouth. Go was basically "done" in the general sense in early 2010. Rust reinvents itself every 3 months. You could say that the Go authors knew better what they wanted from the get-go, maybe? There's a sense of "they know exactly what they wanted" vs "these guys are shooting in the dark and hoping to hit the bulls-eye" which is kind of the impression Rust leaves me with.
- Jweb_Guru 12y ago
  Go made the (pragmatic) decision to go with concurrent garbage collection. This meant they could use very familiar solutions to problems that Rust was struggling with at the time. It also meant that they failed at their initial goal to attract C++ programmers. That doesn't make Go a failure as a language, but I sometimes get the sense that people don't realize just how much Go relies on the GC, or how much of Rust's changing design revolved around its changing relationship with GC. As one example, without GC, Go would likely have had to abandon green threads for performance reasons (the switch away from segmented stacks relies entirely on being able to trace pointers).

Dewie 12y ago

> and the article linked from that comment is why I think Go is posed to become dominant over other new languages like Rust. Is there some law that says that any top comment on HN that mentions either Rust or Go, a mention of the other is bound to happen in the same sentence? Like some kind of magnetic, rhetorical force. Heh. If either, or both, Rust or Go succeeds, it will be for widely different reasons. edit: to whoever is adamant about downvoting my questions for today; you forgot the one previous to this one.

worklogin 12y ago
I think your comment had enough respect/content not to warrant a downvote. Sorry to see the haters out today, comrade. Rust and Go seem to have the potential for some overlap. But it seems Rust will be successful as a lower level systems language while Go may be easier to maintain when building highly concurrent, networked applications.

azth 12y ago

> and the article linked from that comment is why I think Go is posed to become dominant over other new languages like Rust. Apples to oranges. Rust is aiming to be a C++ replacement.

en4bz 12y ago
Go was originally designed as C++ replacement to be used at Google but its lack important C++ features lead to little interest from C++ programmers. Pike found much more interest from Ruby/Python programmers. http://commandcenter.blogspot.it/2012/06/less-is-exponentially-more.html http://commandcenter.blogspot.it/2012/06/less-is-exponential...
- pcwalton 12y ago
  And Rust is different, since it does incorporate the features that current C++ programmers need (such as GC-free memory management and generics). So I don't see how that refutes the comment you replied to.
  - en4bz 12y ago
    I just wanted to point out that Go was trying to be a C++ replacement. Most people tend to forget this. While apple and oranges is an appropriate metaphor for the approach that the two languages take, Go and Rust are vastly different, their goal of being systems programming languages is not.
    - pcwalton 12y ago
      The point of objecting to the comparison is that there are lots of important aspects of Rust's design that Go's design doesn't account for, and many C++ developers (for example, me) depend on those. (In my case, those are memory safety in parallel mode, GC freedom, data race freedom, fast interop with C code, and zero-overhead generics.) The languages have wildly different designs. So saying "Go is going to beat Rust" like the OP did is pointless cheerleading, and the "apples to oranges" comment is correct to point that out. A useful thought experiment is: If Rust completely failed to garner any mindshare, could I switch to Go for the project I work on (Servo)? The answer is no: Go's design goals are totally incompatible with the project. C++ would be more appropriate than Go (though it would mean sacrificing many of Rust's advantages, of course). That's why I, and the Rust community as a whole, tend to dislike the comparison. Go is a fantastic language that works really well for lots of use cases, but a C++ replacement for all niches needs a lot of things that Go doesn't have. And this isn't a knock against Go: as I said, Go is a great language for lots of things that could also be written in C++.

brooksbp 12y ago

> Go's documentation, tutorials, videos, support, community - what forms the ecosystem, basically - is really the reason why I keep coming back to it. One way to put it is that this highlights Go from a user's perspective. The very same thing is true from the compiler developer's perspective. I've found that the process of installing dependencies, pulling source, navigating source, building, testing, contributing patches, etc is important for success--as well as the user experience. I've had bug-fix patches accepted into Clang, GHC, and Rust. I found Rust to be a bit pricklier than Clang and GHC. I'd like to make time to get a similar experience with Go--I suspect it would be good.

vlunkr 12y ago

I haven't done anything big in Go yet, but I loved that in their tutorial they talk in depth about the design choices they made for the language. It really feels like a language that was designed with a purpose, and they are a little obsessive about keeping it pure, not letting it get bloated with features, which suits it nicely. On a side note, why does every discussion about Go seem to turn immediately into a comparison/argument between Go and Rust? I'm not an expert in either language, but I don't see why the two languages can't coexist.

Jweb_Guru 12y ago
If you were an expert in either language, you also wouldn't see why the two languages couldn't coexist. Outside of some nebulous sense that both languages are aimed at "systems programming," and the fact that neither of them existed ten years ago, I have yet to read a convincing explanation of why they have more in common than, say, OCaml and Fortran. We clearly need more OCaml-Fortran comparisons. Or hell, let's do some Rust-Fortran comparisons, at least those might be mildly entertaining like the Go-Algol one.

616c 12y ago

I do not want to pick a fight, but how is Rust not doing that? Check out /r/lang_name subs on Reddit, you will not find many other communities as vibrant (maybe some, but not the majority). Then check out rust_gamedev, dedicated to game programming. I have not checked out their IRC but excerpts from IRC on /r/rust tells me the community is vibrant on both ends of the hose. They also had like one bad incident on IRC about a gender issue, and they shut that crap down with a strict Code of Conduct imposed everywhere. Whether or not your are into that, I think they take community management very seriously, and regardless of politics, I applaud that. They have done every single thing about the language through RFCs and discussions of bugs and PRs on Github from almost project inception, where the community drives a lot. There are very talented people writing tutorials on writing Rust, from tooling, to the Servo web browser experimentation, to http server libraries like Chris Morgan's work, to work on the Piston game dev library. Granted, I have not checked for videos yet. Others correct me if I am wrong. I mean, I understand that Go has these things, but maybe I am reading too much into your comment. I just think Rust has a wonderful community, media and all, about what you can do with it. Rust is nonetheless a work in progress. I am not saying this to be judgemental, but Googlers released Go after work was complete at some stage. Volunteers and a few Mozillans have worked on Rust iteratively, on many iterations and revisions, out in the open. This makes a big difference in perception and how easy it is to get started. Granted, I have not started with either. But what keeps me interested in Rust, even though it is way out of my comfort zone and I have terrible systems programming knowledge, is exactly about what you describe with Go. For me, I look Rust more, personally, because of my perception they are willing to try simple, try complicated, but as long as it is a reasoned discussion about language design. And the best part: IF X IN RUST DOES NOT WORK, OUR BAD, WE THROW IT AWAY. I caps that because it is so refreshing to see that. People have complained a lot. Some of the complaints are there, but many redundant or irritating features were removed simply because they were not useful or outlived usefulness. I wish this honest experimentation was more frequent in the industry, but my myopic view, as largely an outsider, is that it is not the norm. (And to be clear, I am not saying Go or language X does not do these things, but observing Rust you see they are briskly paced but willing to make deliberate changes at a pace and keep reviewing the drawing board; I cannot pass judgement on other langs, and this is just my impression.)

kristianp 12y ago

"and the article linked from that comment is why I think Go is posed to become dominant over other new languages like Rust." Why does every Go posting have to have the same argument about the pros and cons of the language against other languages, and peoples opinions of why they like or dislike go? It's so repetitive.