5 ms·

Rust is also still very far from having eaten any significant chunk of C.

by jcoffland 9y ago

wffurr 9y ago
Do you see any reason why it won't eventually do so?
- runevault 9y ago
  Even if it is objectively better in every way (not saying it is, only going for the most extreme end point for purposes of making a point) it is not guaranteed to replace C. Too many people have invested too much time mastering C and learning to deal with its quirks to simply give it up. There may come a day where basically 0 new C projects are made. I do not think that will be in my lifetime. And I say that as someone with near 0 investment in the language but intends to get more serious about learning rust in the near future.
  - pjmlp 9y ago
    Until we replace UNIX derived OSes and throw away POSIX compatibility that day will never come.
    - mmstick 9y ago
      We've already thrown away POSIX compatibility. Linux isn't POSIX. Mac OS X isn't POSIX. Windows isn't POSIX. POSIX only continues to exist in varying degrees at different times.
- 2trill2spill 9y ago
  I mean it might eventually happen but currently hardware support, vendor support, also all major Unix operating system implementations are written in C and the maintainers don't look like they will change anytime soon. Also C has lot's of inertia behind it.
- maxxxxx 9y ago
  The other question is whether there actually is a reason that it will eventually do so. I personally have my doubts. C has found that perfect sweet spot between not getting in the way of doing things and running on almost any platform. Rust still has to achieve that status and judging from other competitors like C++/D it seems hard to get to that point. Heck, even Java was advertised as systems language on Java CPUs for a while.
  - pjmlp 9y ago
    Well, Java is the systems language on Android that has full exposure to what app developers can actually use. NDK is quite constrained, mostly as a means to implement Java native methods. On Android Things they went one step further and the user space drivers are written in Java. With Treble it is also possible to write drivers in Java thanks to the new micro-kernel like architecture.
  - kbenson 9y ago
    > The other question is whether there actually is a reason that it will eventually do so. I personally have my doubts. C has found that perfect sweet spot between not getting in the way of doing things and running on almost any platform. That is the question. The way I see it, Rust's attractiveness to C developers goes up considerably the more accountable they are for the code they ship. If IoT and embedded devices start having repercussions for out of date, exploitable firmware/services, either through public opinion, legal or legislative means, making a switch to a language that provides more guarantees starts to look a lot more feasible and attractive to a lot of C die-hards.
    - maxxxxx 9y ago
      I think more importantly Rust has to clearly demonstrate that it really is better for projects that use C currently. I think the failure of wider adoption of D is a good case study.
      - kbenson 9y ago
        > I think more importantly Rust has to clearly demonstrate that it really is better for projects that use C currently. I halfway agree. More evidence is always welcome, but the nature of that evidence will almost always be subjective, and I'm not sure a lot of language adherents even care all that much when the evidence is objective. So more is better, but "clearly demonstrate" may be pie in the sky thinking. > I think the failure of wider adoption of D is a good case study. I always considered D interesting, but not worth the effort for the gains it offered. A more ergonomic C/C++ is nice, but ergonomics just steer you the right way, they're a far cry from preventing a while class of errors. A GC does offer some help in that direction, but comes with a clear continuous cost. Compiler level error prevention with zero cost abstractions comes across as something a bit more new and novel, and changes the cost/benefit analysis some. It's now a one-time up-front cost, with the possibility that the cost will lesson over time as you become more accustomed to the language. From an outsider's perspective, Nim was actually a lot more attractive than D as a replacement for C/C++. The cost seems almost negligible since it compiles to C, which makes the benefit fairly good (if overall of less magnitude than I perceive the benefit of Rust to be).
- steveklabnik 9y ago
  It's still too early. There's tons of good reasons to write C code today for many projects. Furthermore, there's so much C code out there that even if nobody wrote a single new line of C today, it'd be decades before it would go away. It's really about growing the pie rather than replacement anyway, in my opinion.
  - carlmr 9y ago
    >even if nobody wrote a single new line of C today, it'd be decades before it would go away. But then we can get sweet sweet COBOL level salaries in 40 years.
  - mmstick 9y ago
    Although, a lot of us are working towards replacement of C in a lot of areas. Being able to say you've written something in Rust is one thing, but having the whole stack Rust all the way down is something else. Not to mention, it's fairly simple to create C bindings from Rust libraries using Cargo workspaces and cbindgen.
vardump 9y ago
I think IoT will push embedded development towards Rust. As well as security critical desktop/server code. Especially when said code needs to be a loadable library (.dylib, .so, .dll). While Rust certainly isn't the silver bullet, it demonstrably significantly reduces memory and concurrency related bugs. Yeah, the last firmware I developed was in C and assembler. No, I could not have done it in Rust, mainly due to no Rust compiler available for the arch. Then again, I could not have done it in pure C either... For future platform selection availability of a Rust compiler is already a factor. Even if we'd still end up using C/C++ for now.
- jcoffland 9y ago
  Since Rust does not yet really work on ARM Cortex or AVR it's still a long way from taking over IoT. Only devices with an OS, like a RaspberryPi, are properly supported by Rust at this point. That's a huge limitation. GCC can target literally hundreds of bare metal devices with C and even C++. Developers have been using C and C++ successfully in IoT devices for years now. Rust may be the bees knees but it has many hurdles to overcome before it dominates a language that has been around for 46 years.
  - tuukkah 9y ago
    Embedded use cases including ARM Cortex-M and AVR support seems to be in the focus on the Rust 2018 roadmap: "We want embedded programming to reach first-class status this year." https://blog.rust-lang.org/2018/03/12/roadmap.html https://blog.rust-lang.org/2018/03/12/roadmap.html
  - deleted 9y ago
    [deleted]
  - vardump 9y ago
    ARM (thumb 2, Cortex M0-M4) is by far the most important target. Second is cores like Cortex A7 and A53. I think AVR is pretty minor outside hobbyist circles. After ARM support, I'd rather first see MSP430 (amazing for low power), some FPGA softcores (like NIOS, microblaze, etc., common in low volume, industrial & medical devices) and even 8051 (these buggers seem to still be everywhere, but I guess targeting Rust for this arch is the ultimate challenge.). I guess RISC-V would be cool as well, I can see this getting more popular in the future, eating ARM market share.

Rust is also still very far from having eaten any significant chunk of C.

wffurr 9y ago

Do you see any reason why it won't eventually do so?

runevault 9y ago
Even if it is objectively better in every way (not saying it is, only going for the most extreme end point for purposes of making a point) it is not guaranteed to replace C. Too many people have invested too much time mastering C and learning to deal with its quirks to simply give it up. There may come a day where basically 0 new C projects are made. I do not think that will be in my lifetime. And I say that as someone with near 0 investment in the language but intends to get more serious about learning rust in the near future.
- pjmlp 9y ago
  Until we replace UNIX derived OSes and throw away POSIX compatibility that day will never come.
  - mmstick 9y ago
    We've already thrown away POSIX compatibility. Linux isn't POSIX. Mac OS X isn't POSIX. Windows isn't POSIX. POSIX only continues to exist in varying degrees at different times.
2trill2spill 9y ago
I mean it might eventually happen but currently hardware support, vendor support, also all major Unix operating system implementations are written in C and the maintainers don't look like they will change anytime soon. Also C has lot's of inertia behind it.
maxxxxx 9y ago
The other question is whether there actually is a reason that it will eventually do so. I personally have my doubts. C has found that perfect sweet spot between not getting in the way of doing things and running on almost any platform. Rust still has to achieve that status and judging from other competitors like C++/D it seems hard to get to that point. Heck, even Java was advertised as systems language on Java CPUs for a while.
- pjmlp 9y ago
  Well, Java is the systems language on Android that has full exposure to what app developers can actually use. NDK is quite constrained, mostly as a means to implement Java native methods. On Android Things they went one step further and the user space drivers are written in Java. With Treble it is also possible to write drivers in Java thanks to the new micro-kernel like architecture.
- kbenson 9y ago
  > The other question is whether there actually is a reason that it will eventually do so. I personally have my doubts. C has found that perfect sweet spot between not getting in the way of doing things and running on almost any platform. That is the question. The way I see it, Rust's attractiveness to C developers goes up considerably the more accountable they are for the code they ship. If IoT and embedded devices start having repercussions for out of date, exploitable firmware/services, either through public opinion, legal or legislative means, making a switch to a language that provides more guarantees starts to look a lot more feasible and attractive to a lot of C die-hards.
  - maxxxxx 9y ago
    I think more importantly Rust has to clearly demonstrate that it really is better for projects that use C currently. I think the failure of wider adoption of D is a good case study.
    - kbenson 9y ago
      > I think more importantly Rust has to clearly demonstrate that it really is better for projects that use C currently. I halfway agree. More evidence is always welcome, but the nature of that evidence will almost always be subjective, and I'm not sure a lot of language adherents even care all that much when the evidence is objective. So more is better, but "clearly demonstrate" may be pie in the sky thinking. > I think the failure of wider adoption of D is a good case study. I always considered D interesting, but not worth the effort for the gains it offered. A more ergonomic C/C++ is nice, but ergonomics just steer you the right way, they're a far cry from preventing a while class of errors. A GC does offer some help in that direction, but comes with a clear continuous cost. Compiler level error prevention with zero cost abstractions comes across as something a bit more new and novel, and changes the cost/benefit analysis some. It's now a one-time up-front cost, with the possibility that the cost will lesson over time as you become more accustomed to the language. From an outsider's perspective, Nim was actually a lot more attractive than D as a replacement for C/C++. The cost seems almost negligible since it compiles to C, which makes the benefit fairly good (if overall of less magnitude than I perceive the benefit of Rust to be).
steveklabnik 9y ago
It's still too early. There's tons of good reasons to write C code today for many projects. Furthermore, there's so much C code out there that even if nobody wrote a single new line of C today, it'd be decades before it would go away. It's really about growing the pie rather than replacement anyway, in my opinion.
- carlmr 9y ago
  >even if nobody wrote a single new line of C today, it'd be decades before it would go away. But then we can get sweet sweet COBOL level salaries in 40 years.
- mmstick 9y ago
  Although, a lot of us are working towards replacement of C in a lot of areas. Being able to say you've written something in Rust is one thing, but having the whole stack Rust all the way down is something else. Not to mention, it's fairly simple to create C bindings from Rust libraries using Cargo workspaces and cbindgen.

vardump 9y ago

I think IoT will push embedded development towards Rust. As well as security critical desktop/server code. Especially when said code needs to be a loadable library (.dylib, .so, .dll). While Rust certainly isn't the silver bullet, it demonstrably significantly reduces memory and concurrency related bugs. Yeah, the last firmware I developed was in C and assembler. No, I could not have done it in Rust, mainly due to no Rust compiler available for the arch. Then again, I could not have done it in pure C either... For future platform selection availability of a Rust compiler is already a factor. Even if we'd still end up using C/C++ for now.

jcoffland 9y ago
Since Rust does not yet really work on ARM Cortex or AVR it's still a long way from taking over IoT. Only devices with an OS, like a RaspberryPi, are properly supported by Rust at this point. That's a huge limitation. GCC can target literally hundreds of bare metal devices with C and even C++. Developers have been using C and C++ successfully in IoT devices for years now. Rust may be the bees knees but it has many hurdles to overcome before it dominates a language that has been around for 46 years.
- tuukkah 9y ago
  Embedded use cases including ARM Cortex-M and AVR support seems to be in the focus on the Rust 2018 roadmap: "We want embedded programming to reach first-class status this year." https://blog.rust-lang.org/2018/03/12/roadmap.html https://blog.rust-lang.org/2018/03/12/roadmap.html
- deleted 9y ago
  [deleted]
- vardump 9y ago
  ARM (thumb 2, Cortex M0-M4) is by far the most important target. Second is cores like Cortex A7 and A53. I think AVR is pretty minor outside hobbyist circles. After ARM support, I'd rather first see MSP430 (amazing for low power), some FPGA softcores (like NIOS, microblaze, etc., common in low volume, industrial & medical devices) and even 8051 (these buggers seem to still be everywhere, but I guess targeting Rust for this arch is the ultimate challenge.). I guess RISC-V would be cool as well, I can see this getting more popular in the future, eating ARM market share.