4 ms·

Sure, we can limit the language growth, as soon as we get all the critical features in!

by ben0x539 8y ago

cesarb 8y ago
Every feature is a "critical feature" to someone. You have to know when to stop.
- gdy 8y ago
  That was a sarcastic comment
- galangalalgol 8y ago
  Async/await isn't stable yet, that seems to be making many commenters here wait to adopt, so at least that should make it in before they lock it down. I'd like the platform independent SIMD but that I can admit is niche and could live in nightly for a long time without harming adoption. They have polls to get a feel for the difference between those two categories and which features fall into them.
  - topspin 8y ago
    Landing async/await will be a watershed. Fast, safe, low resource communications applications implemented in Rust will proliferate.
    - cryptonector 8y ago
      It's absolutely essential. A sine qua non for a serious new language.
    - ajross 8y ago
      Or maybe it's just a fad. There have been far more failed IO paradigms than watersheds... I mean, I like it too, but the point upthread is that you can't just suck in every nice-looking idea or you'll end up like C++.
      - qaq 8y ago
        How is adding async await will make Rust into C++ ? Would people actually name the features that should not be in? Outside of ownership and borrowing have Rust added any features that are not mainstream and well proven in other languages?
        ajross 8y ago
        How did adding exceptions to the language make C++ into C++? RTTI? Multiple virtual inheritance? Default member function generation? They didn't, not individually. They were popular and uncontroversial (rather less controversial than promise apis, even). And yet... The point is that Rust seems to be charging blindly down the same road, not that any one feature is going to blow it all up. Frankly IMHO Rust is already harder to learn for a median programmer than C++ is, even if it makes more aesthetic sense to an expert.
        qaq 8y ago
        I think there is fairly large difference between learning and being able to write production ready code. It's hard to imagine a person for whom Rust is hard to learn and who can write safe threaded code in C++ for example.
        ajross 8y ago
        Hundreds of thousands of engineers are writing "production ready" C++ code every day. Your point seems trivially falsifiable, unless you want to turn it into a no-true-scotsman situation and explain how what they're "really" writing isn't "C++" or whatever. I'm not saying Rust is bad. I'm saying it's... becoming senselessly complicated. And that in 20 years when 60% of its amazing new features turn out to be just fashion (because they happens to everything), Rust will be "ugly" then in basically the same way that C++ is now, and we'll all be chasing some other new hotness.
        qaq 8y ago
        1) You omitted threaded 2) I seriously doubt you or I have good stats on how many people who are writing production ready C++ would consider Rust hard.
  - burfog 8y ago
    Async/await appears to require runtime support, possibly even a modern OS. Wasn't rust supposed to be suitable for writing bare-metal code? SIMD at least has hope of running on bare metal. I suppose the ideal is to have it adjustable: compiled to non-SIMD, using typical SIMD hardware, using implicit threads (and thus needing OS support), or using SIMD hardware with threads. I fear the high-level web developers are in the driver's seat, which may doom rust as a systems language. I'm hesitating on rust because I would miss bitfields and various unsafe performance features. I like the opt-out safety of the "unsafe" keyword, but I want more things that I can opt out of. I want goto, computed goto, no-default switches, something like Microsoft's __assume keyword, and all the other low-level stuff you'd want for making boot loaders and high-performance kernels.
    - kam 8y ago
      > Async/await appears to require runtime support, possibly even a modern OS. Wasn't rust supposed to be suitable for writing bare-metal code? You're probably thinking of Tokio, the library for async network IO, which obviously depends on an OS. The async/await language feature compiles down to basically a state machine and has minimal runtime requirements. I'm looking forward to using it on bare-metal microcontrollers.
    - steveklabnik 8y ago
      async/await in Rust produces a single value, a Future. Executing that future requires calling its poll method repeatedly. That can be extremely simple, or it can be more complex. We call "a thing that calls poll repeatedly" an executor, and they can be written without an OS or even the standard library, just fine. The largest, most well known executor is Tokio, which is built on top of OS primitives. If you're writing your own OS, you'd use those primitives. > I fear the high-level web developers are in the driver's seat First, I pretty fundamentally reject this as an idea, but since you don't, please do a Google Scholar search for many of the core team members. They're very much not web developers.

Sure, we can limit the language growth, as soon as we get all the critical features in!

cesarb 8y ago

Every feature is a "critical feature" to someone. You have to know when to stop.

gdy 8y ago
That was a sarcastic comment
galangalalgol 8y ago
Async/await isn't stable yet, that seems to be making many commenters here wait to adopt, so at least that should make it in before they lock it down. I'd like the platform independent SIMD but that I can admit is niche and could live in nightly for a long time without harming adoption. They have polls to get a feel for the difference between those two categories and which features fall into them.
- topspin 8y ago
  Landing async/await will be a watershed. Fast, safe, low resource communications applications implemented in Rust will proliferate.
  - cryptonector 8y ago
    It's absolutely essential. A sine qua non for a serious new language.
  - ajross 8y ago
    Or maybe it's just a fad. There have been far more failed IO paradigms than watersheds... I mean, I like it too, but the point upthread is that you can't just suck in every nice-looking idea or you'll end up like C++.
    - qaq 8y ago
      How is adding async await will make Rust into C++ ? Would people actually name the features that should not be in? Outside of ownership and borrowing have Rust added any features that are not mainstream and well proven in other languages?
      - ajross 8y ago
        How did adding exceptions to the language make C++ into C++? RTTI? Multiple virtual inheritance? Default member function generation? They didn't, not individually. They were popular and uncontroversial (rather less controversial than promise apis, even). And yet... The point is that Rust seems to be charging blindly down the same road, not that any one feature is going to blow it all up. Frankly IMHO Rust is already harder to learn for a median programmer than C++ is, even if it makes more aesthetic sense to an expert.
        qaq 8y ago
        I think there is fairly large difference between learning and being able to write production ready code. It's hard to imagine a person for whom Rust is hard to learn and who can write safe threaded code in C++ for example.
        ajross 8y ago
        Hundreds of thousands of engineers are writing "production ready" C++ code every day. Your point seems trivially falsifiable, unless you want to turn it into a no-true-scotsman situation and explain how what they're "really" writing isn't "C++" or whatever. I'm not saying Rust is bad. I'm saying it's... becoming senselessly complicated. And that in 20 years when 60% of its amazing new features turn out to be just fashion (because they happens to everything), Rust will be "ugly" then in basically the same way that C++ is now, and we'll all be chasing some other new hotness.
        qaq 8y ago
        1) You omitted threaded 2) I seriously doubt you or I have good stats on how many people who are writing production ready C++ would consider Rust hard.
- burfog 8y ago
  Async/await appears to require runtime support, possibly even a modern OS. Wasn't rust supposed to be suitable for writing bare-metal code? SIMD at least has hope of running on bare metal. I suppose the ideal is to have it adjustable: compiled to non-SIMD, using typical SIMD hardware, using implicit threads (and thus needing OS support), or using SIMD hardware with threads. I fear the high-level web developers are in the driver's seat, which may doom rust as a systems language. I'm hesitating on rust because I would miss bitfields and various unsafe performance features. I like the opt-out safety of the "unsafe" keyword, but I want more things that I can opt out of. I want goto, computed goto, no-default switches, something like Microsoft's __assume keyword, and all the other low-level stuff you'd want for making boot loaders and high-performance kernels.
  - kam 8y ago
    > Async/await appears to require runtime support, possibly even a modern OS. Wasn't rust supposed to be suitable for writing bare-metal code? You're probably thinking of Tokio, the library for async network IO, which obviously depends on an OS. The async/await language feature compiles down to basically a state machine and has minimal runtime requirements. I'm looking forward to using it on bare-metal microcontrollers.
  - steveklabnik 8y ago
    async/await in Rust produces a single value, a Future. Executing that future requires calling its poll method repeatedly. That can be extremely simple, or it can be more complex. We call "a thing that calls poll repeatedly" an executor, and they can be written without an OS or even the standard library, just fine. The largest, most well known executor is Tokio, which is built on top of OS primitives. If you're writing your own OS, you'd use those primitives. > I fear the high-level web developers are in the driver's seat First, I pretty fundamentally reject this as an idea, but since you don't, please do a Google Scholar search for many of the core team members. They're very much not web developers.