Announcement

Collapse
No announcement yet.

Even Apple Is Interested In Migrating Their C Code To Rust

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • kpedersen
    replied
    Originally posted by Candy View Post

    Maybe the company should hire a more skilled programmer ?
    Haha, yep, C certainly has its flaws (like all programming languages) but those who are paid to develop in it generally don't make these kinds of mistakes. If they did, most languages would be unusable because their VMs (CLR, JVM) are obviously written in C.

    bachchain, If I was a software engineer working on mission-critical infrastructure for a trillion dollar company, and my team were a bunch of idiots; then yes; you are absolutely correct, I refuse to work on a C project where the rest of the developers are incompetent.

    So oddly enough I agree with both of you

    Leave a comment:


  • mmstick
    replied
    Originally posted by Kemosabe View Post

    Even though I get the gist of what you're trying to convey - without arguing about the high potential of that being a self-inflicted situation - I gave up on Rust.
    Rust does not seem to be very friendly towards other languages, let's pick example X. Bindings for X to Rust or Rust to X are most likely not present at all, in premature stages or too impractical due to Rust's quirks. I can't afford living in my tiny little ecosystem of Rust.
    Tiny ecosystem? It has a very large and diverse open source ecosystem.

    Leave a comment:


  • Kemosabe
    replied
    Originally posted by bachchain View Post

    If I was a software engineer working on mission-critical infrastructure for a trillion dollar company, I would happily give up a few cycles or kilobytes if it meant I didn't have to spend hundreds of man-hours debugging one-in-ten-thousand race conditions or that segfault that only happens on the second Tuesday of each month.
    Even though I get the gist of what you're trying to convey - without arguing about the high potential of that being a self-inflicted situation - I gave up on Rust.
    Rust does not seem to be very friendly towards other languages, let's pick example X. Bindings for X to Rust or Rust to X are most likely not present at all, in premature stages or too impractical due to Rust's quirks. I can't afford living in my tiny little ecosystem of Rust.

    Leave a comment:


  • Candy
    replied
    Originally posted by bachchain View Post
    I would happily give up a few cycles or kilobytes if it meant I didn't have to spend hundreds of man-hours debugging one-in-ten-thousand race conditions or that segfault that only happens on the second Tuesday of each month.
    Maybe the company should hire a more skilled programmer ?

    Leave a comment:


  • bachchain
    replied
    Originally posted by r08z View Post
    There hasn't been a programming language that has beaten C in speed and energy usage yet. Rust is impressive and is the closest thing out right now. But it's not C.
    If I was a software engineer working on mission-critical infrastructure for a trillion dollar company, I would happily give up a few cycles or kilobytes if it meant I didn't have to spend hundreds of man-hours debugging one-in-ten-thousand race conditions or that segfault that only happens on the second Tuesday of each month.

    Leave a comment:


  • jaypatelani
    replied
    I hoped they choose ada language

    Leave a comment:


  • c117152
    replied
    Originally posted by kpedersen View Post
    C++ and Objective-C are the closest because they are C (mostly); and they extend it. Then I just need to write thin safety (RAII) wrappers.
    C++ and Objective-C (as well as other languages mentioned above) don't "syntactically encapsulate" (as it were) nasal demons like Rust. That is, in modern languages, regardless of the feature-set, the core requirement is that the stuff you're reading is what you're going to get unless it's explicitly defined as unsafe, the hardware is buggy and/or you're consuming external code.

    And it's not a surprise Apple is interested in Rust now that they're porting large chunks of code from x86 to ARM and might need to do it again for RISC-V sometime in the future. Now if they keep up with the porting effort after the initial release and actually finish it... Now that will be surprising.

    Leave a comment:


  • Tomin
    replied
    Originally posted by ssokolow View Post
    It's Table 4 from this 2017 research paper: https://greenlab.di.uminho.pt/wp-con...0/sleFinal.pdf
    Nice. Thanks!

    Originally posted by ssokolow View Post
    Sadly, given how much work has gone into the Rust compiler in the ~2.5 years since then, it's questionable how accurate it still is for such a small margin, and the 2020 revision of the tables at https://sites.google.com/view/energy...l-results-2020 only has about half the number of programming languages, of which C and C++ are not included.
    Yeah, Rust has improved a lot on all frontiers. It's not just the compiler, the language itself and the standard library have improved much as well. Although many of the improvements are such that make it a bit easier to write programs, and not necessarily directly related to making it faster. Indirectly that can help by pointing the developers to use the language better though. In these comparisons I always wonder if the program was really implemented the optimal way or the most idiomatic way given the language so that the result can be considered as fair for all the languages compared. If you don't know your tools well it's not that difficult to make small mistakes that cause the implementation to consume extra memory or spend extra time compared to a slightly different solution. I suspect that the Rust versions were pretty optimized though since the difference to C was so tiny.

    A bit odd choice to drop C and C++ out of such comparison. I would think that must have been due to limited resources. They didn't have time to update the codes for them or something. I hope that they will include them if they make another paper on the subject.
    Last edited by Tomin; 03-21-2020, 08:56 AM.

    Leave a comment:


  • kpedersen
    replied
    Originally posted by ssokolow View Post

    bindgen isn't automatic enough for you?
    Unfortunately not. Same with swig and other "binding generators". C code as you know gets more complex than that. These solutions do not handle callbacks well or memory that is retained by the library (light user data). Chuck in some MACROs, setjmp and other fairly common things and they don't stand a chance.

    Just look at the Rust Gtk bindings. Would they have done all this work if a simple call to bindgen would have a chance of generating something useful?
    Last edited by kpedersen; 03-21-2020, 08:33 AM.

    Leave a comment:


  • ssokolow
    replied
    Originally posted by Tomin View Post

    Well, that's really close. What is Mb column? Program size? Also what is the source for that image? I'd like to take a better look how that comparison was made.
    It's Table 4 from this 2017 research paper: https://greenlab.di.uminho.pt/wp-con...0/sleFinal.pdf

    Sadly, given how much work has gone into the Rust compiler in the ~2.5 years since then, it's questionable how accurate it still is for such a small margin, and the 2020 revision of the tables at https://sites.google.com/view/energy...l-results-2020 only has about half the number of programming languages, of which C and C++ are not included.
    Last edited by ssokolow; 03-21-2020, 08:12 AM.

    Leave a comment:

Working...
X