Wait , so can rust generally be replace C++ code in most projects ? Has anyone here had success with a partial to Rust migration.
> Has anyone here had success with a partial to Rust migration.
Firefox have.
Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust
71–80 of 393 posts
Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust
#72Is this because of memory bugs\vulnerabilities that target the stack or just because it was too old and junky?
Also, a strong point of Rust is just the way the types and the defaults are. Most people think the borrow checker is the only major thing, but Rust have this features:
* Plain Structs
* Rich enums (aka: Algebraic types) that leads to
* All replacements to nulls (Option, Result, Default(trait), Empty(idiom))
* Immutability and functional style as preferred when sensible
* Consistency in APIs by proxy of traits (all conversions going with Into/From traits, All iterables can .collect into all containers, etc)
and many things like this that make very productive to build good APIs when you get the handle of it.
Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust
#73Wait , so can rust generally be replace C++ code in most projects ? Has anyone here had success with a partial to Rust migration.
I mean, Mozilla migrated parts of Firefox to Rust, that's the big one. I hear it might start being included in the Linux Kernel soon.
Rust originated from Mozilla...
Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust
#74Earlier quoted context omitted.
Junkiness and vulnerabilities go hand in hand.
True that. maybe I'll rephrase, was Rust specifically chosen to address memory concerns? I don't think it is too common in Android.
> I don't think it is too common in Android.
??? Android crash little things left and right, and have leaks just for existing.
Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust
#75Earlier quoted context omitted.
My guess would be that they can apply much more pressure to the Bluetooth chip vendor. The buying power that Apple has for designing in a particular chip is much bigger than any individual Android manufacturer (even Samsung). That gets them the leverage to get the chip vendor to do what they want.
I wouldn't be surprised if Apple write their own firmware for things like bluetooth chips.
There's quite a bit of evidence that they do. Apple's strength has always been at the point at which hardware is built and interfaces to the software, including firmware.
Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust
#76Earlier quoted context omitted.
My guess would be that they can apply much more pressure to the Bluetooth chip vendor. The buying power that Apple has for designing in a particular chip is much bigger than any individual Android manufacturer (even Samsung). That gets them the leverage to get the chip vendor to do what they want.
I wouldn't be surprised if Apple write their own firmware for things like bluetooth chips.
I would be surprised if they didn't. They advertise their own Bluetooth chips H1 and W1 in AirPods and some Beats products. These chips definitely have their own firmware and it would be rather ridiculous not to also have their own firmware on the host side, maybe even re-using code.
Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust
#77Nice to see this. Sadly the Android team, while taking this safety steps, it keeps using unsafe C userspace for NDK APIs. Security is as good as the weakest link.
This is false and a meme that continues to stall progress. Hardening the BT stack means that accidentally crappy or adversarial devices cannot use a buggy BT stack to pop a device, from kernel mode remotely.
This is a hugely welcome change. The threat model from a app using the NDK is much different than having a drive by wireless attack.
Defense in depth and put focus on protocols and parsing, the rest of our stacks will come in time.
Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust
#78Earlier quoted context omitted.
So to clear I can't just plop a Rust class into a C++ project.
Rust does not have classes, strictly speaking, though you can define methods on structs. https://crates.io/crates/cxx is the simplest way to do an integration. It is slightly more work than "just plop in" but it's not incredibly difficult. It's harder than mixing C and C++ together, but then again, almost no pairings of languages are that easy.
Then C++ doesn't have classes either, you can put methods on structs though.
Rust people keep saying there are not classes, but all a class needs it the ability to put methods on structs. Private access to some of the internals is often useful, but doesn't need to be enforced by the compiler.
Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust
#79Wait , so can rust generally be replace C++ code in most projects ? Has anyone here had success with a partial to Rust migration.
I think the answer is yes. Most C++ projects would be better served by Rust. However there are many caveats: - I think that C++ devs are still more numerous than Rust devs. - There are many excellent C++ libraries that don't yet have great Rust bindings. Furthermore it is unlikely that template-heavy libraries will ever be easy to use from Rust. - C++ is supported on more platforms. - C++ is more powerful. (Particula…
Meta-programming needs in Rust are addressed by macros. There's not really anything missing there compared to what C++ does via templates.
Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust
#80Earlier quoted context omitted.
I suspect that Zig will still end up eclipsing Rust - not because it's a "more powerful" language, but because it's much easier to learn. Lower barriers of entry seem to matter more than mere "power" - see Common Lisp's multi-decade feature lead being ignored, and Python leapfrogging other more capable languages (Common Lisp) or equally capable ones that came first (Ruby) due to ease-of-use.
Rust isn't that hard to learn. I teach it to college sophomores who only know Java, and within 2-3 months I have them writing parsers and interpreters in Rust. In fact these students are requesting our courses to be taught in Rust, and have never heard of Zig. I think that while the language is a little complicated, this is tempered by how nice the tooling is. I consider the borrow checker to be my TA, as it actually…
I'd imagine given another language (e.g. Python), they'd learn a lot faster and be a lot more prodictive throughout the course.