11 ms·

Rust seems to change constantly, because it's changing so slowly. The 1.0 release has held back a lot of stuff to avoid stabilizing wrong things, and it's now s

by pornel 7y ago

Rust seems to change constantly, because it's changing so slowly. The 1.0 release has held back a lot of stuff to avoid stabilizing wrong things, and it's now slowly backfilling the missing features bit by bit. Instead of starting with a fat standard library, it started with minimal one and now each release adds 2-3 functions that could have been there in 2015. But none of it is idiom-changing revolution. These are mostly convenience functions, and you don't have to use them all just because they're there. Every addition to the language is bikeshedded to death, goes through betas, revisions, refinements, before being stabilized years later. The first experimental release of async was 4 years ago and it has landed last November. So you may hear about new features a lot and they churn in nightlies, but actual big changes reach stable rarely. Apart from async/await, since 2015 Rust made only 2 changes to how idiomatic code looks like (? for errors, and 2018 modules), and both of them can be applied to code automatically. I maintain over 60 Rust crates, some of them as old as Rust itself. All work fine as they are, and running `cargo fix` once was enough to keep them looking idiomatic.

k__ 7y ago
I can't comprehend what you're going at. Are they to slow and doing too much design by comitee or are they at an okay speed of innovation?
twic 7y ago
> it's now slowly backfilling the missing features bit by bit This isn't slow. Java went three years, from December 1998 to February 2002, without any language changes. And to be honest, even that wasn't that slow! > Every addition to the language is bikeshedded to death Not to death, because many of them don't die! What i find annoying about Rust's changes is that some of them are so trivial - they change the language for such small improvements. async/await is not in that category, for sure. But Ok-wrapping actually is. The need to Ok-wrap results is a minor annoyance at most. Ditto a bunch of the problems solved by match ergonomics changes. I think the root of the problem is that the changes are driven by a small core of Rust programmers - many working on Rust itself or some of its flagship projects - who are actively involved in the discussions around Rust. They tend to view change as natural, and the cost of change as low. I believe there is a larger group of Rust programmers who are not actively involved in these discussions, and are maybe not spending 100% of their time on Rust, for who the cost is higher. But we don't hear as much from them.
- sgift 7y ago
  > What i find annoying about Rust's changes is that some of them are so trivial - they change the language for such small improvements. async/await is not in that category, for sure. But Ok-wrapping actually is. The need to Ok-wrap results is a minor annoyance at most. Ditto a bunch of the problems solved by match ergonomics changes. So what? Then don't use them. The whole point of full backward compatibility is that you don't have to use new features. This perceived need to always use the newest feature is only in the head of some developers. Neither in the blog post nor here do I see any reason to not make the experience better for people who want it. Even if it's just a "minor" (very subjective, I love the match ergonomics enhancements) annoyance that's fixed by it.
  - jfkebwjsbx 7y ago
    It is not fully backwards compatible between editions, though.
    - sgift 7y ago
      Editions are opt in. You don't opt in, nothing changes for your code.
  - MaulingMonkey 7y ago
    Agreed. I know plenty of codebases still written in C++03 style and work fine. I'm still using 2015 edition Rust crates and they work fine. I won't say there's no cost to evolving idioms, but evolving idioms on this front means it's more of an affront to asthetics than it is to productivity or anything else actually important to business goals, IMO. The one exception perhaps being async/await, in that a bunch of crates are making breaking API changes to accomidate it and bumping their major versions - because it's bloody useful and a bit more than your typical syntactic sugar - which means changing your code if you want to keep getting patches.
  - umanwizard 7y ago
    I can’t force other people not to use changes, which means I will always need the latest version of rustc installed if I want to be able to build a relatively complete selection of the corpus of Rust code, which in turn makes it very difficult if not impossible for rust software to be distributed in typical OS package managers. I.e., imagine how Debian or Ubuntu could package things if the definition of C++ changed every six weeks, given that the compiler version should change as little as possible during a major OS version cycle? This is a major blocker holding Rust back from mainstream adoption, IMO.
ddevault 7y ago
C adds 2-3 features every 10-20 years. That's slow. Rust is not slow.
- mseepgood 7y ago
  > C adds 2-3 features every 10-20 years. This should be the norm for serious programming languages. Anything else is a hyperactive children's toy.
  - whatshisface 7y ago
    I don't get this perspective, are there only three good features invented every decade? Shouldn't it be the quality of the features that counts, not their rate of introduction? Also, I think C might be the only language to get 1.5 features/decade. Fortran has seen a lot of recent editions, and so has Java. Even x86 gets new instructions every arch bump. Are there any other languages that change as slowly as C? If not it may be too elitist to claim that there is only one language in the world that's not a child's toy.
    - mseepgood 7y ago
      > I don't get this perspective, are there only three good features invented every decade? To be honest, programming language design has been a solved problem since the 1950s when LISP came out.
      - api 7y ago
        Why does nobody use it? I've never heard a satisfactory answer from LISPers. "People are dumb" is not a satisfactory answer.
        jdmichal 7y ago
        The best answer I've seen is the Lisp Curse. It's basically the idea that Lisp is so flexible that every project becomes its own DSL / idiomatic version of Lisp. Imagine what's being discussed here, except that every programmer actually has the power to just make the change rather than have to submit it to the central Rust team for consideration and eventual implementation. http://winestockwebdesign.com/Essays/Lisp_Curse.html http://winestockwebdesign.com/Essays/Lisp_Curse.html
jkoudys 7y ago
I _really_ felt that in JavaScript, especially es2015. So many updates came out at once, that people didn't realize many of the benefits they received from new features were now much less important because of other features that were included around the same time. There was a huge rush to use classes, which was sugar around the prototype system, but happened when we also got spread operators, Object.assign, and property name shorthand. We could already easily express the concept of a class far more easily than we were doing before, but because it all came out at the same time it didn't really click for the community at large and a lot of what became idiomatic didn't really feel important enough for a language update. Ditto with generators and async functions, which while merely a very specific application of a generator is far better known. Again, not sure we needed all this extra syntax so you can say `async function foo() { await bar()`, when `co(function* foo() { yield bar()` was already available (if co were simply added to the Promise object). We're also now tying the language to a very specific implementation, when the co approach is explicit about saying what's responsible for taking control from the yielded function (a Promise).

by pornel 7y ago

k__ 7y ago

I can't comprehend what you're going at. Are they to slow and doing too much design by comitee or are they at an okay speed of innovation?

twic 7y ago

> it's now slowly backfilling the missing features bit by bit This isn't slow. Java went three years, from December 1998 to February 2002, without any language changes. And to be honest, even that wasn't that slow! > Every addition to the language is bikeshedded to death Not to death, because many of them don't die! What i find annoying about Rust's changes is that some of them are so trivial - they change the language for such small improvements. async/await is not in that category, for sure. But Ok-wrapping actually is. The need to Ok-wrap results is a minor annoyance at most. Ditto a bunch of the problems solved by match ergonomics changes. I think the root of the problem is that the changes are driven by a small core of Rust programmers - many working on Rust itself or some of its flagship projects - who are actively involved in the discussions around Rust. They tend to view change as natural, and the cost of change as low. I believe there is a larger group of Rust programmers who are not actively involved in these discussions, and are maybe not spending 100% of their time on Rust, for who the cost is higher. But we don't hear as much from them.

sgift 7y ago
> What i find annoying about Rust's changes is that some of them are so trivial - they change the language for such small improvements. async/await is not in that category, for sure. But Ok-wrapping actually is. The need to Ok-wrap results is a minor annoyance at most. Ditto a bunch of the problems solved by match ergonomics changes. So what? Then don't use them. The whole point of full backward compatibility is that you don't have to use new features. This perceived need to always use the newest feature is only in the head of some developers. Neither in the blog post nor here do I see any reason to not make the experience better for people who want it. Even if it's just a "minor" (very subjective, I love the match ergonomics enhancements) annoyance that's fixed by it.
- jfkebwjsbx 7y ago
  It is not fully backwards compatible between editions, though.
  - sgift 7y ago
    Editions are opt in. You don't opt in, nothing changes for your code.
- MaulingMonkey 7y ago
  Agreed. I know plenty of codebases still written in C++03 style and work fine. I'm still using 2015 edition Rust crates and they work fine. I won't say there's no cost to evolving idioms, but evolving idioms on this front means it's more of an affront to asthetics than it is to productivity or anything else actually important to business goals, IMO. The one exception perhaps being async/await, in that a bunch of crates are making breaking API changes to accomidate it and bumping their major versions - because it's bloody useful and a bit more than your typical syntactic sugar - which means changing your code if you want to keep getting patches.
- umanwizard 7y ago
  I can’t force other people not to use changes, which means I will always need the latest version of rustc installed if I want to be able to build a relatively complete selection of the corpus of Rust code, which in turn makes it very difficult if not impossible for rust software to be distributed in typical OS package managers. I.e., imagine how Debian or Ubuntu could package things if the definition of C++ changed every six weeks, given that the compiler version should change as little as possible during a major OS version cycle? This is a major blocker holding Rust back from mainstream adoption, IMO.

ddevault 7y ago

C adds 2-3 features every 10-20 years. That's slow. Rust is not slow.

mseepgood 7y ago
> C adds 2-3 features every 10-20 years. This should be the norm for serious programming languages. Anything else is a hyperactive children's toy.
- whatshisface 7y ago
  I don't get this perspective, are there only three good features invented every decade? Shouldn't it be the quality of the features that counts, not their rate of introduction? Also, I think C might be the only language to get 1.5 features/decade. Fortran has seen a lot of recent editions, and so has Java. Even x86 gets new instructions every arch bump. Are there any other languages that change as slowly as C? If not it may be too elitist to claim that there is only one language in the world that's not a child's toy.
  - mseepgood 7y ago
    > I don't get this perspective, are there only three good features invented every decade? To be honest, programming language design has been a solved problem since the 1950s when LISP came out.
    - api 7y ago
      Why does nobody use it? I've never heard a satisfactory answer from LISPers. "People are dumb" is not a satisfactory answer.
      - jdmichal 7y ago
        The best answer I've seen is the Lisp Curse. It's basically the idea that Lisp is so flexible that every project becomes its own DSL / idiomatic version of Lisp. Imagine what's being discussed here, except that every programmer actually has the power to just make the change rather than have to submit it to the central Rust team for consideration and eventual implementation. http://winestockwebdesign.com/Essays/Lisp_Curse.html http://winestockwebdesign.com/Essays/Lisp_Curse.html

jkoudys 7y ago

I _really_ felt that in JavaScript, especially es2015. So many updates came out at once, that people didn't realize many of the benefits they received from new features were now much less important because of other features that were included around the same time. There was a huge rush to use classes, which was sugar around the prototype system, but happened when we also got spread operators, Object.assign, and property name shorthand. We could already easily express the concept of a class far more easily than we were doing before, but because it all came out at the same time it didn't really click for the community at large and a lot of what became idiomatic didn't really feel important enough for a language update. Ditto with generators and async functions, which while merely a very specific application of a generator is far better known. Again, not sure we needed all this extra syntax so you can say `async function foo() { await bar()`, when `co(function* foo() { yield bar()` was already available (if co were simply added to the Promise object). We're also now tying the language to a very specific implementation, when the co approach is explicit about saying what's responsible for taking control from the yielded function (a Promise).