4 ms·

> Due to our stability policy, `description` will never be removed .. Can this sort of removal not happen as part of an edition? Is it because it's part of std

• steveklabnik 7y ago
  The standard library cannot change per-edition, that's correct.
  • GolDDranks 7y ago
    I guess that it _would_ be possible to have a hard "edition lint" that would basically forbid you from _implementing_ description in a 2021 or whatever crate. It would still exist and be callable, but no new (non-default) implementations if you want to use new editions.
• burntsushi 7y ago
  Editions do not permit arbitrary breaking changes. Notably, the same version of std must work across all extant editions of std. For example, many people use the `regex` crate in their Rust 2018 projects despite the fact that `regex` still uses Rust 2015. If Rust 2018 made a breaking change to std, this wouldn't be possible in general.
  • est31 7y ago
    You could add an edition sensitive non-overridable error to the language, as in, if you use it on edition 2015 or 2018, there is no problem, but on edition 2021 and beyond there will be an error in your code that you can't allow away. Then you could have edition specific rustdocs for std where items that are deprecated this way are hidden per default. However, at least the 2018 edition had the requirement that updating can be done automatically. Ensuring that is hard for library functions.
    • irishsultan 7y ago
      The problem is that it would be possible for a Rust 2015 module to encounter an Error defined in Rust 202X, so what would happen if that Rust 2015 called `description` on that error if Rust 202X didn't require/allow defining the method `description`?
      • est31 7y ago
        > what would happen if that Rust 2015 called `description` on that error if Rust 202X didn't require/allow defining the method `description`? It's already not required to be defined. Since 1.27.0 there is a default implementation that contains a "description is deprecated" msg. https://doc.rust-lang.org/1.42.0/src/std/error.rs.html#139 https://doc.rust-lang.org/1.42.0/src/std/error.rs.html#139
      • GolDDranks 7y ago
        `description` is still a default method, so the default implementation provided by the Error trait would be called.
      • pas 7y ago
        If your main crate is edition 202X, then it could warn if you link it with anything that depends on Error.description. Too drastic (and would be dog slow)? Yes, but it's easily possible.
  • ithrow 7y ago
    If you know Python and putting libraries aside, talking about raw code, do you think you can be as productive in Rust as in Python?
    • burntsushi 7y ago
      Bad person to ask. I am personally terribly unproductive with Python. I might be able to hammer out a 50 line script that does some data shuffling faster than I could write an equivalent Rust program, but anything more than that---especially when it comes to maintaining it---and Rust easily wins for me in terms of productivity. Nothing against Python specifically. I've just tried and failed over and over again to build large programs in untyped languages. I like my types and think they are invaluable, especially when it comes to refactoring.
    • mikekchar 7y ago
      I've worked professionally using something like 20 different programming languages. Heck, I use 4 or so in my current job. Productivity as a programmer is rarely influenced much by programming language, as long as the programmer is proficient in that language, IMHO. I've never actually used Python professionally, but I've programmed for years in Ruby and Javascript as well as C#, C++, etc, etc. The vast majority of complexity in a code base is added by the programmer themselves and that complexity has less to do with programming language issues than it does with design (or lack thereof). Even on small projects, the ability to do something quickly is almost completely due to having a reuse library that gets you most of the way there coupled with the knowledge of how to use that reuse library. Experts in particular ecosystems can often bang out code at frightening speed. Similarly, complete horrible messes can easily be written in any programming language. Rust helps you deal with certain classes of problems. It forces you to write code in a certain way and think in a certain way. Especially if you are using the standard library, you have less flexibility on how you can write your code if you don't want to write a complete mess. In many ways this is an advantage -- especially if you are very experienced with the ecosystem. Programming languages like Python or Ruby and especially JS (which has a terrible standard library) offer more flexibility. However, it comes at the cost that it's easy to get yourself into trouble. In the end, these things usually come out in the wash. Programming is programming. Some people are always going to like doing things one way or another. I actually love writing code in JS because I find it a very expressive language (and my code looks nothing like most people would expect JS code to look like). In some ways, Rust is like programming in a straight jacket, but it's a comfortable straight jacket :-). I like the shape of code that Rust encourages me to write. As I get more proficient in the language (not so proficient yet), I find that I think less and less about how to do things and more and more about what I want to do -- like any language, really. The main downside of Rust is that it is huge and opinionated. It takes a long time to learn how to use it well and it really wants to push you towards certain types of solutions. Learning all of these things is challenging. TL;DR: Yes, you can definitely be as productive in Rust as in Python. And vice versa. Modulus the fact that you will be running into different problems with each.