1. 23
  1.  

  2. 8

    When I was still active in Scala development I wished there were more people interested in something like that.

    But given that leadership’s position on this issue was that making Scala easier to learn doesn’t matter because everyone already knows Scala, I’m not surprised that something like this never happened. Although Rust has too many issues that for me which can’t be fixed anymore, it’s nice to see that at least some languages care about this.

    1. 5

      I don’t understand why they released 1.0 without being confident about these issues. Fixing them without breaking compatibility is going to result in something worse than fixing it before 1.0.

      I understand it’s an enormous project, but Rust feels designed by committee. I’m not excited by it.

      1. 14

        I don’t understand why they released 1.0 without being confident about these issues. Fixing them without breaking compatibility is going to result in something worse than fixing it before 1.0.

        Because you have to release at some point. Especially ergonomics is hard to judge before things find actual widespread use. Many of these things are also rather minor in day-to-day use, but need some amount of learning effort to grock - that can be fixed.

        Also see that some of these are controversial, for example, I’m against dropping “extern” and “mod” declarations, it would - IMHO - introduce lots more implicitness into the language, which doesn’t make it easier.

        1. 1

          for example, I’m against dropping “extern” and “mod” declarations, it would - IMHO - introduce lots more implicitness into the language, which doesn’t make it easier.

          In the case of extern crate, there is no use of “crate” without “extern”, so “extern” is redundant there.

          I agree that getting rid of “mod” declarations in favor of Cargo.toml entries is probably not ready for prime time until tooling is more mature.

        2. 8

          I don’t understand why they released 1.0 without being confident about these issues.

          Because the number of issues will never end. At some point, you have to become happy with what you have and release it.

          1. 8

            There’s also the fact that many things don’t become un-ergonomic until people actually start using them. To borrow the metaphor of tool ergonomics (as in handtools or power tools), you can often find yourself ‘used’ to the rough ergonomics of an old hammer or drill which you’ve used for a while, even if it’s uncomfortable, you learn to ignore the problems, at least until you use a new, better designed tool which doesn’t have those problems. Most people I’m sure can think of a time where they were used to doing things one way, then made a change to how they were doing it to use some new tool, and had a ‘Where have you been all my life’ moment, I suspect that on some level the ergonomic initiative is an attempt to ‘smooth out’ those rough edges which the core developers (who have written enough Rust to become inured to its rough parts) discovered when lots of others started using the language.

            For me, Rust has been hard to adopt not because it’s a bad language (indeed, it checks off the entirety of the checklist of things I’d like in an ideal language), but because the cost in attention needed to learn it has been high enough to not break the threshold of what I can learn in my free time. I don’t know if I’m just prematurely old and “get-off-my-lawn”-y about these things, but the ergonomics of languages matter a lot more to me these days then, say, when I wrote nontrivial amounts of Scheme or Haskell (both of which are languages which I know and like, but have some serious ergonomic issues).

            I also think that ergonomics is one of the big reasons Python, Ruby, and even PHP or Javascript are as popular as they are. While yes, you do give up some benefits when you give up static typing (or, in the case of PHP and Javascript, sanity), the comfort factor of working in Ruby or Python, or the convenience of working in javascript is significant as a ‘smoothing’ factor. Like a rough board smoothed with dozens of layers of finish, the experience of working in the language is so fundamentally pleasant that what structural roughness there is is effectively hidden by the good ergonomics of working in the language. Having a convenient package manager, a clear path to deployment, copious documentation and support tooling, and a relatively pleasant to use language which balances the implicit/explicit tradeoff the OP talks about, you end up with a language which has all the necessary components to be successful despite it’s ‘disadvantages’ of not using all the latest PLT goodness.

            I hope Rust (which does have a lot of that sweet sweet PLT goodness) lowers it’s barrier to entry significantly with these changes, I’m very excited to see the ideas of making the language more ‘Do-what-I-mean’ by careful application of implicit conventions. It already has a wonderful support ecosystem, and killer documentation, I think that a little bit of sanding will put Rust firmly in my “Daily use” bin, which would make me very happy indeed.

          2. 5

            Something that hasn’t been mentioned yet is that the Rust language has a tool for testing new versions of the compiler with every rust program hosted on the package repository. This way, they can gauge how bad breaking changes are going to impact the community, and in rare cases, actually send patches out to those projects before the change lands!