Google Begins Allowing Rust Code For Developing Android

[jabl]

Two big reasons I'm aware of:

1. Ada's compilers were proprietary and expensive back in the beginning, while C compilers came free with UNIX.
2. Ada's safety guarantees are more focused on runtime checks (eg. constraining integer variables to programmer-defined ranges), making it more a middle-ground between Rust and Go as far as the amount of runtime support code you need.

It's a shame Ada never really caught on outside the military/aerospace markets. Software could have been significantly less shittier if it had caught on as the 'standard systems programming language' instead of C. Oh well..

[kpedersen]

Love it or hate it, I don't know any other language that can really serve as a memory-safe replacement for C.

C++ done right is pretty close. They should start with that.

• Add a weak_ptr<T> like counterpart to unique_ptr<T>. None of this "zero overhead" excuses. Safety comes first.
• Zero initialize all memory. None of this "wasteful performance" mental masturbation. Again, safety comes first.
• Iterators, .at(i) and [i] should also all be bounds checked. None of this "that is expensive when I know its within bounds" crap. It has proven they keep making mistakes. Safety first.

It is the mindset of C++ developers that cause the problems. The language itself can actually be very safe.

Even a safe re-implementation of the STL that only gets enabled at debug time could go a long way for finding issues. My quick attempt here has shown some good results: https://github.com/osen/sr1

[bug77]

Exactly that.
We are not talking abput vlu whales .. isn't it?

Well, I've tried hard to put all that behind me (not a fan of autotools), but it was just a matter of defining some targets that would call javac, pack200 (yup, it was waaay back), jar and whatnot in a generic way and then for each project supplying the proper list of files to work with.

[microcode]

Google is working on a new (the 3rd?) bluetooth stack for android called 'Gabeldorsche', this time (partially) using Rust: https://android.googlesource.com/pla...aster/gd/rust/

Ah.. cool. Well good for them, doing exactly what I'd hoped. I swear the way they treat buffers in there... it just isn't right.

[microcode]

C++ done right is pretty close. They should start with that.

• Add a weak_ptr<T> like counterpart to unique_ptr<T>. None of this "zero overhead" excuses. Safety comes first.
• Zero initialize all memory. None of this "wasteful performance" mental masturbation. Again, safety comes first.
• Iterators, .at(i) and [i] should also all be bounds checked. None of this "that is expensive when I know its within bounds" crap. It has proven they keep making mistakes. Safety first.

It is the mindset of C++ developers that cause the problems. The language itself can actually be very safe.

Even a safe re-implementation of the STL that only gets enabled at debug time could go a long way for finding issues. My quick attempt here has shown some good results: https://github.com/osen/sr1

Why work with a language that "can be safe" when you could work with a language that "can't be unsafe, unless you write the english word unsafe in your code"? zero overhead isn't an excuse, it's a feature, not strictly initializing everything at allocation time is also a feature. As for bounds checking, that's also just how the language works in Rust.

I get that you can get some of the benefits of Rust in C++ by always remembering everything you should know about the task, but in Rust you get the same guarantees and more whether you know anything or not.

[microcode]

Two big reasons I'm aware of:

1. Ada's compilers were proprietary and expensive back in the beginning, while C compilers came free with UNIX.
2. Ada's safety guarantees are more focused on runtime checks (eg. constraining integer variables to programmer-defined ranges), making it more a middle-ground between Rust and Go as far as the amount of runtime support code you need.

Here's a post by an Ada user on the Rust users forum which goes into more detail.

I'll add that Ada was also more different from C than it really needed to be, through a mix of accident and intent, and its capture by tools vendors who only had a foothold in their niche was the death knell. Microsoft was able to make Visual Basic a resounding success despite being a single source because they already had a massive captive audience; random Ada toolchain vendors were in no such position, but they acted like they were.

[kpedersen]

Why work with a language that "can be safe" when you could work with a language that "can't be unsafe, unless you write the english word unsafe in your code"?

Rust basically requires a C++ compiler to prepare the *-sys packages and bindings. So you can never have C++ *or* Rust. If Rust is involved, it will always be C++ *and* Rust.

Sounds a bit of a weak reason I know but until a 99%+ Rust native OS like Redox becomes mainstream you can't get away from ANSI C. And it just so happens that C++ consumes C headers better than Rust's FFI bindings ever can.

C isn't just a language. It is the entire computing platform. C++ is (mostly) and extension of that. So making C++ as good as it can be is currently the best way to directly access the computing platform.

(Unless Rust's unsafe {} system can be made to consume C headers directly by invoking a tiny inbuilt C compiler)

[ssokolow]

That's what I was hinting at: if they're aimed at different "niches" and Rust's "niche" is systems programming, Ada's "niche" must be something else.

Not that I have anything against Ada. Every language is great if you use it for its intended purpose and a nightmare if you use it outside of that.

They're for different kinds of systems programming, and Go is for a third kind of systems programming.

What is Systems Programming, Really? — Will Crichton

TL;DR: As defined when it was originally contrasted with scripting languages back in 1972, systems programming was about building infrastructural components with long maintenance lifecycles and large teams. That the tasks also tended to be low-level wasn't part of the definition. (And Go fits the definition... just for a type of infrastructure that didn't exist in 1972: network microservices)

"Systems Programming" is a broad umbrella and getting broader as computers get used in more and more roles and greater reliability is expected of them.

Rust basically requires a C++ compiler to prepare the *-sys packages and bindings. So you can never have C++ *or* Rust. If Rust is involved, it will always be C++ *and* Rust.

Sounds a bit of a weak reason I know but until a 99%+ Rust native OS like Redox becomes mainstream you can't get away from ANSI C. And it just so happens that C++ consumes C headers better than Rust's FFI bindings ever can.

C isn't just a language. It is the entire computing platform. C++ is (mostly) and extension of that. So making C++ as good as it can be is currently the best way to directly access the computing platform.

(Unless Rust's unsafe {} system can be made to consume C headers directly by invoking a tiny inbuilt C compiler)

Rust's advantage comes from giving the compiler more information so it can enforce invariants at compile time. Microsoft and Google tried using better tooling to shake that 70% memory safety vulns number and it didn't work.

Rust gets away with the level of annotation needed because, if you switch to a whole new language, you take writing safety-enforcing bindings to the unsafe world as a given... because it's a whole other language. If you extend C++ to get the same level of safety, you'll lose the degree of effortless interoperation and familiarity you think of when you say "C++".

Plus, Modern C++ Won't Save Us.

[elatllat]

We should tax all products sold with non-memory safe code and give grants to replacement memory safe projects like RedoxOS.

[microcode]

Rust basically requires a C++ compiler to prepare the *-sys packages and bindings. So you can never have C++ *or* Rust. If Rust is involved, it will always be C++ *and* Rust.

Sounds a bit of a weak reason I know but until a 99%+ Rust native OS like Redox becomes mainstream you can't get away from ANSI C. And it just so happens that C++ consumes C headers better than Rust's FFI bindings ever can.

C isn't just a language. It is the entire computing platform. C++ is (mostly) and extension of that. So making C++ as good as it can be is currently the best way to directly access the computing platform.

(Unless Rust's unsafe {} system can be made to consume C headers directly by invoking a tiny inbuilt C compiler)

Aside from the syscall interface, does it matter whether the "platform" is using the C conventions or not? There are lots of rust libraries, and rust programs can call into C libraries entirely at will. There's a project called remacs, where people are incrementally rewriting Emacs in Rust, it's not that hard to mix the two.