9 ms·

I like the way Go proceeds as a language, with features added very very slowly and the compiler and tools regularly improving. I hope Rust can settle down in

I like the way Go proceeds as a language, with features added very very slowly and the compiler and tools regularly improving. I hope Rust can settle down into a similar focus soon.

leetrout 7y ago
Russ Cox gave a talk at GopherCon 2019 and talked about the 4 R's of Simplifying: Reshaping Redefining Removing Restricting And he follows up with examples of how they applied those to the code base. If you've not seen it you might enjoy it. https://www.youtube.com/watch?v=kNHo788oO5Y https://www.youtube.com/watch?v=kNHo788oO5Y
- ra7 7y ago
  Russ Cox also recently wrote a series of blog posts about Go proposal process, which is also interesting: https://research.swtch.com/proposals https://research.swtch.com/proposals
ragona 7y ago
Heh, I like the way Rust proceeds as a language, with regular releases and improvements. I hope Go can make quality of life improvements with similar speed.
abtinf 7y ago
I hadn’t thought of this before, but I think you are onto something critical about Go. In a different life, I worked deep in C# and the bowels of the CLR. New versions of C# were both exciting (woo, LINQ, anonymous things, lambdas, and a dozen others each release) and frustrating (ugh, visual studio doesn’t have specialized tools to handle this new stuff). I’ve been writing Go for 8 or 9 years now and I value the tool chain improvements far more than the language features. Race detection was a godsend. Indeed, even taking away capabilities (or just being more strict) has been valuable—like when multi-threaded access to slices became an error. In this release, I don’t much care about the new literal prefixes. But I’m excited about the improvement to defer performance and the improved range check panic messages. In a sense, other languages make it easier to to write new code with each release, but every iteration of Go makes my old code better too.
- purple_ducks 7y ago
  > I like the way Go proceeds as a language, with features added very very slowly and the compiler and tools regularly improving > I value the tool chain improvements far more than the language features Java 6 may be right up your alley (https://en.wikipedia.org/wiki/Java_version_history https://en.wikipedia.org/wiki/Java_version_history)
  - orhmeh09 7y ago
    What do you mean by this reference to an older Java version?
rolleiflex 7y ago
I think Go is the only software release at this point to whose releases I respond with ‘Ooh shiny’ and not ‘Oh god’. I love the way they’re doing this — calm, collected, slow, and with ample heads up. At this point, I think we all have some JavaScript PTSD.
- fourseventy 7y ago
  i feel the same way!
- seabrookmx 7y ago
  C# obviously has a very different design philosophy than Go, but its releases are moving along at a similar (and IMO, reasonable) pace.
- Cthulhu_ 7y ago
  Yeah, for me the turnaround point for JS was when they added classes - JS is not an oop language and trying to make it look like one doesn't work. Worse, they didn't even implement it properly - no access modifiers. Call me a bit of a luddite but this is one of the reasons why I'm skeptical about generics in Go - it'll be another language construct to keep in mind. Mind you this opinion of mine is baseless because unfortunately I haven't had the opportunity to do any serious go development yet.
pcwalton 7y ago
Rust moves slowly too. I'm not sure where the idea that Rust makes changes willy-nilly came from, but anyone saying that is deeply unfamiliar with the RFC process. It's extremely hard to get new features into Rust.
- asdkhadsj 7y ago
  Perhaps it's the number of things changing that leads to the feeling of rapid movement. After all, 60 1mph increases are all tiny by themselves. Not sure if that's true or not though. Rust is my daily driver for the last year and even coming from Go (after 6 years) I don't feel the pace is hard to keep up with, or that my code breaks frequently. In fact, I don't think my code has broke as a result of changes once since I switched to Rust. It has happened .. twice maybe, via dependencies, though.
- burntsushi 7y ago
  Maybe Rust moves slowly, but not nearly as slow as Go. I know because I use both languages daily. I spend almost no time in Go code keeping up with deprecations, new APIs and new language features. Not all of those things need to go through the RFC process. For example, I don't think there's any backpressure against deprecating stuff right now. As soon as a replacement comes along, a deprecation pretty routinely occurs just a couple releases (a few months) after it. I don't spend a ton of time in Rust responding to churn, but it's definitely noticeable. This is why I've been bleating a bit more now than I have before about reducing churn. N.B. On reflection, perhaps I do have some bias here. My daily work on Go is mostly for $work, and involves one large codebase. My daily work on Rust, however, involves maintenance of dozens of crates. So if there's churn, I feel it repeatedly. So its effect might be magnified for me personally.
- est31 7y ago
  One example where Rust is moving faster than Go is the compiler: * Excluding patch releases, Go has a release twice each year [1], while Rust has a release every six weeks (about 9 times per year) [2]. * For minor (patch) releases (security updates, etc), Rust only cares about the latest version released. Go provides patch releases for the last two releases [3]. * The latest release of the Go compiler (1.13, Sept 2019) is able to bootstrap itself from Go 1.4 [4], released on Dec 10 2014. The latest release of the Rust compiler 1.37.0 (Aug 15 2019) needs Rust 1.36.0 (Jul 04 2019) for bootstrap. * For the language, I think relative to itself, Rust has considerably slowed down with development compared to the pre-1.0 times. Now it's still evolving more quickly than Go. Rust is getting async_await, const generics, etc while Go is discussing about an error handling operator that Rust already had two revisions of since its 2015 release (try! and ?). I'm not saying that all of this churn that Rust has is bad. Some of it is good, like the tighter release schedule that prevents half finished stuff to be released. But other things, like the tight version range that the compiler can bootstrap from, could be improved. [1]: https://github.com/golang/go/wiki/Go-Release-Cycle https://github.com/golang/go/wiki/Go-Release-Cycle [2]: https://blog.rust-lang.org/2014/12/12/1.0-Timeline.html https://blog.rust-lang.org/2014/12/12/1.0-Timeline.html [3]: https://github.com/golang/go/wiki/MinorReleases https://github.com/golang/go/wiki/MinorReleases [4]: https://golang.org/doc/install/source https://golang.org/doc/install/source
derefr 7y ago
I feel like Go is the way it is, mostly because its maintainers are also responsible for the continued productivity of thousands of engineers working on Google's numerous Go codebases. Any "breaking change" that requires rewriting Go code is a tangible negative for them, in that it'll interrupt Googlers from getting real work done, and the blame will come back to them. In a sense, Go is more like a corporate-internal DSL that the public just happen to be able to use. (Erlang is—or at least, was, for the first ten years of its life—another language that is this way.)
- remus 7y ago
  Personally I think this is a pretty positive thing. If a language is at all popular then any breaking change is going to mean work for users, and having those users sitting next to you in the office keeps it fresh in your mind when you're tempted to make that "one small change" to the language.
  - pcwalton 7y ago
    This thread isn't about breaking changes, though. Neither Rust nor Go make breaking changes.
- gameswithgo 7y ago
  Rust doesn't really introduce breaking changes. There is just a lot of cognitive power required to keep up with everything, which can make it hard to read other people's code, or know which is the 'best' way to do a thing, etc. People who disagree with this may simply have more cognitive power/time to devote to keeping up with everything in Rust. I have a day job in an entirely different universe, so keeping up with Rust is hard.
kzrdude 7y ago
Rust has a focus - it is articulated through the roadmap. - 2018 roadmap https://blog.rust-lang.org/2018/03/12/roadmap.html https://blog.rust-lang.org/2018/03/12/roadmap.html - 2019 roadmap https://blog.rust-lang.org/2019/04/23/roadmap.html https://blog.rust-lang.org/2019/04/23/roadmap.html It's a big community, and it has time for a lot of development
bsaul 7y ago
Rust can't settle down right now, because it still has to make necessary changes to critical parts of the language, such as async. Go always had a very narrow and precise ambition and scope (a better C, aimed at server-side data plumbing). Which is the reason why it was able to nail a set of features from the start and keep it that way. Rust has a much wider ambition : all the modern languages facilities (generics, metaprogramming, etc) with the speed of C, AND breakthrough memory-safety features. Go doesn't try to innovate, and i suppose the author see innovation as something you should stay away until it's nothing new anymore.
- littlestymaar 7y ago
  > a better C, aimed at server-side data plumbing I agree with all what you said but this. Go isn't a better C, it's a better Java.
  - root_axis 7y ago
    I think in practice it has become something closer to a better python than a better java.
    - earenndil 7y ago
      Personally, I don't think it's better than any of those languages.
    - meowface 7y ago
      More like a "different Python" than a better one. Way more performant, way more verbose, and (IMO) way better concurrency. Not to go off on too much of a tangent, but I think asyncio is a huge mess and was a mistake. I still use gevent for everything in Python. https://glyph.twistedmatrix.com/2014/02/unyielding.html https://glyph.twistedmatrix.com/2014/02/unyielding.html is frequently cited as an argument for why goroutines and gevent and green threads suck and why explicit asyncio-style concurrency is better, but I have a lot of issues with this article and find the former two way easier, simpler, and faster to work with.
  - 7y ago
JTenerife 7y ago
Rust needs to settle down to reach broader adaption, because the ecosystem must stabelize. No business oriented project manager would choose Rust as an alterative to Go or Java while Rust has "only" a community http lib on version 0.12. Sure, async needs to be shipped and polished, but then Rust needs to tell the world: "We have all you need and as stable as you need."

I like the way Go proceeds as a language, with features added very very slowly and the compiler and tools regularly improving. I hope Rust can settle down into a similar focus soon.

leetrout 7y ago

Russ Cox gave a talk at GopherCon 2019 and talked about the 4 R's of Simplifying: Reshaping Redefining Removing Restricting And he follows up with examples of how they applied those to the code base. If you've not seen it you might enjoy it. https://www.youtube.com/watch?v=kNHo788oO5Y https://www.youtube.com/watch?v=kNHo788oO5Y

ra7 7y ago
Russ Cox also recently wrote a series of blog posts about Go proposal process, which is also interesting: https://research.swtch.com/proposals https://research.swtch.com/proposals

ragona 7y ago

Heh, I like the way Rust proceeds as a language, with regular releases and improvements. I hope Go can make quality of life improvements with similar speed.

abtinf 7y ago

I hadn’t thought of this before, but I think you are onto something critical about Go. In a different life, I worked deep in C# and the bowels of the CLR. New versions of C# were both exciting (woo, LINQ, anonymous things, lambdas, and a dozen others each release) and frustrating (ugh, visual studio doesn’t have specialized tools to handle this new stuff). I’ve been writing Go for 8 or 9 years now and I value the tool chain improvements far more than the language features. Race detection was a godsend. Indeed, even taking away capabilities (or just being more strict) has been valuable—like when multi-threaded access to slices became an error. In this release, I don’t much care about the new literal prefixes. But I’m excited about the improvement to defer performance and the improved range check panic messages. In a sense, other languages make it easier to to write new code with each release, but every iteration of Go makes my old code better too.

purple_ducks 7y ago
> I like the way Go proceeds as a language, with features added very very slowly and the compiler and tools regularly improving > I value the tool chain improvements far more than the language features Java 6 may be right up your alley (https://en.wikipedia.org/wiki/Java_version_history https://en.wikipedia.org/wiki/Java_version_history)
- orhmeh09 7y ago
  What do you mean by this reference to an older Java version?

rolleiflex 7y ago

I think Go is the only software release at this point to whose releases I respond with ‘Ooh shiny’ and not ‘Oh god’. I love the way they’re doing this — calm, collected, slow, and with ample heads up. At this point, I think we all have some JavaScript PTSD.

fourseventy 7y ago
i feel the same way!
seabrookmx 7y ago
C# obviously has a very different design philosophy than Go, but its releases are moving along at a similar (and IMO, reasonable) pace.
Cthulhu_ 7y ago
Yeah, for me the turnaround point for JS was when they added classes - JS is not an oop language and trying to make it look like one doesn't work. Worse, they didn't even implement it properly - no access modifiers. Call me a bit of a luddite but this is one of the reasons why I'm skeptical about generics in Go - it'll be another language construct to keep in mind. Mind you this opinion of mine is baseless because unfortunately I haven't had the opportunity to do any serious go development yet.

pcwalton 7y ago

Rust moves slowly too. I'm not sure where the idea that Rust makes changes willy-nilly came from, but anyone saying that is deeply unfamiliar with the RFC process. It's extremely hard to get new features into Rust.

asdkhadsj 7y ago
Perhaps it's the number of things changing that leads to the feeling of rapid movement. After all, 60 1mph increases are all tiny by themselves. Not sure if that's true or not though. Rust is my daily driver for the last year and even coming from Go (after 6 years) I don't feel the pace is hard to keep up with, or that my code breaks frequently. In fact, I don't think my code has broke as a result of changes once since I switched to Rust. It has happened .. twice maybe, via dependencies, though.
burntsushi 7y ago
Maybe Rust moves slowly, but not nearly as slow as Go. I know because I use both languages daily. I spend almost no time in Go code keeping up with deprecations, new APIs and new language features. Not all of those things need to go through the RFC process. For example, I don't think there's any backpressure against deprecating stuff right now. As soon as a replacement comes along, a deprecation pretty routinely occurs just a couple releases (a few months) after it. I don't spend a ton of time in Rust responding to churn, but it's definitely noticeable. This is why I've been bleating a bit more now than I have before about reducing churn. N.B. On reflection, perhaps I do have some bias here. My daily work on Go is mostly for $work, and involves one large codebase. My daily work on Rust, however, involves maintenance of dozens of crates. So if there's churn, I feel it repeatedly. So its effect might be magnified for me personally.
est31 7y ago
One example where Rust is moving faster than Go is the compiler: * Excluding patch releases, Go has a release twice each year [1], while Rust has a release every six weeks (about 9 times per year) [2]. * For minor (patch) releases (security updates, etc), Rust only cares about the latest version released. Go provides patch releases for the last two releases [3]. * The latest release of the Go compiler (1.13, Sept 2019) is able to bootstrap itself from Go 1.4 [4], released on Dec 10 2014. The latest release of the Rust compiler 1.37.0 (Aug 15 2019) needs Rust 1.36.0 (Jul 04 2019) for bootstrap. * For the language, I think relative to itself, Rust has considerably slowed down with development compared to the pre-1.0 times. Now it's still evolving more quickly than Go. Rust is getting async_await, const generics, etc while Go is discussing about an error handling operator that Rust already had two revisions of since its 2015 release (try! and ?). I'm not saying that all of this churn that Rust has is bad. Some of it is good, like the tighter release schedule that prevents half finished stuff to be released. But other things, like the tight version range that the compiler can bootstrap from, could be improved. [1]: https://github.com/golang/go/wiki/Go-Release-Cycle https://github.com/golang/go/wiki/Go-Release-Cycle [2]: https://blog.rust-lang.org/2014/12/12/1.0-Timeline.html https://blog.rust-lang.org/2014/12/12/1.0-Timeline.html [3]: https://github.com/golang/go/wiki/MinorReleases https://github.com/golang/go/wiki/MinorReleases [4]: https://golang.org/doc/install/source https://golang.org/doc/install/source

derefr 7y ago

I feel like Go is the way it is, mostly because its maintainers are also responsible for the continued productivity of thousands of engineers working on Google's numerous Go codebases. Any "breaking change" that requires rewriting Go code is a tangible negative for them, in that it'll interrupt Googlers from getting real work done, and the blame will come back to them. In a sense, Go is more like a corporate-internal DSL that the public just happen to be able to use. (Erlang is—or at least, was, for the first ten years of its life—another language that is this way.)

remus 7y ago
Personally I think this is a pretty positive thing. If a language is at all popular then any breaking change is going to mean work for users, and having those users sitting next to you in the office keeps it fresh in your mind when you're tempted to make that "one small change" to the language.
- pcwalton 7y ago
  This thread isn't about breaking changes, though. Neither Rust nor Go make breaking changes.
gameswithgo 7y ago
Rust doesn't really introduce breaking changes. There is just a lot of cognitive power required to keep up with everything, which can make it hard to read other people's code, or know which is the 'best' way to do a thing, etc. People who disagree with this may simply have more cognitive power/time to devote to keeping up with everything in Rust. I have a day job in an entirely different universe, so keeping up with Rust is hard.

kzrdude 7y ago

Rust has a focus - it is articulated through the roadmap. - 2018 roadmap https://blog.rust-lang.org/2018/03/12/roadmap.html https://blog.rust-lang.org/2018/03/12/roadmap.html - 2019 roadmap https://blog.rust-lang.org/2019/04/23/roadmap.html https://blog.rust-lang.org/2019/04/23/roadmap.html It's a big community, and it has time for a lot of development

bsaul 7y ago

Rust can't settle down right now, because it still has to make necessary changes to critical parts of the language, such as async. Go always had a very narrow and precise ambition and scope (a better C, aimed at server-side data plumbing). Which is the reason why it was able to nail a set of features from the start and keep it that way. Rust has a much wider ambition : all the modern languages facilities (generics, metaprogramming, etc) with the speed of C, AND breakthrough memory-safety features. Go doesn't try to innovate, and i suppose the author see innovation as something you should stay away until it's nothing new anymore.

littlestymaar 7y ago
> a better C, aimed at server-side data plumbing I agree with all what you said but this. Go isn't a better C, it's a better Java.
- root_axis 7y ago
  I think in practice it has become something closer to a better python than a better java.
  - earenndil 7y ago
    Personally, I don't think it's better than any of those languages.
  - meowface 7y ago
    More like a "different Python" than a better one. Way more performant, way more verbose, and (IMO) way better concurrency. Not to go off on too much of a tangent, but I think asyncio is a huge mess and was a mistake. I still use gevent for everything in Python. https://glyph.twistedmatrix.com/2014/02/unyielding.html https://glyph.twistedmatrix.com/2014/02/unyielding.html is frequently cited as an argument for why goroutines and gevent and green threads suck and why explicit asyncio-style concurrency is better, but I have a lot of issues with this article and find the former two way easier, simpler, and faster to work with.
- 7y ago

JTenerife 7y ago

Rust needs to settle down to reach broader adaption, because the ecosystem must stabelize. No business oriented project manager would choose Rust as an alterative to Go or Java while Rust has "only" a community http lib on version 0.12. Sure, async needs to be shipped and polished, but then Rust needs to tell the world: "We have all you need and as stable as you need."