5 ms·

>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, a

>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).
- infogulch 12y ago
  I would argue that Go's focus on a small feature set made it easier to get right more quickly. The few Go designers knew what they wanted out of the language. They decided early on that Go would be very opinionated. And they were OK with sacrificing purity for simplicity. Rust has many more features than Go. (And language complexity increases approximately combinatorially with the number of features.) Features in Rust are decided more democratically. Rust designers are OK with a long (re)discovery period for features to find the purest design. I believe these differences in language authorship explains the churn that Rust has experienced relative to Go.

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).
infogulch 12y ago
I would argue that Go's focus on a small feature set made it easier to get right more quickly. The few Go designers knew what they wanted out of the language. They decided early on that Go would be very opinionated. And they were OK with sacrificing purity for simplicity. Rust has many more features than Go. (And language complexity increases approximately combinatorially with the number of features.) Features in Rust are decided more democratically. Rust designers are OK with a long (re)discovery period for features to find the purest design. I believe these differences in language authorship explains the churn that Rust has experienced relative to Go.