4 ms·

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 proce

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
- pcwalton 7y ago
  Does the compiler bootstrap version matter though? Taking the principle that compilers should compile on the most easily accessible toolchain, writing the compiler in C++ would be the best option of all. But nobody wants to do that.
  - est31 7y ago
    Yeah, if you take the principle further it would be even better to write it in C89 because this language is comparatively easy to write compilers for. But the principle is not absolute and it doesn't stand above everything else. There are major differences in how easy it is to write compilers in C++ vs C89. There are major differences between C++ and Rust with its ADTs and pattern matching. But are there major differences between, say Rust 1.32 and Rust 1.36? I'd argue no. There are real use cases like distros wanting to maintain/bootstrap a Rust compiler independently from upstream binaries. The more often these people have to port a compiler, the more troublesome it is for them. Rust seems like it's the odd one out: Swift is written in C++, Go supports bootstrapping from years old compilers, LLVM does so as well, and GCC has probably some of the best backwards compatibility stories out there.
    - pjmlp 7y ago
      Why the odd one? D has been replacing the C++ code with D, .NET made a major reboot with Rosyln where VB.NET and C# got bootstraped (F# was already bootstrapped), OCaml and Haskell have only the runtime in C due to convinience with everything else bootstraped, FreePascal is bootstraped, OpenJDK has the long term goal of replacing C++ with Java/Graal, Jikes was bootstraped in Java, ...
      - est31 7y ago
        You are misunderstanding me. I don't have problems with the fact that Rust is bootstrapped, but with the high rate this bootstrapping is happening. That a 12 week old compiler is already considered as too old to compile the newest rustc. This seems wrong.

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

pcwalton 7y ago
Does the compiler bootstrap version matter though? Taking the principle that compilers should compile on the most easily accessible toolchain, writing the compiler in C++ would be the best option of all. But nobody wants to do that.
- est31 7y ago
  Yeah, if you take the principle further it would be even better to write it in C89 because this language is comparatively easy to write compilers for. But the principle is not absolute and it doesn't stand above everything else. There are major differences in how easy it is to write compilers in C++ vs C89. There are major differences between C++ and Rust with its ADTs and pattern matching. But are there major differences between, say Rust 1.32 and Rust 1.36? I'd argue no. There are real use cases like distros wanting to maintain/bootstrap a Rust compiler independently from upstream binaries. The more often these people have to port a compiler, the more troublesome it is for them. Rust seems like it's the odd one out: Swift is written in C++, Go supports bootstrapping from years old compilers, LLVM does so as well, and GCC has probably some of the best backwards compatibility stories out there.
  - pjmlp 7y ago
    Why the odd one? D has been replacing the C++ code with D, .NET made a major reboot with Rosyln where VB.NET and C# got bootstraped (F# was already bootstrapped), OCaml and Haskell have only the runtime in C due to convinience with everything else bootstraped, FreePascal is bootstraped, OpenJDK has the long term goal of replacing C++ with Java/Graal, Jikes was bootstraped in Java, ...
    - est31 7y ago
      You are misunderstanding me. I don't have problems with the fact that Rust is bootstrapped, but with the high rate this bootstrapping is happening. That a 12 week old compiler is already considered as too old to compile the newest rustc. This seems wrong.