3 ms·

>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

by 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.
- S_I 10y ago
  >The idea is, it's better to develop a great language first and focus on other priorities later[...] Agreed, but when is Rust done? 1.0, 2.0, 3.0? Why does the Rust community talk more about adding optional garbage collection than IEEE standardization and alternative implementations (for example for gcc)? You see, there's always this "one more feature" before it is a "great language". If you want to sell it as a C alternative/replacement and keep going this way, it will be neither a technical nor a spiritual successor.
  - Manishearth 10y ago
    > Why does the Rust community talk more about adding optional garbage collection What? There is only one person talking about that, and that's me, and that's pretty low priority right now. There are three people total who are working on it (I worked on the higher level design, and felix/niko/I will implement bits of it at some point) and I don't think any one of us is currently doing anything here. OTOH there is a whole group of people actively working on standardizing how unsafe code is supposed to behave. There are pushes for standardization elsewhere too, though unsafe code is the more pressing one since that's where actual UB can happen and that's where you need a standard the most. There's a group working on formal verification as well (which could produce a standard as a byproduct). Not sure if there are plans for making it an IEEE standard, but a standard it will be. Standardization is a topic that crops up pretty regularly in discussions. Optional GC is not. The type system is still in flux with specialization and a bunch of other type system changes on the horizon. These don't affect language stability, but they do affect how the standard would look since they may completely change how you describe the type system. Starting work on a complete standard right now doesn't make sense with these bits missing. Edit: it's also not "optional garbage collection", really, it's just hooks so that it's easy to write your own GC, or, more importantly, integrate with another one. Rust is getting a lot of attention from folks wanting to speed up portions of their Python/Ruby/whatever codebase, so having these is important.
Ar-Curunir 10y ago
I'm pretty sure C did not have a plethora of compilers six years after birth. Even if it did, they were probably wildly inconsistent.
- kibwen 10y ago
  They were absolutely inconsistent. It wasn't until 17 years after its inception that a C standard was agreed upon.

by S_I 10y ago

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.

S_I 10y ago
>The idea is, it's better to develop a great language first and focus on other priorities later[...] Agreed, but when is Rust done? 1.0, 2.0, 3.0? Why does the Rust community talk more about adding optional garbage collection than IEEE standardization and alternative implementations (for example for gcc)? You see, there's always this "one more feature" before it is a "great language". If you want to sell it as a C alternative/replacement and keep going this way, it will be neither a technical nor a spiritual successor.
- Manishearth 10y ago
  > Why does the Rust community talk more about adding optional garbage collection What? There is only one person talking about that, and that's me, and that's pretty low priority right now. There are three people total who are working on it (I worked on the higher level design, and felix/niko/I will implement bits of it at some point) and I don't think any one of us is currently doing anything here. OTOH there is a whole group of people actively working on standardizing how unsafe code is supposed to behave. There are pushes for standardization elsewhere too, though unsafe code is the more pressing one since that's where actual UB can happen and that's where you need a standard the most. There's a group working on formal verification as well (which could produce a standard as a byproduct). Not sure if there are plans for making it an IEEE standard, but a standard it will be. Standardization is a topic that crops up pretty regularly in discussions. Optional GC is not. The type system is still in flux with specialization and a bunch of other type system changes on the horizon. These don't affect language stability, but they do affect how the standard would look since they may completely change how you describe the type system. Starting work on a complete standard right now doesn't make sense with these bits missing. Edit: it's also not "optional garbage collection", really, it's just hooks so that it's easy to write your own GC, or, more importantly, integrate with another one. Rust is getting a lot of attention from folks wanting to speed up portions of their Python/Ruby/whatever codebase, so having these is important.

Ar-Curunir 10y ago

I'm pretty sure C did not have a plethora of compilers six years after birth. Even if it did, they were probably wildly inconsistent.

kibwen 10y ago
They were absolutely inconsistent. It wasn't until 17 years after its inception that a C standard was agreed upon.