3 ms·

" There's nothing in Rust that rises to the category of "stuff everyone just uses because it's what everyone uses" (c.f. zlib, libjpeg, readline...) yet." IMHO

by jerf 7y ago

" There's nothing in Rust that rises to the category of "stuff everyone just uses because it's what everyone uses" (c.f. zlib, libjpeg, readline...) yet." IMHO, that's basically not possible, so it isn't a fair ask. If the Rust community produced a drop-in replacement that is every bit as good as readline in literally every way... still nobody would switch, because why would they? What's the benefit? You spend all this effort just to trade evenly across. If the Rust community produces something better, nobody's going to use whatever those extra features are outside of Rust itself. This is the category of software that will be last. The question for Rust, and equally, every other ambitious language, isn't really "What percentage of existing code will be rewritten in this new language?" (And by "rewritten", I don't just mean "reimplemented but only your community uses it, but in the sense you mean... it actually replaces the original.) If your answer is any number significantly over zero, that itself represents entrance into the absolute top tier of languages... this is very rare. The question for Rust et al is "What percentage of future code will be written in your language?" On that front, Rust is still on a pretty decent trajectory.

ajross 7y ago
> IMHO, that's basically not possible, so it isn't a fair ask Is it not? There is software in that category written in the last ten years (not as much as in the preceding decade, obviously). How about Docker? V8/node? Most of the wasm ecosystem dates from that period. Actually there was a huge window with TLS implementations once the community collectively decided to move away from openssl, too. Rust didn't hit any of those sweet spots. And I think we should maybe be spending more time asking why.
- jacquesm 7y ago
  At a guess because it is much easier to yell from the sidelines than to be exposed with your stuff out in production across major installations. Maturity of code is measured in blood, bugs and overtime, regardless of what language it is written in.
- jerf 7y ago
  "How about Docker? V8/node? Most of the wasm ecosystem dates from that period." Not a replacement of any previous tech, not a replacement of previous tech, and not a replacement of previous tech respectively. You were suggesting Rust must replace things like "zlib, libjpeg, readline". These are not the same sort of thing. It is "zlib, libjpeg, readline" I was suggesting is far too high a bar to clear to say a language is succeeding; I mean, what other language has replaced them either? It isn't just Rust failing to displace C from those places, it's all the languages. I don't even know what it would take for a language to actively replace C in those positions. What could a language possibly offer to overcome the cost of throwing all that code away? "Actually there was a huge window with TLS implementations once the community collectively decided to move away from openssl, too." This is closer to valid, but still a huge ask. Rust may not have done it but neither did anybody else; SSL is still C. Now you've shifted the question from "Why doesn't Rust successfully replace existing tech?", which is what I was saying is effectively impossible, to the question "Why doesn't Rust have a killer app?". This is a fine question to ask; I don't attack you for asking it. I'm merely defending my original characterization. Still, I suspect Rust is like Go; while there is definitely a significant set of apps now that are implemented in Go that people use because they are the best-of-breed and not because they are Go, I expect that usage is dwarfed by usage of Go that you never see. I see Rust coming up around me in places where it's just happening organically, unrelated to HN.
  - unilynx 7y ago
    > You were suggesting Rust must replace things like "zlib, libjpeg, readline". These are not the same sort of thing. They're all parsers of foreign input. Somethings which C is extremely fast at, but also extremely dangerous at doing. > I mean, what other language has replaced them either? It isn't just Rust failing to displace C from those places, it's all the languages. But did other languages have the same ambitions ? As I understood, Rust wanted to be safer but just as fast as C. Which would make it an ideal language to replace those input parsers. It's a pity that still hasn't happened because we'll still be seeing plenty of CVEs for those libs..

by jerf 7y ago

ajross 7y ago

> IMHO, that's basically not possible, so it isn't a fair ask Is it not? There is software in that category written in the last ten years (not as much as in the preceding decade, obviously). How about Docker? V8/node? Most of the wasm ecosystem dates from that period. Actually there was a huge window with TLS implementations once the community collectively decided to move away from openssl, too. Rust didn't hit any of those sweet spots. And I think we should maybe be spending more time asking why.

jacquesm 7y ago
At a guess because it is much easier to yell from the sidelines than to be exposed with your stuff out in production across major installations. Maturity of code is measured in blood, bugs and overtime, regardless of what language it is written in.
jerf 7y ago
"How about Docker? V8/node? Most of the wasm ecosystem dates from that period." Not a replacement of any previous tech, not a replacement of previous tech, and not a replacement of previous tech respectively. You were suggesting Rust must replace things like "zlib, libjpeg, readline". These are not the same sort of thing. It is "zlib, libjpeg, readline" I was suggesting is far too high a bar to clear to say a language is succeeding; I mean, what other language has replaced them either? It isn't just Rust failing to displace C from those places, it's all the languages. I don't even know what it would take for a language to actively replace C in those positions. What could a language possibly offer to overcome the cost of throwing all that code away? "Actually there was a huge window with TLS implementations once the community collectively decided to move away from openssl, too." This is closer to valid, but still a huge ask. Rust may not have done it but neither did anybody else; SSL is still C. Now you've shifted the question from "Why doesn't Rust successfully replace existing tech?", which is what I was saying is effectively impossible, to the question "Why doesn't Rust have a killer app?". This is a fine question to ask; I don't attack you for asking it. I'm merely defending my original characterization. Still, I suspect Rust is like Go; while there is definitely a significant set of apps now that are implemented in Go that people use because they are the best-of-breed and not because they are Go, I expect that usage is dwarfed by usage of Go that you never see. I see Rust coming up around me in places where it's just happening organically, unrelated to HN.
- unilynx 7y ago
  > You were suggesting Rust must replace things like "zlib, libjpeg, readline". These are not the same sort of thing. They're all parsers of foreign input. Somethings which C is extremely fast at, but also extremely dangerous at doing. > I mean, what other language has replaced them either? It isn't just Rust failing to displace C from those places, it's all the languages. But did other languages have the same ambitions ? As I understood, Rust wanted to be safer but just as fast as C. Which would make it an ideal language to replace those input parsers. It's a pity that still hasn't happened because we'll still be seeing plenty of CVEs for those libs..