5 ms·

Yea I think this concept just doesn’t resonate deeply with the rust community for some reason

dodobirdlord 7y ago
> When a new version of Rust is released, the core Rust devs write a blog post gleefully explaining all the new "features" the current version has. What these devs perhaps fail to appreciate is that not having new features can itself be a feature. Rust is trying to solve a set of problems, some combination of which exist in pretty much every programming language that exists today (including Rust). "Have you considered giving up?" is obviously not a very interesting question and not one that's going to get much traction.
- ddevault 7y ago
  The question is not "have you considered giving up?", but rather "have you considered when this will be finished?"
  - ironmagma 7y ago
    From using Rust, it’s clear there is still a lot of work to be done. Someday Rust will be stable and mature, but it isn’t now, and it doesn’t look like it will be a year from now either. The plasticity of the language honestly is what allows it to continue to innovate where others do not. Let’s let Rust find its niche and then lock it down, and not rush it or we’ll be regretting it in a few years.
  - DeathArrow 7y ago
    Try Cobol, it's pretty much finished.
    - moogly 6y ago
      The latest version was released in 2014
  - steveklabnik 7y ago
    The only languages that are “finished” are the ones nobody uses. Heck, C’s latest standard is from 2018. And there’s probably gonna be a new one next year. Most changes are minor, but sometimes they’re bigger. Just like any language. It moves much slower than most languages, but it’s still moving.
    - ddevault 6y ago
      C's 2018 standard cannot be compared to Rust's development in good faith. C didn't add anything new - it just clarifies edge cases, and does not change downstream C code in meaningful ways. And that constitutes 7 years of C development.
      - AndrewGaspar 6y ago
        New Rust versions don't change downstream Rust code either, except in edge cases. And those edge cases are only to fix potential security vulnerabilities.
        ddevault 6y ago
        Changing the definition of idiomatic counts as changing downstream code.
        deleted 6y ago
        [deleted]
        kelnos 6y ago
        Only if you feel like you need to constantly update your code to be idiomatic, which is absolutely unnecessary. No one has to change their code to conform to whatever the new version of "idiomatic" is. Their code will continue to work, and it won't be "bad".
      - steveklabnik 6y ago
        C 2018 was a small release, sure. There are bigger ones. C11 added an entire memory model. > it just clarifies edge cases, and does not change downstream C code in meaningful ways. This is exactly the same as Rust. (Again, with the small exception of soundness fixes, which, depending on impact, we sometimes leave a year of warnings in before actually changing.)
  - deleted 7y ago
    [deleted]
- lmm 7y ago
  > Rust is trying to solve a set of problems, some combination of which exist in pretty much every programming language that exists today (including Rust). There's a well-known feature in similar languages that would solve at least two of the mentioned cases in one go: https://philipnilsson.github.io/Badness10k/escaping-hell-with-monads/ https://philipnilsson.github.io/Badness10k/escaping-hell-wit...
  - dodobirdlord 7y ago
    Hopefully someday, but nothing is free until someone comes up with a zero-cost abstraction, and in the meantime Haskell relies on a garbage collector. Thank you for the link, I enjoyed it a great deal!
    - lmm 7y ago
      There's no reason monad shouldn't be a zero-cost abstraction, to the same extent as any other trait (i.e. using them in cases where the type is not statically known would require boxing, but the abstraction is not really a cost overhead in that case since you simply couldn't write that code at all without it). Haskell currently uses a garbage collector, as do most languages that we could look to for inspiration, but I don't see that that's an essential barrier. The part I would be worried about doing in the presence of a borrow checker would be being able to form first-class functions, especially closures, but Rust already has those! AFAICS the only other "hard" part is having higher-kinded types and preserving good type inference, but the solution to that is already known (Hindley-Milner).
    - marcosdumay 6y ago
      I didn't look deep enough to be confident, but I don't understand Rust's issue with do notation. It already has monads, and uses them in a lot of places. Do notation is just syntax sugar.
      - steveklabnik 6y ago
        Here's one simple part of this very large and thorny problem: each of Rust's monad instances does not share the same type signature, even for similar methods. This is because Rust has more novel features that appear in type signatures.
- frankmcsherry 6y ago
  I don't think it's about giving up, but accepting that churn has costs. Of the first 15 or so Rust releases, 4 of them caused library code I maintain (timely dataflow) to publicly break. They were all minor "paper cut" breaks that one could fix by changing the syntax, but several were in the public APIs (most were around convenience features, clashing in namespaces). The stated position of the Rust team was that it is ok to break code in this way. I brought this up with some of the team; I do think they are more aware of it now; many are still more excited to land new things than preserve the experience of the users (I'm ok with that, but it is what it is).
Ar-Curunir 7y ago
What concept? Stagnation?
- SaxonRobber 7y ago
  At what point is enough enough?
inimino 7y ago
Self-selection? There are already many other programming languages that appeal more to those who value elegance or minimalism, so those using Rust either lack the organ that senses elegance, or simply picked Rust anyway because of some other reasons.

> When a new version of Rust is released, the core Rust devs write a blog post gleefully explaining all the new "features" the current version has. What these devs perhaps fail to appreciate is that not having new features can itself be a feature. Rust is trying to solve a set of problems, some combination of which exist in pretty much every programming language that exists today (including Rust). "Have you considered giving up?" is obviously not a very interesting question and not one that's going to get much traction.

ddevault 7y ago
The question is not "have you considered giving up?", but rather "have you considered when this will be finished?"
- ironmagma 7y ago
  From using Rust, it’s clear there is still a lot of work to be done. Someday Rust will be stable and mature, but it isn’t now, and it doesn’t look like it will be a year from now either. The plasticity of the language honestly is what allows it to continue to innovate where others do not. Let’s let Rust find its niche and then lock it down, and not rush it or we’ll be regretting it in a few years.
- DeathArrow 7y ago
  Try Cobol, it's pretty much finished.
  - moogly 6y ago
    The latest version was released in 2014
- steveklabnik 7y ago
  The only languages that are “finished” are the ones nobody uses. Heck, C’s latest standard is from 2018. And there’s probably gonna be a new one next year. Most changes are minor, but sometimes they’re bigger. Just like any language. It moves much slower than most languages, but it’s still moving.
  - ddevault 6y ago
    C's 2018 standard cannot be compared to Rust's development in good faith. C didn't add anything new - it just clarifies edge cases, and does not change downstream C code in meaningful ways. And that constitutes 7 years of C development.
    - AndrewGaspar 6y ago
      New Rust versions don't change downstream Rust code either, except in edge cases. And those edge cases are only to fix potential security vulnerabilities.
      - ddevault 6y ago
        Changing the definition of idiomatic counts as changing downstream code.
        deleted 6y ago
        [deleted]
        kelnos 6y ago
        Only if you feel like you need to constantly update your code to be idiomatic, which is absolutely unnecessary. No one has to change their code to conform to whatever the new version of "idiomatic" is. Their code will continue to work, and it won't be "bad".
    - steveklabnik 6y ago
      C 2018 was a small release, sure. There are bigger ones. C11 added an entire memory model. > it just clarifies edge cases, and does not change downstream C code in meaningful ways. This is exactly the same as Rust. (Again, with the small exception of soundness fixes, which, depending on impact, we sometimes leave a year of warnings in before actually changing.)
- deleted 7y ago
  [deleted]
lmm 7y ago
> Rust is trying to solve a set of problems, some combination of which exist in pretty much every programming language that exists today (including Rust). There's a well-known feature in similar languages that would solve at least two of the mentioned cases in one go: https://philipnilsson.github.io/Badness10k/escaping-hell-with-monads/ https://philipnilsson.github.io/Badness10k/escaping-hell-wit...
- dodobirdlord 7y ago
  Hopefully someday, but nothing is free until someone comes up with a zero-cost abstraction, and in the meantime Haskell relies on a garbage collector. Thank you for the link, I enjoyed it a great deal!
  - lmm 7y ago
    There's no reason monad shouldn't be a zero-cost abstraction, to the same extent as any other trait (i.e. using them in cases where the type is not statically known would require boxing, but the abstraction is not really a cost overhead in that case since you simply couldn't write that code at all without it). Haskell currently uses a garbage collector, as do most languages that we could look to for inspiration, but I don't see that that's an essential barrier. The part I would be worried about doing in the presence of a borrow checker would be being able to form first-class functions, especially closures, but Rust already has those! AFAICS the only other "hard" part is having higher-kinded types and preserving good type inference, but the solution to that is already known (Hindley-Milner).
  - marcosdumay 6y ago
    I didn't look deep enough to be confident, but I don't understand Rust's issue with do notation. It already has monads, and uses them in a lot of places. Do notation is just syntax sugar.
    - steveklabnik 6y ago
      Here's one simple part of this very large and thorny problem: each of Rust's monad instances does not share the same type signature, even for similar methods. This is because Rust has more novel features that appear in type signatures.
frankmcsherry 6y ago
I don't think it's about giving up, but accepting that churn has costs. Of the first 15 or so Rust releases, 4 of them caused library code I maintain (timely dataflow) to publicly break. They were all minor "paper cut" breaks that one could fix by changing the syntax, but several were in the public APIs (most were around convenience features, clashing in namespaces). The stated position of the Rust team was that it is ok to break code in this way. I brought this up with some of the team; I do think they are more aware of it now; many are still more excited to land new things than preserve the experience of the users (I'm ok with that, but it is what it is).

Ar-Curunir 7y ago

What concept? Stagnation?

SaxonRobber 7y ago
At what point is enough enough?

inimino 7y ago

Self-selection? There are already many other programming languages that appeal more to those who value elegance or minimalism, so those using Rust either lack the organ that senses elegance, or simply picked Rust anyway because of some other reasons.