Even Apple Is Interested In Migrating Their C Code To Rust

[wizard69]

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

Well this is their internet infrastructure team.

Beyond that I'd still take Swift over Rust for the long term play.

[wizard69]

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.

I'm certain many feel this way but the real question is, is Rust the right answer? I just don't know and honestly Rust never had the magnetism for me, that others seem to see in it.

[Luke_Wolf]

Using the term "error free" is naive. However I am confident that disciplined C developers adhering to good standards like MISRA will develop software which has less memory errors than Java or C# when dealing with something like OpenGL or device drivers.

Remember in Java / .NET when accessing hardware, you still have to use raw memory correctly. You also have to "Pin" the GC memory so that it doesn't clear it. You still have to manually free memory that is no longer used and that the GC does not know about.

But of course the typical managed developer will just grab a (probably obsolete) binding and blame someone else when their project turns to mush. Been there done that, I have worked with Unity / C# developers before and they are the worst XD.

C and C++ also have 3rd party garbage collectors asan and Valgrind. Debugging tools for raw memory in Java or .NET are very primitive because that is not a common usecase for these technologies.

I mean... between what Microsoft itself provides and things like dotMemory, C#'s debugging tools for memory are actually pretty good. The fact that .NET's tooling basically blows everything else out of the water in general with static analysis and everything else is half the reason people love C# so much.

[Luke_Wolf]

Well, maybe I'm placing too high value on GC,... I had hated GC in past, and was studying/researching it a bit, and it's not that bad, considering that zero learning is required from developer. And, also found, that GC could outperform reference-counting based memory management (as, reference counting requires atomic operations, and also checks for zeroing reference count,...).

Garbage collection isn't as bad as people make it out to be, yes. Which is why Unreal uses C++ with a garbage collector. However other than long term memory use (GCs will keep more in memory) and latency spikes we can generally consider the difference between various memory management schema to be the same. Performance is much more strongly effected by what things it has to do at run time rather than being able to do at compile time.

Dependency injection doesn't guarantee anything about (de)coupling,... It's just a way how instances are wired together. Also, as it makes that wiring easier, it's actually easier to write more coupled code. Issue of coupling in Java lies in ability to import classes from other packages allowing cyclical dependencies between packages. Even though project might look from package structure as nicely decoupled, the actual logic could be placed anywhere. These classes could be easily heavily inter-coupled. The whole project could be using DI, but actually it would be impossible to swap out any single class (responsibility implementation), as these classes would depend on concrete implementation of each other.

What was implied by "Dependency Injection to serve the purposes of testing" is that all possible types (with some exceptions for those that just hold data, and such) within a project would have an interface associated with them.

Layered architectures aren't decoupled at all. As each layer depends directly on layer below it. However, when layers depend on each other using interfaces only (plus value objects,... or also on polymorphic abstractions), then it's possible to swap out implementation of layers below easily (ie. different persistence layer for testing,..). Another way is also hexagonal architecture, or ports and adapter,... Which could make code to be too decoupled. However, all of that nice structuring can get easily destroyed, as Java allows cyclical dependencies.

Layered interfaces refers to things like in C#: List Implements IList, which derives from ICollection, which derives from IEnumerable, and writing things this way is far from uncommon.

It's worth noting that Rust does allow for this but its developers have generally decided that many small interfaces are preferable to complex hierarchies of interfaces.

And, the whole "correct OOP" thing is quite subjective area on its own,... Many say OOP is actually a mistake,... As for me goes, when toying in golang, the only thing I really miss, is generics. However, I'm neither against, or for, OOP.

Those who say "OOP is a mistake" either misunderstand OOP and blame OOP for shitty programmers who also don't understand OOP existing or they learned to program in the 70s and 80s and are clinging as hard as they can to C to try to remain relevant.

The irony being that OOP is an extraordinarily simple concept. All OOP really is is architecting your program to be a box of things that have adjectives and can verb each other, and this box of things is attempting to closely model real world objects, processes, or concepts. That's it. Nothing more. Nothing less. The rest is all implementation details, and things that make it easier to achieve creating said models.

Note that the definition says nothing about inheritance, interfaces, VTables or anything else. All it really requires is user definable types and arguably the ability to have methods on types (you can do it without but writing code that way is painful). Which means that for example: it's entirely possible to write OOP code in Javascript, in spite of it having almost none of the language features of C# or Java.

Dunno Rust's traits that well,... I need to learn it a bit.

The tl;dr is they're interfaces with the ability to define default implementations, with the added benefit that if you created the type you can implement any interface you want on it, and if you created the interface you can implement it on any type you want including primitive types such as i32.

For now, Java,... C# doesn't have any performance related advantage to Java, when it comes to mobile platform. When a language comes, which allows to write applications as easily as in Java, and offers a better performance (and memory usage), then a change might happen.

I mean... XobotOS https://arstechnica.com/information-...on-of-android/ was substantially faster than Android, and C# is much better about memory usage vs Java because C# programs produce less garbage for a variety of reasons. So what you're saying about performance isn't really true.

People write in Java and Kotlin for Android because it's what Google officially supports and recommends on the platform, much like if a developer deigns to support iOS they're going to write in Objective-C or Swift for that platform. It doesn't really matter how nice or performant a language is, unless Google considers it a first class citizen in its ecosystem, only the more adventurous developers are going to bother trying to play with it.

[kpedersen]

You people that keep saying it just requires "more skill" to write error free C code are the reason we have so many vulnerabilities in today's software.

Using the term "error free" is naive. However I am confident that disciplined C developers adhering to good standards like MISRA will develop software which has less memory errors than Java or C# when dealing with something like OpenGL or device drivers.

Remember in Java / .NET when accessing hardware, you still have to use raw memory correctly. You also have to "Pin" the GC memory so that it doesn't clear it. You still have to manually free memory that is no longer used and that the GC does not know about.

But of course the typical managed developer will just grab a (probably obsolete) binding and blame someone else when their project turns to mush. Been there done that, I have worked with Unity / C# developers before and they are the worst XD.

C and C++ also have 3rd party garbage collectors asan and Valgrind. Debugging tools for raw memory in Java or .NET are very primitive because that is not a common usecase for these technologies.

[smitty3268]

You people that keep saying it just requires "more skill" to write error free C code are the reason we have so many vulnerabilities in today's software.

It makes it pretty easy to spot the people who have never been involved in writing highly complex software in C.

[jabl]

Well, maybe I'm placing too high value on GC,... I had hated GC in past, and was studying/researching it a bit, and it's not that bad, considering that zero learning is required from developer. And, also found, that GC could outperform reference-counting based memory management (as, reference counting requires atomic operations, and also checks for zeroing reference count,...).

Rust has it's ownership/ borrowing system which is neither GC nor RC. Rc and Arc types are available in the standard library for those cases when the ownership system isn't sufficient, but in a well written Rust codebase those cases are presumably quite rare.

[cynical]

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

The JVM is written in C++, and one of the main authors of it says he would never do it again because of how difficult it is to maintain now (they basically haven't been able to add major new features in years for fear of breaking something). According to him, Java is fast enough that he would rather use it instead because it is safer and less error prone, and what do you know, GraalVM is a Java VM written in Java... (which will replace HotSpot eventually)

You people that keep saying it just requires "more skill" to write error free C code are the reason we have so many vulnerabilities in today's software. If the language can eliminate a whole class of errors for the developer with a small performance hit, that's totally worth it. Who wants to sit there and figure out memory management problems instead of working on the actual problem their code was written to solve?

[ssokolow]

Go also has a problem with refusing to accept the "but not simpler" part of the famous Einstein paraphrase "everything should be made as simple as possible, but not simpler".

I want off Mr. Golang's Wild Ride

TL;DR: Go developers are determined to force simplicity, even when the problem domains are inherently complex, and the resulting abstractions get frustratingly leaky.

You're placing way too high a value on garbage collection. The days of manually futzing around with memory are over even in C++, don't need a garbage collector for that. Rust's ownership model takes care of memory to the same degree a garbage collector would, minus the overhead, and that scripting languages suck isn't really a point in Go's favour.

Well, maybe I'm placing too high value on GC,... I had hated GC in past, and was studying/researching it a bit, and it's not that bad, considering that zero learning is required from developer. And, also found, that GC could outperform reference-counting based memory management (as, reference counting requires atomic operations, and also checks for zeroing reference count,...).

Eh... usually the complaint is that C# and Java applications are too decoupled, with overuse of dependency injection (in order to serve the purposes of testing), layers upon layers of interfaces, and general code explosion not the reverse. With the other major complaint usually being that people who don't actually understand OOP, writing code that's not actually OOP by misusing inheritance.

Dependency injection doesn't guarantee anything about (de)coupling,... It's just a way how instances are wired together. Also, as it makes that wiring easier, it's actually easier to write more coupled code. Issue of coupling in Java lies in ability to import classes from other packages allowing cyclical dependencies between packages. Even though project might look from package structure as nicely decoupled, the actual logic could be placed anywhere. These classes could be easily heavily inter-coupled. The whole project could be using DI, but actually it would be impossible to swap out any single class (responsibility implementation), as these classes would depend on concrete implementation of each other.

Layered architectures aren't decoupled at all. As each layer depends directly on layer below it. However, when layers depend on each other using interfaces only (plus value objects,... or also on polymorphic abstractions), then it's possible to swap out implementation of layers below easily (ie. different persistence layer for testing,..). Another way is also hexagonal architecture, or ports and adapter,... Which could make code to be too decoupled. However, all of that nice structuring can get easily destroyed, as Java allows cyclical dependencies.

And, the whole "correct OOP" thing is quite subjective area on its own,... Many say OOP is actually a mistake,... As for me goes, when toying in golang, the only thing I really miss, is generics. However, I'm neither against, or for, OOP.

Additionally Go's implementation of the Interface concept isn't all that wonderful, and has the same fundamental issue as Java's due to (like most problems with the language) being too simple, whereas C# and Rust neatly sidestep the problem of method name collision in interfaces by tracking what's being implemented.

Dunno Rust's traits that well,... I need to learn it a bit.

Java really, but yes. Granted you can use Xamarin with C# and Qt with C++, as well as a few other things, but Java is really the language de jure for Android which is really the only platform that matters in mobile.

For now, Java,... C# doesn't have any performance related advantage to Java, when it comes to mobile platform. When a language comes, which allows to write applications as easily as in Java, and offers a better performance (and memory usage), then a change might happen.