Even Apple Is Interested In Migrating Their C Code To Rust

[kpedersen]

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

[Kemosabe]

Tiny ecosystem? It has a very large and diverse open source ecosystem.

It is not good enough. Are you trying to make the claim that you don't need anything else beside some fun looking Rust packages - disregarding and reinventing others' work?

[wagaf]

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

Even expert C/C++ developers make mistakes sometimes.
And language-level protections allow to free up brain time to focus on the actual business logic.

Rust offers more guarantees than most interpreted languages (including revolutionary thread-safety guarantees), while offering close-to-C performances.

[Kemosabe]

Rust offers more guarantees than most interpreted languages (including revolutionary thread-safety guarantees), while offering close-to-C performances.

Yes, that's one of the famous Rust slogans thanks to the aggressive marketing. What it guarantees is no data races. Nothing more. Surely a useful thing but I would not call that "revolutionary". Not sure how interpreted languages guarantee things? Most of them are not even type safe... Nm.

[bug77]

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.

sed s/C/asm/g

[Vistaus]

And here I thought Apple was putting all their money on Swift, which they created...

[chocolate]

Believing that C is "good enough" and that experienced coders are less likely to make mistakes, thus letting C continue to exist merely by inertia, is delusional.

Yes, there are standards, plural. Different standards exist for different sectors as if less critical ones shouldn't have a choice and just cope with potential failures and monetary loss. Those standards are helped more often than not by proprietary tools, and are ultimately enforced to varying degrees... by humans.

At the root of all this are C's deficiencies and demerits. We all grow up being told that "math doesn't care what you think" and that "math is not an opinion", yet as adults and as engineers we refuse to build mathematical proofs inside the language, and spend our lives chasing windmills: incomplete proofs built around code, with even more code, perhaps in a different, functional language, more burden, more absurdity.

I like to call all this, quite simply, negligence.

Maybe Rust is not the savior it is said to be, but a language that avoids common C (et similia) traps and pitfalls is sorely needed, and stating otherwise after decades of proof will eventually be considered criminal.

[r08z]

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.

You're just a bad programmer and shouldn't code in C to begin with.

[ssokolow]

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?

GTK+ bindings are a poor example because they're a special case.

Because Glib implements its own higher-level object system and IDL, pointing to them is like pointing to the existence of something like rust-cpython, Helix, or Neon as an example of why bindgen is insufficient.

A general-purpose C binding tool cannot magically infer the semantics of a higher-level language's API that's implemented in C.

[ssokolow]

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.

Poking at the site more after having slept, I just realized what the selection criterion was for that updated but shorter list:

Updated functional languages results + Julia added