7 ms·

> The rust RFC process is a graveyard of good ideas. I actually have quite an opposite view: I think the Rust core team is 100% correct to make it very hard to

> The rust RFC process is a graveyard of good ideas. I actually have quite an opposite view: I think the Rust core team is 100% correct to make it very hard to add new "features" to the PL, in order to prevent the "language surface" from being bloated, inconsistent and unpredictable. I've seen this happen before: I started out as a Swift fan, even though I have been working with Objective-C++ for years, considered it an awesome powerhouse and I did not really need a new PL for anything in particular in the world of iOS development. With time, Swift's insistence on introducing tons of new language "features" such as multiple, redundant function names, e.g., "isMultiple(of:)", multiple rules for parsing curly braces at al. to make the SwiftUI declarative paradigm possible, multiple rules for reference and value types and mutability thereof, multiple shorthand notations such as argument names inside closures, etc. - all that made me just dump Swift altogether. I would have to focus on Swift development exclusively just to keep up, which I was not willing to do. Good ideas are "dime a dozen". Please keep Rust as lean as possible.

formerly_proven 2y ago
> Please keep Rust as lean as possible. Alternatively: Rust is already the Wagyu of somewhat-mainstream PLs, don't keep adding fat until it's inedible.
- deleted 2y ago
  [deleted]
josephg 2y ago
Author here. I hear what you're saying. But there's lots of times while using rust where the language supports feature X and feature Y, but the features can't be used together. For example, you can write functions which return an impl Trait. And structs can contain arbitrary fields. But you can't write a struct which contains a value returned via impl Trait - because you can't name the type. Or, I can write if a && b. And I can write if let Some(x) = x. But I can't combine those features together to write if let Some(x) = x && b. I want things like this to be fixed. Do I want rust to be "bigger"? I mean, measured by the number of lines in the compiler, probably yeah? But measured from the point of view of "how complex is rust to learn and use", feature holes make the language more complex. Fixing these problems would make the language simpler to learn and simpler to use, because developers don't have to remember as much stuff. You can just program the obvious way. Pin didn't take much work to implement in the standard library. But its not a "lean" feature. It takes a massive cognitive burden to use - to say nothing of how complex code that uses it becomes. I'd rather clean, simple, easy to read rust code and a complex borrow checker than a simple compiler and hard to use language.
- valenterry 2y ago
  Yeah, I agree wholeheartedly with that. This is also what I really dislike in many languages. You should have a look at Scala 3. Not saying that I'm perfectly happy with the direction of the language - but Scala really got those foundations well and made it so that it has few features but they are very powerful and can be combined very well. Rust took a lot of inspiration from Scala for a reason - but then Rust wants to achieve zero-cost abstraction and do high-performance, so it has to make compromises accordingly for good reasons. Some of those compromises affect the ergonomics of the language unfortunately.
- gary17the 2y ago
  I think it would be helpful to clearly distinguish between PL simplification (e.g., "if let Some(x) = x, x == 42 {}") and convenience-driven PL expansion (e.g., "let @discardable lhs = rhs ?? 0;"). In case of the former, I'm with you. In case of the latter, I'm not. Rust likely isn't meant to be a tool that is easy to learn at all costs (since the borrow checker does exist, after all). Rust is, IMvHO, supposed to be like vi: hard to learn and easy to use :).
  - adastra22 2y ago
    We should strive for easy to learn, easy to use.
    - Measter 2y ago
      Though we should also accept that some things are just hard. Though that's not to say that we should give up on trying to make them as easy to learn and use as possible.
      - adastra22 2y ago
        I don’t know. This certainly isn’t provable. What’s the difference between a something being intrinsically difficult and something for which adequate UI just hasn’t been figured out yet? I don’t know anything that hasn’t been made simpler and easier over time.
hiimkeks 2y ago
I general I agree, but we are also in the paradoxical situation that generic associated constants in traits are stable, but you can't actually use them as constants. You can't use them as const generics for other types, and you can't use them for array lengths. I'd argue that this makes them pretty useless: if you just want a value that you can use like any other, then you can define a function that returns it and be done with it. Now we have another way to do it, and in theory it could do more, but that RFC has been stale for several years, nobody seems to be working on it, and I believe it's not even in nightly. If the support would actually be good, we could just get rid of all the support crates we have in cryptography libraries (like the generic_array and typenum crates). That said, I agree that the Rust team should be careful about adding features.
- nicce 2y ago
  > Now we have another way to do it, and in theory it could do more, but that RFC has been stale for several years, nobody seems to be working on it, and I believe it's not even in nightly. What is this way? I have been fighting with this problem for quite some time recently.
goodpoint 2y ago
> Good ideas are "dime a dozen". Please keep Rust as lean as possible. Good ideas are rare and precious by definition.
- gary17the 2y ago
  I think it would be helpful to clearly distinguish between "good ideas" and "excellent ideas". It's relatively easy in the complex art of programming to come up with a dozen good ideas. It seems very hard in the complex art of programming to come up with even one truly excellent idea.
kazinator 2y ago
It's easier to write RFCs than to implement them, and there are more people who can write RFCs. At any popularity level, you have more of the former. Therefore, an RFC queue will always look like a graveyard of good ideas, even if 100% of the queued ideas are being accepted and eventually worked on, simply due to the in/out differential rate. If you want an edge over the people who are writing RFCs, don't write an RFC. Write a complete, production-ready implementation of your idea, with documentation and test cases, which can be cleanly merged into the tree.
- JoshTriplett 2y ago
  > If you want an edge over the people who are writing RFCs, don't write an RFC. Write a complete, production-ready implementation of your idea, with documentation and test cases, which can be cleanly merged into the tree. Please by all means provide an implementation, but do write the RFC first. (Or in some cases smaller processes, such as the ACP process for a small standard-library addition.) Otherwise you may end up wasting a lot of effort, or having to rewrite the implementation. We are unlikely to accept a large feature, or even a medium feature, directly from a PR without an RFC.
  - estebank 2y ago
    I've noticed that having even a minimal implementation helps a lot to inform the RFC: some details are non-obvious until you are either forced to clamp down behavior or have tried to use the feature. The RFC discussion doesn't always surface these. I've also been thinking that we should go over our stabilized RFCs and add an appendix to all of them documenting how the current implementation diverges from the original proposal.
    - JoshTriplett 2y ago
      Absolute agreement on both counts.
    - steveklabnik 2y ago
      This is why back in 2018 I was so excited by moving the RFC process to a staged one. Niko wrote up his version of the idea on his blog back then: https://smallcultfollowing.com/babysteps/blog/2018/06/20/proposal-for-a-staged-rfc-process/ https://smallcultfollowing.com/babysteps/blog/2018/06/20/pro... Stages let you build consensus at more points. You could imagine RFCs go through stages of consensus: First a proposal phase, where agreement is found that this is a problem worth solving and the broad strokes of the idea. This would be the similar to the summary and motivation sections of current RFCs. Then an implementation phase, where a design is sketched out. I think the timing between this stage and the next is one of the more interesting/weak parts of this proposal, but the point is mostly that these things don't have to be strictly done in order, just that you make the points at which consensus to move forward is found in order. Next, there'd be a design review phase. This would be a specific proposal based on feedback from the implementation, kind of like the Detailed Design section of the current RFC process. Finally, you'd accept the design, and the RFC would move into a terminal "it's done" stage. Anyway, just throwing that out there. You all still have a ton of stuff to do, of course, but this is something I really wish I could have actually pushed for back in the day. I think it would make it easier to move on bigger things, and give outsiders a much better idea of how close an RFC is to becoming reality.

formerly_proven 2y ago

> Please keep Rust as lean as possible. Alternatively: Rust is already the Wagyu of somewhat-mainstream PLs, don't keep adding fat until it's inedible.

deleted 2y ago
[deleted]

josephg 2y ago

Author here. I hear what you're saying. But there's lots of times while using rust where the language supports feature X and feature Y, but the features can't be used together. For example, you can write functions which return an impl Trait. And structs can contain arbitrary fields. But you can't write a struct which contains a value returned via impl Trait - because you can't name the type. Or, I can write if a && b. And I can write if let Some(x) = x. But I can't combine those features together to write if let Some(x) = x && b. I want things like this to be fixed. Do I want rust to be "bigger"? I mean, measured by the number of lines in the compiler, probably yeah? But measured from the point of view of "how complex is rust to learn and use", feature holes make the language more complex. Fixing these problems would make the language simpler to learn and simpler to use, because developers don't have to remember as much stuff. You can just program the obvious way. Pin didn't take much work to implement in the standard library. But its not a "lean" feature. It takes a massive cognitive burden to use - to say nothing of how complex code that uses it becomes. I'd rather clean, simple, easy to read rust code and a complex borrow checker than a simple compiler and hard to use language.

valenterry 2y ago
Yeah, I agree wholeheartedly with that. This is also what I really dislike in many languages. You should have a look at Scala 3. Not saying that I'm perfectly happy with the direction of the language - but Scala really got those foundations well and made it so that it has few features but they are very powerful and can be combined very well. Rust took a lot of inspiration from Scala for a reason - but then Rust wants to achieve zero-cost abstraction and do high-performance, so it has to make compromises accordingly for good reasons. Some of those compromises affect the ergonomics of the language unfortunately.
gary17the 2y ago
I think it would be helpful to clearly distinguish between PL simplification (e.g., "if let Some(x) = x, x == 42 {}") and convenience-driven PL expansion (e.g., "let @discardable lhs = rhs ?? 0;"). In case of the former, I'm with you. In case of the latter, I'm not. Rust likely isn't meant to be a tool that is easy to learn at all costs (since the borrow checker does exist, after all). Rust is, IMvHO, supposed to be like vi: hard to learn and easy to use :).
- adastra22 2y ago
  We should strive for easy to learn, easy to use.
  - Measter 2y ago
    Though we should also accept that some things are just hard. Though that's not to say that we should give up on trying to make them as easy to learn and use as possible.
    - adastra22 2y ago
      I don’t know. This certainly isn’t provable. What’s the difference between a something being intrinsically difficult and something for which adequate UI just hasn’t been figured out yet? I don’t know anything that hasn’t been made simpler and easier over time.

hiimkeks 2y ago

I general I agree, but we are also in the paradoxical situation that generic associated constants in traits are stable, but you can't actually use them as constants. You can't use them as const generics for other types, and you can't use them for array lengths. I'd argue that this makes them pretty useless: if you just want a value that you can use like any other, then you can define a function that returns it and be done with it. Now we have another way to do it, and in theory it could do more, but that RFC has been stale for several years, nobody seems to be working on it, and I believe it's not even in nightly. If the support would actually be good, we could just get rid of all the support crates we have in cryptography libraries (like the generic_array and typenum crates). That said, I agree that the Rust team should be careful about adding features.

nicce 2y ago
> Now we have another way to do it, and in theory it could do more, but that RFC has been stale for several years, nobody seems to be working on it, and I believe it's not even in nightly. What is this way? I have been fighting with this problem for quite some time recently.

goodpoint 2y ago

> Good ideas are "dime a dozen". Please keep Rust as lean as possible. Good ideas are rare and precious by definition.

gary17the 2y ago
I think it would be helpful to clearly distinguish between "good ideas" and "excellent ideas". It's relatively easy in the complex art of programming to come up with a dozen good ideas. It seems very hard in the complex art of programming to come up with even one truly excellent idea.

kazinator 2y ago

It's easier to write RFCs than to implement them, and there are more people who can write RFCs. At any popularity level, you have more of the former. Therefore, an RFC queue will always look like a graveyard of good ideas, even if 100% of the queued ideas are being accepted and eventually worked on, simply due to the in/out differential rate. If you want an edge over the people who are writing RFCs, don't write an RFC. Write a complete, production-ready implementation of your idea, with documentation and test cases, which can be cleanly merged into the tree.

JoshTriplett 2y ago
> If you want an edge over the people who are writing RFCs, don't write an RFC. Write a complete, production-ready implementation of your idea, with documentation and test cases, which can be cleanly merged into the tree. Please by all means provide an implementation, but do write the RFC first. (Or in some cases smaller processes, such as the ACP process for a small standard-library addition.) Otherwise you may end up wasting a lot of effort, or having to rewrite the implementation. We are unlikely to accept a large feature, or even a medium feature, directly from a PR without an RFC.
- estebank 2y ago
  I've noticed that having even a minimal implementation helps a lot to inform the RFC: some details are non-obvious until you are either forced to clamp down behavior or have tried to use the feature. The RFC discussion doesn't always surface these. I've also been thinking that we should go over our stabilized RFCs and add an appendix to all of them documenting how the current implementation diverges from the original proposal.
  - JoshTriplett 2y ago
    Absolute agreement on both counts.
  - steveklabnik 2y ago
    This is why back in 2018 I was so excited by moving the RFC process to a staged one. Niko wrote up his version of the idea on his blog back then: https://smallcultfollowing.com/babysteps/blog/2018/06/20/proposal-for-a-staged-rfc-process/ https://smallcultfollowing.com/babysteps/blog/2018/06/20/pro... Stages let you build consensus at more points. You could imagine RFCs go through stages of consensus: First a proposal phase, where agreement is found that this is a problem worth solving and the broad strokes of the idea. This would be the similar to the summary and motivation sections of current RFCs. Then an implementation phase, where a design is sketched out. I think the timing between this stage and the next is one of the more interesting/weak parts of this proposal, but the point is mostly that these things don't have to be strictly done in order, just that you make the points at which consensus to move forward is found in order. Next, there'd be a design review phase. This would be a specific proposal based on feedback from the implementation, kind of like the Detailed Design section of the current RFC process. Finally, you'd accept the design, and the RFC would move into a terminal "it's done" stage. Anyway, just throwing that out there. You all still have a ton of stuff to do, of course, but this is something I really wish I could have actually pushed for back in the day. I think it would make it easier to move on bigger things, and give outsiders a much better idea of how close an RFC is to becoming reality.