4 ms·

> 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

> 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 7y 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 7y 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 7y 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 7y 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 7y ago
      Thanks through I still don't get it. I only know that you can get backtraces of errors by setting `RUST_BACKTRACE=1`.
      - est31 7y ago
        That only gives you backtraces for panics, but not for errors based on the Result<,> type.
        lzutao 7y ago
        I am not serious. Often in these cases I would use printf debugging to know where the errors came. (I am still a Rust beginner).

dpc_pw 7y 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 7y 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 7y 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 7y 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 7y ago
    Thanks through I still don't get it. I only know that you can get backtraces of errors by setting `RUST_BACKTRACE=1`.
    - est31 7y ago
      That only gives you backtraces for panics, but not for errors based on the Result<,> type.
      - lzutao 7y ago
        I am not serious. Often in these cases I would use printf debugging to know where the errors came. (I am still a Rust beginner).