5 ms·

As much as the Rust community does right with respect to the technical aspects of the language, as much they still don't (seem) to understand the non technical

by S_I 10y ago

As much as the Rust community does right with respect to the technical aspects of the language, as much they still don't (seem) to understand the non technical problems it has. Do you know which non technical advantage C has? Multiple implementations. Don't like gcc, use clang. The Keil compiler has a certain bug that screws your project? Use IAR. And so on. That is one thing. Another thing (at least at the company i work for and the ones i know) is, companies that write code for infrastructure or machines that need to rung a looong time won't ever trust a language (and toolchain) that comes in versions and not in IEEE standards. That may or not be stupid, but it is the reality i've seen so far. P.S.: Before someone says C only NOW has multiple implementations, yes, at some point in time that was true, but i was VERY easy for compiler vendors to implement a C compiler (speak ROI). Time will tell if this will be true for Rust as well.

Manishearth 10y ago
> companies that write code for infrastructure or machines that need to rung a looong time won't ever trust a language (and toolchain) that comes in versions and not in IEEE standards The Rust team has a very high commitment to stability, and does way more to maintain stability than any other language/compiler I know of (by testing new versions and potentially-breaking-changes against the entire ecosystem) > still don't (seem) to understand the non technical problems it has. Just because multiple implementations of Rust don't exist (there are a couple but nothing 100% feature complete iirc) doesn't mean that the community doesn't understand the need for it. Alternate implementations are hard to write and take time. The language is still new, but work is being done towards speccing it (e.g. the unsafe code semantics work being done right now). Note that most languages have gone for years without getting a proper spec or alternate implementations. This is an advantage C has over Rust, agreed. It's usually not a dealbreaker, though.
- S_I 10y ago
  >The Rust team has a very high commitment to stability, and does way more to maintain stability than any other language/compiler I know of (by testing new versions and potentially-breaking-changes against the entire ecosystem) Yes, but my experience is that they don't seem to manage generating the kind of trust needed to get my peers to give it a serious go. It's a purely social and subjective problem. >Just because multiple implementations of Rust don't exist (there are a couple but nothing 100% feature complete iirc) doesn't mean that the community doesn't understand the need for it. As i said, it SEEMS to be so. That means that it is a subjective impression my colleagues and me get. It is the job of the community to generate trust, not the (potential) user's. >Alternate implementations are hard to write and take time. Yes, see my P.S. Time will tell if it's worth it to compiler vendors. C made it easy for them right from the start. >Note that most languages have gone for years without getting a proper spec or alternate implementations. This is an advantage C has over Rust, agreed. It's usually not a dealbreaker, though. Not a dealbreaker for whom? In the infrastructure and big machine business you will see C, some C++ and Ada. All standardized. If the Rust community wants to offer an alternative for C, C++ and Ada, AND want Rust to succeed as an alternative, they need to understand that trust (in the toolchain) is generated in different ways in different industries.
  - Manishearth 10y ago
    > Not a dealbreaker for whom? In the infrastructure and big machine business you will see C, some C++ and Ada. All standardized. Sure, there will be some cases where you absolutely need a standardized language. And Rust won't work there for a while at least. But that's a far cry from the picture painted in the original post.
    - S_I 10y ago
      >And Rust won't work there for a while at least. Yes, and that is why those industries will choose to ignore it for a while at least. Chicken and egg.
      - Manishearth 10y ago
        It's not a chicken and egg. Like I said, the Rust team does want to make this happen (and is already doing so from the specification side, though I suspect multiple implementations will come from elsewhere since we already have a couple partial ones). Rust already has lots of folks from other industries trying to use it -- there's plenty of momentum for it to get there. It will take time, but it's not like Rust will never get there without support from the industries you mention (which would be a chicken and egg problem)
        S_I 10y ago
        Until this happens i will remain skeptical if the Rust community can pull it off without the backing of said industries. On the other i like being proven wrong. Time will tell. > though I suspect multiple implementations will come from elsewhere since we already have a couple partial ones) >Rust already has lots of folks from other industries trying to use it I'm not up to date. Input would be appreciated here.
        Manishearth 10y ago
        As for alternate implementations, https://github.com/thepowersgang/mrustc https://github.com/thepowersgang/mrustc . As for specification, https://github.com/rust-lang/rfcs/pull/1643 https://github.com/rust-lang/rfcs/pull/1643 is what's currently happening, i.e. specifying exactly how unsafe code behaves (this is more important than specifying the rest). But the rest will come. As for the industry, https://www.rust-lang.org/friends.html https://www.rust-lang.org/friends.html
- banachtarski 10y ago
  > The Rust team has a very high commitment to stability, and does way more to maintain stability than any other language/compiler I know of (by testing new versions and potentially-breaking-changes against the entire ecosystem) I'm all for this but I really don't see how Rust's stability can hold a candle to the international standards committees that govern C and C++ (not to mention the investment from the big tech companies in developing and implementing these standards)
  - Manishearth 10y ago
    > I'm all for this but I really don't see how Rust's stability can hold a candle to the international standards committees that govern C and C++ (not to mention the investment from the big tech companies in developing and implementing these standards) That's an orthogonal issue; that's adoption. More adoption means more stability, regardless of whether or not the thing has a standards committee. Of course Rust can't hold a candle to the level of adoption C has.
  - TheCoelacanth 10y ago
    Rust is far more stable than C was six years into it's life. It hasn't caught up with C yet, but C had a 38 year head-start.
kibwen 10y ago
> as much they still don't (seem) to understand the non > technical problems it has. What makes you think that? The Rust developers have had their eye on a written specification and a path to standardization for a while now. And I've seen nobody arguing that alternate implementations are undesirable, only that that's hardly a priority at the moment, especially in this day and age (the "you need multiple compilers" argument was more veracious before compilers were all FOSS and all grew retargetable backends, today multiple implementations are useful mainly to rule out reflections-on-trusting-trust attacks).
- S_I 10y ago
  >And I've seen nobody arguing that alternate implementations are undesirable, only that that's hardly a priority at the moment, especially in this day and age Yes, for most developers this is true, but not all (see post above). Try looking at it from my perspective. If i suggest to my peers to give Rust a (serious) try and evaluate it for use in a project, this "hardly a priority" generates the impression of "we don't care right now, maybe someday". So they say "fine, i will give it a try in x years, when multiple implementations are available. It the meantime we will wait and C.". So basically, chicken and egg. Again, the Rust community needs to understand what kind of impressions they generate vs. which impressions they want to they generate. Update: Just to make that clear, i have to look at it from the perspective of an industry that produces infrastructure and complex, big machines. Update 2: Fixed typo.
  - AsyncAwait 10y ago
    > Try looking at it from my perspective. If i suggest to my peers to give Rust a (serious) try and evaluate it for use in a project, this "hardly a priority" generates the impression of "we don't care right now Interesting, but if you try to see the perspective of the Rust developers, they're a relatively small group trying to first develop the strongest language possible, after which other implementations will rise in priority. The idea is, it's better to develop a great language first and focus on other priorities later, rather than having a mediocre language with many implementations. Nonetheless, they're taking the necessary steps.
johncolanduoni 10y ago
Multiple implementations combined with loads of undefined behavior is a pretty big disadvantage for C as well.
- S_I 10y ago
  Yes, but if a compiler screws my project because of a bug, and the company (maintainer) can't/won't fix it for reason x, i at least have a chance rescuing the project by switching compilers.

by S_I 10y ago

Manishearth 10y ago

> companies that write code for infrastructure or machines that need to rung a looong time won't ever trust a language (and toolchain) that comes in versions and not in IEEE standards The Rust team has a very high commitment to stability, and does way more to maintain stability than any other language/compiler I know of (by testing new versions and potentially-breaking-changes against the entire ecosystem) > still don't (seem) to understand the non technical problems it has. Just because multiple implementations of Rust don't exist (there are a couple but nothing 100% feature complete iirc) doesn't mean that the community doesn't understand the need for it. Alternate implementations are hard to write and take time. The language is still new, but work is being done towards speccing it (e.g. the unsafe code semantics work being done right now). Note that most languages have gone for years without getting a proper spec or alternate implementations. This is an advantage C has over Rust, agreed. It's usually not a dealbreaker, though.

S_I 10y ago
>The Rust team has a very high commitment to stability, and does way more to maintain stability than any other language/compiler I know of (by testing new versions and potentially-breaking-changes against the entire ecosystem) Yes, but my experience is that they don't seem to manage generating the kind of trust needed to get my peers to give it a serious go. It's a purely social and subjective problem. >Just because multiple implementations of Rust don't exist (there are a couple but nothing 100% feature complete iirc) doesn't mean that the community doesn't understand the need for it. As i said, it SEEMS to be so. That means that it is a subjective impression my colleagues and me get. It is the job of the community to generate trust, not the (potential) user's. >Alternate implementations are hard to write and take time. Yes, see my P.S. Time will tell if it's worth it to compiler vendors. C made it easy for them right from the start. >Note that most languages have gone for years without getting a proper spec or alternate implementations. This is an advantage C has over Rust, agreed. It's usually not a dealbreaker, though. Not a dealbreaker for whom? In the infrastructure and big machine business you will see C, some C++ and Ada. All standardized. If the Rust community wants to offer an alternative for C, C++ and Ada, AND want Rust to succeed as an alternative, they need to understand that trust (in the toolchain) is generated in different ways in different industries.
- Manishearth 10y ago
  > Not a dealbreaker for whom? In the infrastructure and big machine business you will see C, some C++ and Ada. All standardized. Sure, there will be some cases where you absolutely need a standardized language. And Rust won't work there for a while at least. But that's a far cry from the picture painted in the original post.
  - S_I 10y ago
    >And Rust won't work there for a while at least. Yes, and that is why those industries will choose to ignore it for a while at least. Chicken and egg.
    - Manishearth 10y ago
      It's not a chicken and egg. Like I said, the Rust team does want to make this happen (and is already doing so from the specification side, though I suspect multiple implementations will come from elsewhere since we already have a couple partial ones). Rust already has lots of folks from other industries trying to use it -- there's plenty of momentum for it to get there. It will take time, but it's not like Rust will never get there without support from the industries you mention (which would be a chicken and egg problem)
      - S_I 10y ago
        Until this happens i will remain skeptical if the Rust community can pull it off without the backing of said industries. On the other i like being proven wrong. Time will tell. > though I suspect multiple implementations will come from elsewhere since we already have a couple partial ones) >Rust already has lots of folks from other industries trying to use it I'm not up to date. Input would be appreciated here.
        Manishearth 10y ago
        As for alternate implementations, https://github.com/thepowersgang/mrustc https://github.com/thepowersgang/mrustc . As for specification, https://github.com/rust-lang/rfcs/pull/1643 https://github.com/rust-lang/rfcs/pull/1643 is what's currently happening, i.e. specifying exactly how unsafe code behaves (this is more important than specifying the rest). But the rest will come. As for the industry, https://www.rust-lang.org/friends.html https://www.rust-lang.org/friends.html
banachtarski 10y ago
> The Rust team has a very high commitment to stability, and does way more to maintain stability than any other language/compiler I know of (by testing new versions and potentially-breaking-changes against the entire ecosystem) I'm all for this but I really don't see how Rust's stability can hold a candle to the international standards committees that govern C and C++ (not to mention the investment from the big tech companies in developing and implementing these standards)
- Manishearth 10y ago
  > I'm all for this but I really don't see how Rust's stability can hold a candle to the international standards committees that govern C and C++ (not to mention the investment from the big tech companies in developing and implementing these standards) That's an orthogonal issue; that's adoption. More adoption means more stability, regardless of whether or not the thing has a standards committee. Of course Rust can't hold a candle to the level of adoption C has.
- TheCoelacanth 10y ago
  Rust is far more stable than C was six years into it's life. It hasn't caught up with C yet, but C had a 38 year head-start.

kibwen 10y ago

> as much they still don't (seem) to understand the non > technical problems it has. What makes you think that? The Rust developers have had their eye on a written specification and a path to standardization for a while now. And I've seen nobody arguing that alternate implementations are undesirable, only that that's hardly a priority at the moment, especially in this day and age (the "you need multiple compilers" argument was more veracious before compilers were all FOSS and all grew retargetable backends, today multiple implementations are useful mainly to rule out reflections-on-trusting-trust attacks).

S_I 10y ago
>And I've seen nobody arguing that alternate implementations are undesirable, only that that's hardly a priority at the moment, especially in this day and age Yes, for most developers this is true, but not all (see post above). Try looking at it from my perspective. If i suggest to my peers to give Rust a (serious) try and evaluate it for use in a project, this "hardly a priority" generates the impression of "we don't care right now, maybe someday". So they say "fine, i will give it a try in x years, when multiple implementations are available. It the meantime we will wait and C.". So basically, chicken and egg. Again, the Rust community needs to understand what kind of impressions they generate vs. which impressions they want to they generate. Update: Just to make that clear, i have to look at it from the perspective of an industry that produces infrastructure and complex, big machines. Update 2: Fixed typo.
- AsyncAwait 10y ago
  > Try looking at it from my perspective. If i suggest to my peers to give Rust a (serious) try and evaluate it for use in a project, this "hardly a priority" generates the impression of "we don't care right now Interesting, but if you try to see the perspective of the Rust developers, they're a relatively small group trying to first develop the strongest language possible, after which other implementations will rise in priority. The idea is, it's better to develop a great language first and focus on other priorities later, rather than having a mediocre language with many implementations. Nonetheless, they're taking the necessary steps.

johncolanduoni 10y ago

Multiple implementations combined with loads of undefined behavior is a pretty big disadvantage for C as well.

S_I 10y ago
Yes, but if a compiler screws my project because of a bug, and the company (maintainer) can't/won't fix it for reason x, i at least have a chance rescuing the project by switching compilers.