5 ms·

Yes, it's far too early to tell. The good thing to take away is that, at the moment, the answer to "is Rust a viable threat to C/C++?" does not seem to be a cat

by DCKing 12y ago

Yes, it's far too early to tell. The good thing to take away is that, at the moment, the answer to "is Rust a viable threat to C/C++?" does not seem to be a categorical no. The same cannot be said for other languages in the area, such as Pascal, D, Ada, Nimrod and even Go, although all of these languages have their use. Any adoption of Rust in areas where people otherwise use C/C++ is an improvement I think. It doesn't have to be total displacement, and that will never happen.

pjmlp 12y ago
Any systems programming language can displace C. You just need a successful OS vendor pushing the said language as only means to target their OS.
- DCKing 12y ago
  I think the reason many people are rooting for Rust is because it's got comprehensively better features than competing languages. I'm not talking just about memory safety, but also its adoption of functional language features. I'm of the opinion that immutability-by-default, pattern matching, first-class functions and real macros combined with no garbage collection are a Very Good Thing™ for this type of language (and I'm not the only one). So yeah, I disagree that any systems programming language can displace C. Other system languages simply don't come with the same amount of improvements that Rust offers.
  - pjmlp 12y ago
    > So yeah, I disagree that any systems programming language can displace C. Other system languages simply don't come with the same amount of improvements that Rust offers. So, given my premise, how do you target super-cool-everyone-wants-it-os that only offers new-cool-language as their system programming language in the OS SDK? Are you going to write a C compiler in new-cool-language to be able to keep on using C?
    - dllthomas 12y ago
      Why not cross compile?
      - pjmlp 12y ago
        You could as well. In case case the C runtime has to be implemented on top of the new-cool-language ABI, as it is the only way the vendor supports creating software for their system. What I am describing is not that different from thirty years ago when C was a UNIX only language, and other OS had other languages as their systems programming language.
    - MaulingMonkey 12y ago
      > super-cool-everyone-wants-it-os that only offers new-cool-language I'd suggest that these are fundamentally incompatible statements. "Only offers new-cool-language" is another way of saying "it's a pain in the ass to port to - you have to rewrite your whole app!" if you're coming from anywhere that's ever touched not-quite-as-cool-language.
fithisux 12y ago
D is a viable alternative to C++, period, not necessarily to C. I believe a rewrite of Xorg in D would be googd. The only problem with all these languages is that you cannot e.g. create a dll in Ada and generate appropriate headers to use it in C, even more in Go. In this respect I feel that this is the real problem here. The biggest obstacle is the C++ legacy code.
- DCKing 12y ago
  D is absolutely a viable alternative to C++ and probably C. There's no argument there. D is not a viable threat to C/C++ (this is what I said!), as noone is really thinking that D will actively displace the use of C/C++ in many projects in the future. The same goes for all the other languages I mention. In my perception there's a buzz around Rust that indicates it might be viewed differently.
- kvark 12y ago
  Can you use D without GC? How would it look like? If very restricted, then I don't see it as a viable C++ alternative. I'm ok with GC on a web server, but coreutils are better without it.
  - Shorel 12y ago
    It is possible to allocate objects in the stack (objects without polymorphism, defined with the struct keyword). No use of heap and GC in that case at all. It's not that different to using C++ objects in the stack. If by no GC you mean to use heap allocated objects with manually managed destructors, then I think the answer is no.
    - kvark 12y ago
      I'm looking at "http://dlang.org/garbage.html" http://dlang.org/garbage.html" section "D Operations That Involve the Garbage Collector", and there are some pretty interesting things on the list that require GC: all dynamic arrays, associative arrays, closures, asserts. Can you even read a file without these?

by DCKing 12y ago

pjmlp 12y ago

Any systems programming language can displace C. You just need a successful OS vendor pushing the said language as only means to target their OS.

DCKing 12y ago
I think the reason many people are rooting for Rust is because it's got comprehensively better features than competing languages. I'm not talking just about memory safety, but also its adoption of functional language features. I'm of the opinion that immutability-by-default, pattern matching, first-class functions and real macros combined with no garbage collection are a Very Good Thing™ for this type of language (and I'm not the only one). So yeah, I disagree that any systems programming language can displace C. Other system languages simply don't come with the same amount of improvements that Rust offers.
- pjmlp 12y ago
  > So yeah, I disagree that any systems programming language can displace C. Other system languages simply don't come with the same amount of improvements that Rust offers. So, given my premise, how do you target super-cool-everyone-wants-it-os that only offers new-cool-language as their system programming language in the OS SDK? Are you going to write a C compiler in new-cool-language to be able to keep on using C?
  - dllthomas 12y ago
    Why not cross compile?
    - pjmlp 12y ago
      You could as well. In case case the C runtime has to be implemented on top of the new-cool-language ABI, as it is the only way the vendor supports creating software for their system. What I am describing is not that different from thirty years ago when C was a UNIX only language, and other OS had other languages as their systems programming language.
  - MaulingMonkey 12y ago
    > super-cool-everyone-wants-it-os that only offers new-cool-language I'd suggest that these are fundamentally incompatible statements. "Only offers new-cool-language" is another way of saying "it's a pain in the ass to port to - you have to rewrite your whole app!" if you're coming from anywhere that's ever touched not-quite-as-cool-language.

fithisux 12y ago

D is a viable alternative to C++, period, not necessarily to C. I believe a rewrite of Xorg in D would be googd. The only problem with all these languages is that you cannot e.g. create a dll in Ada and generate appropriate headers to use it in C, even more in Go. In this respect I feel that this is the real problem here. The biggest obstacle is the C++ legacy code.

DCKing 12y ago
D is absolutely a viable alternative to C++ and probably C. There's no argument there. D is not a viable threat to C/C++ (this is what I said!), as noone is really thinking that D will actively displace the use of C/C++ in many projects in the future. The same goes for all the other languages I mention. In my perception there's a buzz around Rust that indicates it might be viewed differently.
kvark 12y ago
Can you use D without GC? How would it look like? If very restricted, then I don't see it as a viable C++ alternative. I'm ok with GC on a web server, but coreutils are better without it.
- Shorel 12y ago
  It is possible to allocate objects in the stack (objects without polymorphism, defined with the struct keyword). No use of heap and GC in that case at all. It's not that different to using C++ objects in the stack. If by no GC you mean to use heap allocated objects with manually managed destructors, then I think the answer is no.
  - kvark 12y ago
    I'm looking at "http://dlang.org/garbage.html" http://dlang.org/garbage.html" section "D Operations That Involve the Garbage Collector", and there are some pretty interesting things on the list that require GC: all dynamic arrays, associative arrays, closures, asserts. Can you even read a file without these?