Announcement
Collapse
No announcement yet.
Google Begins Allowing Rust Code For Developing Android
Collapse
X
-
We should tax all products sold with non-memory safe code and give grants to replacement memory safe projects like RedoxOS.
- Likes 2
-
Originally posted by bug77 View Post
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.
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.
Originally posted by kpedersen View Post
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 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.
- Likes 4
Leave a comment:
-
Originally posted by microcode View Post
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"?
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)
- Likes 2
Leave a comment:
-
Originally posted by ssokolow View Post
Two big reasons I'm aware of:- Ada's compilers were proprietary and expensive back in the beginning, while C compilers came free with UNIX.
- 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.
- Likes 6
Leave a comment:
-
Originally posted by kpedersen View Post
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.
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
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.
- Likes 13
Leave a comment:
-
Originally posted by jabl View PostGoogle 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/
- Likes 3
Leave a comment:
-
Originally posted by kloczek View Post
Exactly that.
We are not talking abput vlu whales .. isn't it?
Leave a comment:
-
Originally posted by paulpach View Post
Love it or hate it, I don't know any other language that can really serve as a memory-safe replacement for C.- 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.
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
- Likes 2
Leave a comment:
-
Originally posted by ssokolow View PostTwo big reasons I'm aware of:- Ada's compilers were proprietary and expensive back in the beginning, while C compilers came free with UNIX.
- 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.
- Likes 4
Leave a comment:
-
Originally posted by microcode View PostA new Bluetooth service is a good place to look. The current one on Android is horrifying, to anyone who has read what's in it.
- Likes 6
Leave a comment:
Leave a comment: