3 ms·

> > However, I think Rust has moved too fast in the language department. ... I'd like the language to stabilize a bit and work on what is currently there > Th

by est31 8y ago

> > However, I think Rust has moved too fast in the language department. ... I'd like the language to stabilize a bit and work on what is currently there > This is actually the major theme of this year! https://blog.rust-lang.org/2019/04/23/roadmap.html https://blog.rust-lang.org/2019/04/23/roadmap.html Major theme of the year, but not major theme of the language. One year of stability followed by one year of working on the next breaking idiom change followed by one year where that change is executed doesn't give you a stable language. Also consider the pace of compiler updates. With C++, I can be very productive with my distro provided compiler. With Rust, the ecosystem is jumping onto new compiler versions so fast that you basically have to use rustup or a rolling release distro when you have a project with a medium amount of crates you depend on (hundreds). Cargo further has no way of recognizing the MSRV of crates and it's updating the index without asking so you can't even safely add new dependencies or update dependencies without increasing the MSRV of your Cargo.lock. All of this can change, and maybe the rate of modifications will slow down. But right now it rather points towards the opposite direction, with the recent introduction of editions.

wtetzner 8y ago
> Major theme of the year, but not major theme of the language. One year of stability followed by one year of working on the next breaking idiom change followed by one year where that change is executed doesn't give you a stable language. Doesn't C++ have exactly this problem? It keeps adding new features, which change the language idioms. It actually seems much worse than Rust in this area, as Rust is mostly re-enforcing the existing idioms, while C++ is almost like two different languages now (well, probably even more than two).
- dpc_pw 8y ago
  > C++ is almost like two different languages now (well, probably even more than two). C++ is a different language in every company I worked for. Ha. Even a different language per team/project sometimes. Tab vs spaces, different capitalization, different indentation style, exceptions vs no-exceptions, 0 is failure vs 1 is failure and then we like featureA, we don't like featureB, and so on.
- est31 8y ago
  The C++ approach of adding new idioms by making the language fatter is of course not as nice as the Rust approach of having breaking changes and disallowing the old idioms. But then again, the people behind Rust have made usage of the try! macro harder for a questionably useful keyword that could have been named differently as well. And now it's part of the 2018 edition and you need two more characters to use the try! macro even though there are still cases where it's much better than ? and nothing is being done about it.
  - lzutao 8y ago
    What are the cases when `try!` macro bettern than `?` operator? I'm a beginner to Rust so I don't know about that.
    - est31 8y ago
      Often when you are getting error messages you would like to find the place they originate. Failure provides backtraces but not everyone uses failure and tbh it's quite a heavy dependency, using serde and so on. With try!, you can easily shadow the macro to e.g. emit a panic. This can be done to basically any codebase using try!, even if it's not yours. Migrating it to use failure is much harder :). It would be cool if you just had a compiler flag that invokes an user settable handler function every time Err() gets constructed or something like that. To give concrete examples, I was developing a library to generate certificates [1]. Often you generate a wrong one though and the parser library you use for testing gives you a Err(BadDer). If that's everything you are getting it can be a bit tough to find out the origins. As it was using ? I had to grep for all the places returning a BadDer error and replace them with a panic. Shadowing try! would have been much easier. [1]: https://github.com/est31/rcgen https://github.com/est31/rcgen
      - lzutao 8y ago
        Thanks through I still don't get it. I only know that you can get backtraces of errors by setting `RUST_BACKTRACE=1`.

by est31 8y ago

wtetzner 8y ago

> Major theme of the year, but not major theme of the language. One year of stability followed by one year of working on the next breaking idiom change followed by one year where that change is executed doesn't give you a stable language. Doesn't C++ have exactly this problem? It keeps adding new features, which change the language idioms. It actually seems much worse than Rust in this area, as Rust is mostly re-enforcing the existing idioms, while C++ is almost like two different languages now (well, probably even more than two).

dpc_pw 8y ago
> C++ is almost like two different languages now (well, probably even more than two). C++ is a different language in every company I worked for. Ha. Even a different language per team/project sometimes. Tab vs spaces, different capitalization, different indentation style, exceptions vs no-exceptions, 0 is failure vs 1 is failure and then we like featureA, we don't like featureB, and so on.
est31 8y ago
The C++ approach of adding new idioms by making the language fatter is of course not as nice as the Rust approach of having breaking changes and disallowing the old idioms. But then again, the people behind Rust have made usage of the try! macro harder for a questionably useful keyword that could have been named differently as well. And now it's part of the 2018 edition and you need two more characters to use the try! macro even though there are still cases where it's much better than ? and nothing is being done about it.
- lzutao 8y ago
  What are the cases when `try!` macro bettern than `?` operator? I'm a beginner to Rust so I don't know about that.
  - est31 8y ago
    Often when you are getting error messages you would like to find the place they originate. Failure provides backtraces but not everyone uses failure and tbh it's quite a heavy dependency, using serde and so on. With try!, you can easily shadow the macro to e.g. emit a panic. This can be done to basically any codebase using try!, even if it's not yours. Migrating it to use failure is much harder :). It would be cool if you just had a compiler flag that invokes an user settable handler function every time Err() gets constructed or something like that. To give concrete examples, I was developing a library to generate certificates [1]. Often you generate a wrong one though and the parser library you use for testing gives you a Err(BadDer). If that's everything you are getting it can be a bit tough to find out the origins. As it was using ? I had to grep for all the places returning a BadDer error and replace them with a panic. Shadowing try! would have been much easier. [1]: https://github.com/est31/rcgen https://github.com/est31/rcgen
    - lzutao 8y ago
      Thanks through I still don't get it. I only know that you can get backtraces of errors by setting `RUST_BACKTRACE=1`.