Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust
android.googlesource.com
android.googlesource.com
Zach, if you're reading this, HUGE kudos to holding the line in replacing that, and double kudos for doing it in a verifiable, sane language!
Unclear why you're being downvoted here -- I seem to remember you, and I definitely remember hearing about NewBlue while we were working on Bluedroid. At the time it wasn't clear what happened. When did you leave?
Correction: god-awful host side bluetooth code.
There is still the bluetooth firmware residing on the BCMxxx chip (or Qualcomm chip) - >1MB of god-awfulerer closed-source code, half of it is in ROM (with limited number of available patch slots), full of bugs. You can see it crash from time to time in the kernel debug logs (and auto-restart itself)
address1, 4 bytes overlay data
address2, 4 bytes overlay data
etc
By the time the chip is 2-3 years in the market and still getting firmware updates, ~98% of them are used by existing firmware, so there are only 5-10 free entries by the time the chip is considered "obsolete".
Case in point: the Broadcom/Cypress BCM43455 chip on the raspberry pi is almost out of patch entries. Broadcom have switched to their usual tactic of stalling for years on known, reproducible bug reports.
And it's still really buggy. I had to write a service on the RPI and the only way to reliably connect was to restart bluetooth before every attempt.
That kind of fix makes a person feel dirty.
Step 1. Have a reliable hardware watchdog that restarts everytime there's a software problem.
Step 2. There is no step 2.
Nobody would complaining about Apple creating their own radio chips (which they seem to plan for 5G/6G). Apple creating their own standard protocols is an issue though.
I fixated on Apple because they're often picked on for taking the highway, but on the other hand what's the point doing otherwise? What's a common ground if it's just a pipe dream?
Breaking compatibility with that ecosystem out of spite is not conducive to getting adoption for a better product.
Now, of course, multiple nines of uptime would be very nice to have (and open up new use-cases), but 2-3 nines is still a lot better than 0.
You're arguing that it's not enough to make a correct implementation, but that it's also important to break compatibility with incorrect implementations.
I'm arguing that a better implementation that is compatible with current protocols is strictly better than a better implementation that is not Bluetooth-compatible.
If you make a piece of hardware that is good (e.g. doesn't randomly crash and need to be rebooted by the kernel), why is it a bad thing for it to try to connect to some flaky BT headset?
And the root of the brokenness is that there isn't the end-to-end awareness and acceptance that ten times the capacity is obviously needed.
Owww.
In general I agree with your comment, though it’s a lot easier to say this in hindsight.
The radio frontend is typically a downmixer and then straight into digital.
Some of the typically "software" bits like FFT's, various encodings, checksums, clock recovery etc. are frequently done in digital hardware acceleration blocks for performance, and saving power. If you were writing the firmware of the device, you needn't use them though.
With enough human years of effort, you could take almost any radio hardware for sale today and repurpose it to speak nearly any other radio protocol in similar frequency bands. Performance will probably be terrible though!
It's rare people do this though - all the chips don't have their firmware documented (again mostly to avoid publishing documentation that proves they are violating someone elses patents), and many have various cryptographic elements that makes reverse engineering hard.
The one exception to this is WiFi chips used in the Nexus 5 by Broadcom, which has had a reasonable amount of reverse engineering because Broadcom accidentally published the source code because the firmware code was in part shared with published Linux kernel driver source code.
:O
Enlightenment moment :(
Companies already in the industry typically have cross-licensing agreements - ie. I can use your patents if you can use mine. Either that or they just violate each others patents knowing that a patent war would be mutual destruction and in neither companies interests.
But a newcomer has nothing to offer - the minute they release any product, every incumbent company will go through their patent portfolio and sue them out of the water.
I thought only the hardware could be patented, not the software, and so SDR would level the playing field, but that's perhaps too naive?
Distraction might not be the right word but I can't conjure up the right one.
Hardware is one of the end goals for Apple, for example. For Google, Android hardware is not. It's just there to serve their goal of selling ads.
Android has never been about driving the hardware narrative -- it's always been about building a phone with mostly open contributions and driving the start of a wedge to open up the phone industry a bit. It's always been a software answer to a hardware problem, even today. Prior to Android, all we had were closed source low powered feature phones and Blackberries.
That being said, building silicon is non trivial work, and building a BLE stack and controller is even more so. Will a solid BLE stack sell phones? Hard to say how it could drive that narrative, realistically, and even harder to say if such a controller could be made cost effectively. Given Android's archetype (software solution to closed hardware), this puts such a project into a much more difficult position politically and financially.
I can't see this kind of thing having much in the way of legs in a large corp. That being said, I do think if a startup could challenge this landscape, it is a HUGE opportunity.
The Android org generally isn't the right org to build hardware, let alone do chip design. Maybe the camera team got closest when I worked there?
Source: worked on Pixel Buds @ Google & was one of several engineers responsible for selecting the chip vendor. We got source access to the entire stack/OS except for the microcode & some parts of the stack they hid. I found BES a way better partner to work with than the BCOM/QCOM mess.
a) they frequently flip flop between at least two BT profiles, leading to a lackluster listening experience b) they lose connection to each other (leading to intermittend profile switches during reconnects, possibly due to lack of available bandwidth) c) they have severe signal quality issues, leading to limited range and audio interruptions
All these issues only happen with the 2nd Gen Pixel Buds, but not with a random sample of various other true wireless earbuds (I tested Sony WF-1000XM3, 1More True Wireless ANC, Airpods Pro) leading me to believe that this must be a hardware issue on Google's side, especially because the amount of people with the same issues is pretty high.
No other pair of true wireless earbuds hat any issues with music playback while I'm on a road bike, with my phone being on my back, only the Pixel Buds do - and I'm on my 2nd replacement already.
Symbian was open source, ran on millions of smartphones - most of which had app stores and web browsers. Some of which had touchscreens, GPS, augmented reality features etc.
Don't get me wrong - Android has been brilliant. But let's not completely rewrite history, eh?
Symbian was far more popular in Europe than it ever was Stateside, so bear that in mind. I had to import my Nokia E70 gullwing phone before I received my sooner, and what functionality it had was okay, but the browser was hardly more than a WAP browser in a feature phone. The app store was barely there as well, including only a handful of very simple apps at the time.
Prior to Android, all we had were closed source low
powered feature phones and Blackberries.
The rest of your comment makes sense, but the cognitive dissonance of that sentence was so extreme I had to respond.
Fun fact: the first Android phone was the sooner, and it looked and behaved much like a blackberry. Still have mine, in fact.
Apple has been building its own hardware from the beginning, but still also uses Broadcom chips.
do you mean designing? I'm not familiar with any point in time where Apple was building phones, but maybe i'm mistaken.
A quick google search indicates that even the first generation phones were built by Hon Hai.
There is a lot of overlap between WiFi and Bluetooth & BLE such that you just have a Wireless chip that does both. In fact I think with Bluetooth 4 the file transfer profile just establishes an adhoc WiFi network. You don't have separate Bluetooth and WiFi chips anymore.
Furthering that, in the mobile space the Wireless capabilities are usually integrated into the mobile SoC. So you don't even have separate chips for CPU and Wireless.
About the only time you see a separate Wireless chip is when a new technology is emerging like 5G and it's usually only an external chip for a generation or two until it can be integrated into the SoC.
So, if you were to design your own Bluetooth chip today you would also be designing a WiFi chip and then you'd probably just roll all that into a SoC with a CPU. No small feat.
This was a feature of Bluetooth 3.0, but almost nothing ever used it. I was once at a big BT testing company and asked about it, and they had like one device that could do it (a crazy feature-packed HTC WinMo device I think).
And then Bluetooth 4.0 added BLE, and it seems like there hasn't been much development of classic BT since then.
I tried it and it can do a few basic things, though it’s in the early stages, apparently.
I got update for my half a decade old Logitech's 2.4 GHz receiver (nRF24L) for wireless keyboard as soon as I plugged it on Linux, I've used the same keyboard on Mac and the official Logitech software doesn't even detect the device properly let alone update the receiver's firmware(no issues using the device though).
What would happen if consistency is lost outside the Rust domain but still in the BT stack?
The counter point does apply to drivers, but it's really not just that.
"Bluetooth is a layer cake of sadness" is the turn of phrase we used for a while on the Glass connectivity team. One of our project founders, Thad Starner actually apologized to me for the mess it became; apparently it was supposed to be simpler, but when Nokia took ownership back in the 90s, it started to go downhill.
Our lead on the connectivity team at the time had a crazy idea to rewrite the spec using only ACL and L2CAP, but never really went anywhere with it because of the the Glass org implosion.
Why does Samsung have smaller buying power than Apple? Doesn't Samsung sell more phones than them? Or is it because while Samsung sells more phones in total, Apple still has the most successful single models?
With Samsung and android, it's a different story. There are many android vendors and the people producing the Bluetooth chips are selling to many of them (broadcom). Samsung has the ability to make their own chips, but to get everything working flawlessly they not only have to make their chips awesome but also improve the android driver stack to work with their new awesome chips. That stack has to also be compatible with the other bluetooth manufactures on the market making it a harder change to make.
In other words, with apple and a vendor, there are pretty much just the 2 parties involved which control everything. With Samsung and vendor it's not just them but also the likes of google and other bluetooth vendors that can get in the way of really fixing things.
If someone senior at Samsung said to their vendor "good Bluetooth or you lose the Samsung account", that would provoke some, um, intense conversations at the vendor between sales and engineering.
Incidentally Apple sometimes has more than one vendor too, so it's not just two parties. I know cases where they've had two suppliers. Displays and modems come to mind, although I've not Googled to verify.
The problem: There aren't that many suppliers left in the field, and Broadcom knows that their customers are pretty much locked in. The notable exception is once again Apple, they have proven that they can and will go and implement the technology on their own if their suppliers fail to meet their expectations.
Samsung could obviously do this too, but as you say, they lack the will - and motivation.
So why should Samsung invest more than the bare minimum when they can't get anything measurable in return?
Edit: Samsung has apparently already ripped out the Bluetooth stack and replaced it with their own - https://news.ycombinator.com/item?id=26650447
Apple controls their whole stack. They've already written the Bluetooth stack for their OS. They only have to service their devices.
> Incidentally Apple sometimes has more than one vendor too, so it's not just two parties.
Not the point I was making. It's not an issue with multiple vendors, its and issue of who controls what. Those other vendors also have to conform to apples standards if they want to sell apple their products. What I'm talking about is the fact that a bluetooth device manufacture has to conform to google's android standards if they want to sell their chips to android manufactures, not to samsung standards. That's where the leverage goes away.
If samsung ever pulls the trigger and uses Tizen everywhere, then they'll be more in Apples position. Until that happens, they need to work with google to get stuff done.
If broadcom says it's going to be expensive to fix, either you pay or you don't. But it has nothing whatsoever to do with "controlling the whole stack".
As an aside, and it's totally irrelevant to the above, but there's nothing other than the amount of work involved preventing Samsung writing their own bluetooth stack. They write plenty of custom drivers and they created a folding device prior to OS support. If they wanted to they could; they just apparently don't think it's worth the cost.
Edit: according to a comment down thread they have done exactly that.
The same thing could be said for Qualcomm's failure to support it's SOCs for more than a couple of years. Device makers could force their hand.
That works, even works well, as long as device makers feel that supporting SOCs for a limited period helps them sell more phones.
Apple has changed the rules of the game by supporting its devices for longer -- and as phone upgrades become more infrequent due to plateauing technology, I think device makers will realize this.
Samsung has already committed to supporting recent Galaxy devices for at least 4 years -- at least with security updates[1]. I suspect this was also because they found that their extremely short-sighted prior policy re security updates encouraged corporate phone procurers to ditch Samsung and go with Apple.
[1] https://www.theverge.com/2021/2/22/22295639/samsung-galaxy-d...
However, if we're going to count years where you only got a security update, the iPhone 5s is currently on it's 8th supported year.
Apple can come to a vendor and say "these are our constraints on what we are willing to buy. Here's testing benchmarks. You are required to meet them. Failure to do so voids the purchase contract."
The vendor will then, of course, say "We'll have to charge you more if we're spinning up a test infrastructure we don't have."
And then Apple will negotiate a price point and pass the anti-savings onto the consumer.
They do this at multiple levels at multiple points in their hardware story. I met someone once who worked on the USB integration specs back in the first-couple-generation iBooks. Apple built a rig for physically testing the connectors (including multiple cycles of intentional mis-plug, i.e. flipping a USB-A connector over wrong-side-up and pushing hard against the socket). They told the vendors selling them USB sockets that the sockets had to survive the rig, or the sale was void. Vendors priced accordingly. But the resulting product is more robust than others on the market.
I'm not sure about this. There are people who pay >1000€ for their flagship phones and believe them to be premium products, but they are just as buggy as the cheap ones. Huge amount of CPU power and impressive camera specs, though.
The S21 Ultra seems like a very good purchase from reviews. QHD screen with dynamically adjusted 120Hz seems really like the best spec.
Apple sounds like it really is that rigorous with the quality of hardware and drivers/firmware they use.
Some of the stories of nitpicking that I’ve heard are truly awe inspiring. On the other hand, I’d hate to be the engineer on the vendor side trying to please apple. (Mostly because some crap PM or sales person made promises without consulting engineering on what’s possible with the available time and resources)
We've been together 4 years, its USB port is a little loose now. Too much charging everyday, but the screen is still pristine. The camera is fine so we can go out and take photos at the beach. I'm happy man. It does what it said it would do and did it. And still doing it.
Not just that, every apple device has wireless access, and Apple has thrice the operating income and more than twice the net income of Samsung Electronics.
But yes the "value" of individual devices is also part of the equation, in the sense that Samsung has a lot of cheap-ish devices with fairly short lifetimes, they're not going to fight for device quality. Apple has a very limited number of devices they support for a long time. And they're probably bringing in a lot of baggage from having been screwed over by the plans and fuckups of their suppliers in the past.
And even then, the more time passes the more they just go "fuck'em all" and move chip design in-house, not just the "main" chips (AX, MX, SX) but the ancillary as well: the WX and HX series integrate bluetooth on the SoC. There's no doubt they'll eventually go their own way on larger devices as well, the U1 is probably the first steps towards that.
I think my overall point is still valid because I have had Samsung phones for a while and have found their Bluetooth to be pretty good. This is not surprising as Samsung actually bought one of the biggest Bluetooth chip vendors (CSR) at one point, so they do have control over the full stack.
("what was advertised as" because there wasn't really a differentiation in the R&D bits, so there was a somewhat arbitrary split and hasty redacting of repos given to Samsung to avoid names of other customers in comments).
Samsung's phone division and electronic parts division aren't the same thing, so there was no guarantee that the phones would buy the Bluetooth/Wifi from their new acquisition, although I hear they did eventually.
So the reason Samsung typically has less influence is that when all you do is crush your suppliers margins to make your own, said suppliers don't tend to make much of an investment in making things better since they are incentivized to just make them cheaper.
[1] in fairness, they can't afford to: while Apple has an ongoing revenue stream from its devices, most other manufacturers don't. It's Google/Facebook/etc who monetize the devices post-sale while for the original device manufacturer it's merely a liability at that point. This is a factor in why Android has a rather dismal track record re: updates on older devices.
https://news.ycombinator.com/item?id=26625356
tl;dr Using USB3 ports can cause Bluetooth dropouts on Macs (and lots of other machines).
I've noticed that Bluetooth connectivity is significantly worse when the laptop is closed. You might see if keeping it open helps.
Resetting the Bluetooth module also helped resolve some persistent connectivity problems I was having (shift+option+click on the Bluetooth menubar item; choose "reset" from the menu).
Eventually this thing started having kernel panics every time I plugged something into a USB-C port and I had to send it back for replacement. Not a great experience.
I can't believe Bluetooth is still such a pain in the bum in 2021.
Once you move to all Apple bluetooth, things really smooth out. It seems that Apple does way more testing/validating of their Bluetooth stack.
Although of course Apple might well be better anyways; one would hope that billions of dollars in R&D plus caring about quality makes a difference.
Sometimes you have to make a choice on which brands/chipsets you support. Devices on different ends of the compatibility spectrum can basically be mutually exclusive. IIRC if you advertise A2DP some devices supporting only HSP won't work, so you can make some hacky workaround but then your nicer A2DP equipment is harder to use. If you only need to guarantee support for X subset of devices you control, it's easy to tweak the settings so they work well together.
Apple's stack does work great with Apples hardware, though.
Bose bluetooth headphones, third party "high end" bluetooth devices... not so great. Lately it's been better, though.
This is a joke right? My M1 BT goes out to lunch several times an hour. It is literally unusable.
> We are missing Rust support in our GN toolchain so we currently build the Rust libraries as a staticlib and link in C++.
4K lines of Rust is not a BlueTooth stack.
[1] https://fuchsia.dev/fuchsia-src/contribute/contributing_to_n...
[2] https://cs.opensource.google/fuchsia/fuchsia/+/master:src/co...
At face value, protocol stacks such as TCP/IP or bluetooth, are great use cases for a language like rust in a resource constrained environment (battery, CPU) where you are looking to get high throughput, low latency, etc combined with decent zero cost abstractions so you can make some strong guarantees about e.g. correctness. A good high level implementation, might be usable across different OS kernels. Of course these kernels have very different designs so it might make less sense at the code level than I imagine.
I do wonder about where Google is headed with Fuchsia. Do they have a plan at this point for getting OEMs to want to switch to that? I imagine e.g. Samsung might have some hesitations about being even more dependent on Google as a supplier.
Does it make them more dependent? Google is effectively the only upstream for Android, and Fuchsia is open source, so it seems like it should be the same?
Fuchsia is open source but closed source friendly (because of the license). I suspect that's actually the main non technical argument for Google to be doing this: Android is too open and they've been trying to fix that for years. Apple has a similar benefit with the BSD internals of IOS and OSX. Still OSS in part but mostly not and Apple has not bothered with supporting separate Darwin releases for a long time.
So, like with Android, I'd expect a fair amount of closed source secret sauce is going to be needed to run Fuchsia. More rather than less. I doubt Google free versions of Fuchsia are going to be a thing like it is a thing with Android. Google is doing this to take more control of the end user experience. Just like Apple does with IOS. Letting Samsung (or anyone) bastardize that is not really what they want here.
I'm guessing, Samsung actually wants less of that Google secret sauce at this point rather than more. They are trying to differentiate with exclusive features, their own UX, their own apps, and services, etc. I'm expecting a lot of OEMs are going to have a similar mindset. Especially the Chinese ones currently shipping flavors of Android without a Google license for the play services on the wrong side of the current trade wars (like Huawei). Google has got their work cut out there trying to get OEMs like that to swallow Fuchsia. I think, Google is going to end up supporting Android for a long time because of this even if they eventually launch Fuchsia (which in my opinion is not a certainty yet). The simple reason for this is that the alternative would be walking away from a chunk of the mobile market that they currently exploit via their play store. I don't see them surrendering that and I don't think they would want third parties to continue releasing Android without Google either. So, the only way to prevent that would be a long term Android development strategy regardless of whether they actually release Fuchsia or not.
So, reusing code across Android and Fuchsia makes a lot of sense.
You mean Tizen.
Which, just like Android, the only thing it shares with Linux, is the Linux kernel, now having its own C++ stack, .NET Core/Xamarin and there are still some Englightment leftovers.
This Android Bluetooth stack is mostly in C++. Only part of it (about 4K lines) is written with Rust.
The headline is misleading.
* Devices getting stuck at max volume (thankfully not headphones)
* Devices getting stuck at really low volumes
* Devices randomly switching between absolute volume and relative volume (not really sure how to describe this, but sometimes changing the volume on the phone changes the volume on the receiver, and sometimes it changes the mix volume on the phone only (like an aux output would behave) and keeps the volume on the receiver)
* Needing to enable Developer Settings to change the Bluetooth protocol version and other wacky stuff that I just shouldn't have to do [0]
* Headphones cutting in and out when exercising, like the phone can't figure out it needs to stay in the higher of two radio power profiles that it's switching between, as the receiving antenna on my workout band moves 2-3 inches away from the phone and back again
[0]: https://www.reddit.com/r/GooglePixel/comments/8hbcuu/the_100...
Bluetooth has been awful on Android for a long time. I've never not had to futz with it to get it to work. I hope this is a move toward making it as seamless as it should be. I couldn't imagine trying to figure all this out as a non-technical user.
What I _do_ have problems with is the stupid accompanying apps on Samsung phones (Wear and Buds) that are reinstalled automatically every time I reconnect.
Dear Samsung, how many times do I have to refuse the ToS and delete the app before you get my point?
(I don't use the apps because I don't want any of the "smart" functionality and I don't like Samsung sharing my data with unspecified third parties)
Let me explain: on the first run the app demands access to lots of personal data including contacts and location data while at the same time stating they may share this data with partners and third parties. If you don't agree to _all_ these the app will not start (but continue to nag you)
If Samsung wants to make the app a requirement, they should remove analytics and also let the user choose if he wants to give the app all these permissions.
- volume stuck low or high (on headphones :/) - "fixed" with a quick bluetooth off/on cycle
- volume okay but not responsive to changes in system volume
I've become used to these issues but I'd love a new driver that made them go away!
I think it’s just Bluetooth itself being cursed.
re:Watch, it is likely using WiFi at least some of the time. My Watch shows up on my WiFi and conveniently connects using the same network as my phone, so it apparently knows the WiFi credentials from the phone, at least on a personal network. I never explicitly set that up, and getting Watch to stay off WiFi isn’t something I persisted at - mainly because it does help create a more perfect connection experience than is possible with Bluetooth.
I discovered this initially when I was charging my Watch, while well outside of bluetooth range but just barely in range of WiFi.
Hence my desire for a headphone jack.
Honestly, I think the issue is the bluetooth itself, it an amazing but extremely fragile technology. My Win 10 laptop crap the bed with the internal bluetooth. And it crap the bed with the USB bluetooth transceiver as well. Microsoft been having issue with bluetooth. The same for OSX, Apple have their issues with it. They recently released a update to fix the bluetooth issue in Big Sur M1 and that didn't fix the issue.
* It's a purposeful re-write: not just because it sounded like a fun idea, but because there are reasons to redo the stack. Memory security a main one given the choice of language, but presumably cleaning up the logic and making it better overall is another.
* Broken-windows theory of software development: Writing in a sloppy, old, foot-gun language encourages bad code that just barely works for the happy path. Writing in a language that is far stricter and requires intention and design makes one think a little more critically about the logic.
https://fuchsia.googlesource.com/fuchsia/+/refs/heads/master...
Or is it more of a "What if" thing? Ie there's not many problems currently, but the liability is a huge deal?
to be clear i work in Rust, use it for all my projects, etc - i'm a fanboy, but i also recognize there's a lot of hype. I'm always keeping an eye out for the Rewrite It In Rust (RIIR?) meme vs actual needs.
Which isn't to say that i think people _need_ to have a reason to use Rust, i use it for everything because i (and my team) prefer it - but i think the meme is destructive.. so i'm always looking for it heh.
Additionally exposing some NDK only APIs to ART would also be welcomed from security point of view.
And since we are at it, support Rust on the NDK LLVM toolchain.
I'm actually one of the main binder userspace maintainers in my day job there (opinions are my own), and I haven't heard about this. Do you have a reference? What has happened is that there is a userspace shim over libbinder called libbinder_rs which provides Rust support for binder, but AFAIK, the kernel driver and main userspace lib is remaining in C++. Still, would be cool.
Your Friend, Steven Moreland
[0] https://github.com/Rust-for-Linux/linux/pull/145 [1] https://github.com/Rust-for-Linux/linux/pull/130
https://fuchsia.googlesource.com/fuchsia/+/master/src/connec...
To be honest, I didn't pay much attention to it for a while -- it felt like it might have simply been that day's "flavor of the day", destined to sink once then next flavor became popular.
Now, there's a real problem to be solved. But I thought a simpler approach would be needed (e.g., Zig or something like it). I guess that may still happen, but seems more and more like Rust is here to stay.
Discussion from 9 days ago: https://news.ycombinator.com/item?id=26537693
Zig misses a lot of futures that modern C++ has without offering anything in return. Yeah, it's easy to learn compared to C++ and Rust, but what the point of learning it if doesn't offer anything new?
I don't think Zig is meant to replace C++. It's a cool language on its own.
By the way, you've been shadowbanned if you haven't noticed it yet.
I understand that the language has a steeper learning curve but it’s an upfront cost compared to C (or Zig?) where you have to put even more effort later on chasing the same bugs which Rust could’ve protected you from.
I don’t know Zig well enough so I’m not arguing against it. It’s just what I think about being safe vs being easier to learn.
But I see your point. At the end of the day, the growth of the language happens almost organically and might not follow the logic I put forward.
So like a single player video game, it might be an easier overall choice, in a hypothetical world where ecosystems are similarly fleshed out.
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 helps the student write code that is structured better. When they go on to write C and C++ in later courses, their code is actually more memory safe due to having their habits having been shaped by Rust.
To me it's the difference between programming and computer science.
I do wonder if Rust is easier or harder than other comparable languages like C / C++ when the person has no prior knowledge of programming.
I would say just the ease of having a hello world and the ease of the Rust book would make it easier to get to grips with. No dealing with complex build systems and compiler flags at the start
I can answer this because I previously taught the course in C and C++. The students supposedly have some knowledge of Java but they seem to always have forgotten all of it when they reach me.
Students learning C use all of the footguns you can imagine. The biggest problem for them is writing code that segfaults, and their code always segfaults. It's not so much a problem that it does, but that there is 0 useful feedback as to why the segfault occurred and where they could potentially look to fix the problem. The bigger issue for them is memory management. They frequently walk into the use after free, double free, and memory leak walls. They also have significant trouble with N-dimensional pointer arrays. They have trouble allocating the appropriate memory for these arrays and can't seem to visualize the layout of memory.
C++ is a little better because they have experience with Java, but they are frequently mystified by constructors/destructors and how to manage memory manually (they only have experience with a GC), and template programming is always an issue. But they still run into the same issue with segfaults.
Rust makes all of this go away. They don't have to manage their memory manually, and they don't encounter a single segfault. Ever. We are able to just sweep all of those problems under the rug, and move on to actual content. With C/C++ we focused a lot on the language with the hope we could use it as a tool eventually, with Rust we use the language as a tool and focus on the wider world of applications for which that tool is useful.
You are doing it wrong If you are manually managing memory on Modern C++.
C++ has RAII built in even before Rust came to the scene.
I've never had a situation where I had to manage memory manually during my professional career in C++
If your students face seg faults, please show them Valgrind. Valgrind is better than GDB when it comes to seg faults. It can show you where exactly error occurred.
Edit: Oh I got downvoted for saying truth. I now know what they are really up to.
"C++ is a little better because they have experience with Java, but they are frequently mystified by constructors/destructors and how to manage memory manually"
And yes we use valgrind, but it's important not to overload students who are new to programming. Students tend to reach for withdrawal forms when you tell them "I see you are overwhelmed by this new tool you're learning. To solve this problem here's a new tool to learn". The near-universal sentiment I've gotten from students going from C/C++ to Rust is "Wow, this is so much nicer". YMMV.
You claimed that you don't have to teach Manual Memory management in Rust so why not do the same for C++?
"Rust makes all of this go away. They don't have to manage their memory manually"
Both C++ and Rust has manual memory management but rarely needed. Both supports RAII where everything managed automatically.
Depending on what kind of work you do, you may not have a choice as to whether you get to you smart pointers or not. Our students go into work with decades-old codebases littered with new and delete. They need to know what they do.
> You claimed that you don't have to teach Manual Memory management in Rust so why not do the same for C++?
Because there are no old rust codebases where manual memory management is an issue.
It's also student fault if he selects a company with C++98 codebase. The student shall do due diligence.
It's my advice for you to teach the Modern C++ before driving into legacy C++ sort of like how you teach History. You start what's current then drive deep under.
It builds intuition.
A lot of universities stuck in C++98. It will takes them 1000 years to adopt C++20 tho.
One of mistakes many universities do is teaching either C or Java before C++.
I find C++ as a minimal OOP language to get head start.
C++ -> Java -> C
But if student is a complete noob to programming, I'd suggest to learn Javascript before going to C++
Again, this is to keep the intuition otherwise they will forget what they learnt.
I wish if many universities listened to Kate Gregory talk.
When you teach Java before C++,
Students try to write C++ in Java Style (Eg with new and delete). I answer plenty questions of students on Reddit's cpp sub who are trying to write C++ in Java style. I might make a talk on this in CPPCon.
When you teach C before C++,
Students try to write C with Classes.
But, as once Steve Jobs said,
"I used to think that technology could help education. I’ve probably spearheaded giving away more computer equipment to schools than anybody else on the planet. But I’ve had to come to the inevitable conclusion that the problem is not one that technology can hope to solve. What’s wrong with education cannot be fixed with technology. No amount of technology will make a dent."
You can laugh at me, that's okay. But truth is truth!
By the way, This is my 50th throwaway account. I use them because I'm getting down voted to death when speaking in defense of C++.
I was blessed that my own university during the early 90's, already teached C++ after Pascal to first year students, C was never taught explicily and naturally Java was like 6 years away to be a reality.
The same univerity does teach modern C++ nowadays.
Sourcetrail does amazing job at explaining larger code bases. Check it out.
So you are saying they should (as totally newbies) ask to go through a company's code before accepting a job?
https://jobs.smartrecruiters.com/FireEyeInc1/743999738511776...
They can also look at the creation date of company and make a educated guess.
I guess there are lots of demented and broken codebases out there, but starting students with the broken dysfunctional case as the default seems wrong. They can learn bad habits on their own later.
I don't know what kind of career you had but it's nothing like any C++ career I've ever heard of. Do you never allocate integers or other basic types on the heap? Do you never deal with C-strings? Do you never interact with C libraries? Do you never call posix functions?
A C++ career is full of memory management. You got downvoted because it appears you're speaking from a lack of experience. Even if what you're saying is the truth, I would say you fell into a lucky niche that is unusual compared to the average C++ programmer.
It's fairly mixed. Compiler warnings and errors are great. IDE integration is improving. CPU profiling with perf/hotspot is fine, albeit memory-hungry. Debugging and memory profiling is still bad compared to java.
Zig also seems far too opinionated & even self-contradictory. Like no hidden control flow means that you can't have operator overloading because apparently the + operator is invisible to people or something. And if it could be overridden it could call a function (gasp!) or throw an exception (double gasp!), followed immediately by a big section about how the + operator internally is hidden control flow and can throw an exception (overflow checking).
It then also constantly claims itself as being small & simple, but it has compile-time reflection & evaluation for templated functions - which is widely considered the main complexity of C++. I think Zig is better overall having this feature, I love constexpr & friends in C++, but compile-time code generation & evaluation over generic types is also not "simple" nor "small".
I suspect zig will eventually fill this niche. Proper arrays and strings and better compile time execution support while still being a small, simple, explicit language are quite significant improvements on C.
And as a bonus Rust includes a package manager today, instead of a coming eventually promise. So I'm not seeing why I'd ever go with Zig over Rust if I was migrating off of C today?
If I imagine a world where Zig is 1.0, and has the same tooling/ecosystem as Rust, and I want to make a single player game from scratch, I would probably pick Zig over Rust, and Zig over C or C++.
As VP of marketing bullshit I recommend you double check your source of information as we never claimed that Zig has no metaprogramming, in fact comptime is mentioned on the front page of the official Zig website and the codesample on the right of it shows comptime metaprogramming too.
That said, is you need something stable today, then Rust is undoubtedly the better choice.
I can only speak for Go, not Zig at all, but not giving me the "wand colors" meant that when i still needed colors to solve my problems, i had to invent them myself. .. okay this analogy breaks down there, but yea. The need for basic things like iterators, enums, and sometimes even generics didn't go away in Go. They didn't stop being extremely useful patterns or abstractions. They're just missing.
So what do you do with something that is still useful, possibly needed, but missing? You reinvent it. Very basic behavior like Iterators, Maps, etc become separated by piles of functions spread out all over the page. Yea, it's all simple - no complex features, but also no way to express that logic tightly, quick to reason about. Go wears down your scroll wheel in my experience (~5 years).
Would i have the same complaints about Zig? Your comment leaves me feeling like i would.
Yup, see for example java.lang.Comparable which is basically just the standard library going "yeah the language screwed up, here's your operator overloading"
Back then the main draw of Python was supposed to be the "one way of doing things" - Python originally started as a teaching language.
And look at Python today - there's what, five different "standard" ways of packaging libraries? (And why is "packaging libraries" even a thing?) Instead of "batteries included" we get at least four different ways of doing every common task: the stdlib Python 2 way, the stdlib Python 3 way, the "standard" community third-party synchronous library and the "standard" community async one.
This is just how it always is. Every language starts with the goal of being small, easy to understand and beautifully composeable.
The cruft builds over time because people eventually want it and because none of it ever really goes away due to backwards compatibility.
I think it's best to make peace with this fact, learn to live with the cruft and accept existing languages rather than switching your entire stack every three years trying to chase an unobtainable dragon.
If you have fast iterative build times, lots of assertions, and good debugger there is no reason to waste time writing it in another language first.
Almost every system uses basic vectors and matrices/quats, most gameplay code also uses them etc.
Have you ever heard of matrices and vectors? You need them in a lot of DSP (digital signal processing) applications, like audio and video filters, or in 3D graphics. Being able to write
x = m * y
x = m.vector_mult(y)
x = m * y
x = m.vector_mult(y)
I've been interested in D since the early days (back when it had two competing standard libraries) - I think you're kind of misrepresenting why D never caught on - it wasn't that people weren't interested in a better C++ - it's that D was unsuitable for a lot of scenarios C++ was used because they decided to include GC in the language and it needed to have a runtime that supports it. This put D more in the C# alternative camp than C++ alternative, it was harder to port (I don't know if D still has a working iOS or Android ports, it didn't have them a few years ago when I last checked). And as a C# alternative it's strait out worse across the board (C# has quite string native interop so D doesn't really win much, tooling ecosystem and support is levels above).
If someone came up with something ala D (strong C/C++ interop, fast compile times, good metaprogramming, modules, package manager) without the GC and LLVM based (so it's super portable out of the box) I'm sure it would gain traction. The problem is that's a huge undertaking and I don't see who would be motivated to fund such a thing.
Rust exists because it solves a real problem and places like this BT stack seem like perfect use case due to security aspects - but the security aspect also adds a lot of complexity and there are domains that really don't care about it - they just want sane modules, modern package management and fast compile times.
Go has it's own niche in the application/network programming.
Seems like modern system languages get purpose built and general purpose ones are higher up the stack.
D themselves did that, that's what I was referring to: https://dlang.org/spec/betterc.html
Also back when it launched LLVM wasn't really a thing (GCC was probably the closest thing to having a portable backend but it wasn't nearly as clear cut especially with the licensing and all that anti-extensibility attitude), and D having it's own custom backend was also an issue.
I applaud the effort but at this point I think it will never get mainstream popularity like Rust. I'm sure it's useful to people but it had it's time in the spotlight, I don't see how they get the momentum shift.
As someone who knows C and not Zig, Zig is very interesting. It has incremental compilation, in-place binary patching, the ability to use code before declaration in a file, compile-time code execution, and extremely low compile times. Rust itself doesn't have most of those.
Also, as Python illustrated, a language doesn't have to be interesting to be popular.
As Python also illustrated, a language can be opinionated and popular. I'm growing more and more convinced that useful languages have to be opinionated - opinions have to be somewhere, and if they're not in the language (where the entire community is forced to use them), then they'll have to be in individual code-bases, where you'll get a bunch of fragmentation (which I think was one of the things that killed Lisp).
Now, Zig is very imperfect - no hidden control flow/operator overloading, no REPL, and a weak type system, most notably - but it's better than C in almost every way, easier to learn than Rust, and way more conceptually scalable than FORTH (which has a more "beautiful" design).
Personally I don't find it necessary, but the proposal for REPL has been accepted: https://github.com/ziglang/zig/issues/596
REPLs do exist for C and C++.
Zig security story is hardly much better than using something like Free Pascal, with even less libraries.
In a particular toolchain not available cross-platform - not comparable to Zig having it available in the reference implementation, which is open-source and cross-platform.
> REPLs do exist for C and C++.
Hacky, nonstandard ones with limitations and altered semantics that aren't included in any of the major IDE's. Not remotely comparable to what's provided with SLIME.
Rust has all of those except in place binary patching and fast compile times.
Python was very interesting, or rather, Python is the thing in its interesting group that survived. Highly flexible scripting language with a "batteries included" library set is a very compelling sales pitch, even today. It was Perl but readable, and in this case simply being "readable" was interesting enough to cause it to win out (and also Perl's internal drama)
> As Python also illustrated, a language can be opinionated and popular.
Python's "style guide" is opinionated, but Python the language itself isn't that opinionated. Missing ++ & -- are about the only contentious "opinionated" aspects to it. You can fiddle with basically everything else however you want, though, and the language made adjustments to make that even more possible (eg, replacing the print keyword with the overridable print() function).
Critically Python's standard library didn't really get any special treatment from the language. When a language lets the standard library or builtins do things that you can't, that's when it gets really questionable.
That being said, I do think Rust's memory safety story is a game-changer for systems programming. We seem to be in a programming language boom, with lots of new and interesting languages being developed. I hope some of them iterate on the concepts that Rust has developed so we can do even better in the future! I don't think anyone involved in Rust would claim that it's the best we can do, or it solves every problem perfectly.
Despite being an ANSI specified language, the most popular libraries focuses only on SBCL. CL is like Lua where most interpreters never achieve 100% compatibility with each other. The lack of Emacs/Vim alternatives demands beginners to adhere to their dogma. Adhering to their cargo cult might be reasonable if they are the dominant language and culture. But they are not. Software engineering classes in university teaches how to make Java AbstractSingletonProxyFactoryBeans first and caml/lisp much later. Common lisp had it coming when they had their lunch eaten by Clojure. They were an old irrelevant relic that sat on their ivory tower and refused to improve or confront the status quo beyond empty words.
And it is not like the Common Lisp community lacks resources. They claim their language is used at Google via ITA software and in GOFAI through Grammarly. Even the bleeding edge of computing through Regetti. Then where are all the maintained, up to date tooling and libraries? Do a quick search and almost everything is unmaintained or half dead, with the usual generic excuse being "we are ANSI specified, libraries twenty years ago will work perfectly fine".
HN is an echo chamber for the greatness of Lisp where every commenter would worship at its church before going back to coding JS/Python/Java on Monday.
- Guy Steele, Java spec co-author
Take a look at the GitHub Octoverse https://octoverse.github.com/
FWIW Bluetooth isn't "terrible." It's pretty remarkable we can get all sorts of devices to communicate with eachother wirelessly and at low powers with pretty decent bandwidth. And now you can buy a Bluetooth stack on a chip from a variety of vendors.
The bigger issue with Bluetooth is that failure conditions are mostly an afterthought by device manufacturers, and Bluetooth is becoming a sought after feature in environments less than tolerable to failure like automotive and medical devices.
Each of those standards were burdened with lots of little features to cater for the needs (perceived or real) of each of the committee members. It's a very similar dynamic to what happened to bluetooth. A lot of 3G stuff never really got any traction. Especially once Apple and Google decided that IP connectivity was the only thing they needed from 3G/4G modems and unceremoniously declined to even bother to support such things as videocalls over 3G. Apple did Facetime instead and in the process also strangled SMS and cut out the middlemen (operators) from the revenue. Google was a bit slower but on Android a lot of 3G features were never really implemented as they were mostly redundant if you had a working internet connection, fully featured SDKs, and a modern web browser.
It's the same for a lot of early bluetooth features. Lots of stuff you can do with it; lots of vendors with half broken implementations with lots of bugs; decades of workarounds for all sorts of widely used buggy implementations; etc. It kind of works but not great and making it work great in the presence of all those not so great products is kind of hard.
Just a long way of saying that bluetooth is so convoluted and complicated is because the people that built it needed it to be that way more badly than they needed for it to be easy to implement (including by others). At this point it's so entrenched that nothing else seems to be able to displace it. I'm not even sure of people actively putting time and resources in even trying to do that. I guess you could but your product just wouldn't work with any phone or laptop in the market. Which if you make e.g. headphones is kind of a non-starter. It's Bluetooth or nothing. I wouldn't be surprised if Apple considered this at some point and then ended up not doing it. They have a history of taking good ideas and then creating proprietary but functional implementations of those ideas.
I'm personally really glad for this decision. iMessage is many times better than SMS. SMS security is a nightmare by design.
I just wish there was something better between Google and Apple, like a universal iMessage.
A lot of it is due to backwards compatibility. Bluetooth isn't simply bluetooth. There are different versions, different profiles, different codecs, and even different optional features.
Have a look at the matrix: https://www.rtings.com/headphones/learn/bluetooth-versions-c...
The two devices being paired have to figure out what version/profile/codec to use to talk to each other, and gracefully fall back to the lowest mutually supported featureset. This is a really hard problem, and the devices don't always handle it well.
Am I missing something? Or is the headline exaggerated?
We have two apps, one that communicates over many variously configured characteristics, and another that uses less characteristics but pushes/receives just as fast as I can get it to go in big bursts.
The edge cases around connect/disconnect events are the most frustrating and most difficult to reliably debug and gain confidence your implementation is robust. Oh, and don't forget that just because it works on your Samsung, doesn't mean it works on your Moto.
Assuming this new implementation is indeed much better (and not just swapping one pile of surprises for a new and shiny, but different, pile of surprises) my hat is off to the folks behind this. You get a big fat atta-whatever for making the world a better place, even if I wish it had happened 4 years ago.
And just because it works on a new Samsung doesn't mean it works on a 2 generations old one. I had to do two projects recently developing cross platform mobile apps, one had to interface with the WIFI stack - holly shit the deprecated APIs that only work on Android 10, legacy that doesn't work but is the only way to do it on Android <10, cross device inconsistency, incorrect documentation (one thing in the docs, another in the source code) etc. etc.
To be fair, iOS doesn't expose a lot of that functionality to user space apps (without special certs) but I prefer that to Android where it's technically possible but practically impossible because of the insane support matrix - it just wastes time.
I'm not doing any mobile development from now on - the entire process is just riddled with busywork and working around crap APIs, people used to complain about having to support IE, mobile fragmentation is probably 10x worse.
https://medium.com/@martijn.van.welie/making-android-ble-wor...
Has anyone here had success with a partial to Rust migration.
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.
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.
You can also have implement different associated functions based on properties of generic arguments, which is quite different in design from just attaching methods to a struct.
Also, while not in C++, in many languages, classes imply heap allocation, where structs do not.
The different allocation between structs and class objects in C# is a total head scratcher. Didn't it ever occur to the language designers that someone might want to choose how to allocate memory?
https://www.fluentcpp.com/2017/06/13/the-real-difference-bet...
Maybe it was the era that I learned C++ (which was in the 98 days), but I was taught something closer to this convention, and didn't realize until just now there was such little difference by the book. Just bundling some data together? Use a struct. Doing more? Use a class.
I still think this distinction is useful overall, because there often is more of one in many languages, but I will be more precise when speaking about C++ specifically in the future. I would also still argue the same thing overall, that is, Rust does not have what C++ calls classes. Our structs are apparently even simpler than C++ structs.
- Rust has strong support for C ABI much like C++. So you can communicate between Rust and C++ via a C ABI.
- There are projects like https://cxx.rs/ to provide higher-level bindings between the two languages.
However I suspect that template-heavy/generic-heavy code will never be well supported. This is usually not an issue for the types of things that we are trying to bind.
1. Firefox is a huge codebase. 10% of that is still quite a bit.
2. Some highly complex core parts of firefox such as the rendering engine are at least partly written in Rust.
3. The bits written in Rust are not all isolated from the bits written in C++. In places they intertwine at a function level of granularity.
- 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. (Particularly templates). You rarely need more power than what is available in Rust but if for whatever reason your project would really benefit from heavy meta-programming C++ will be better. (I think this case is rare). Rust is also catching up, but the language development, especially around generics is fairly slow (which is probably a good thing)
Macros are an option but don't have access to the same type information so often they solve different problems.
In principle Rust could replace every line of C++ code in the world. The questions of how often it would be a good idea to do so, practical to do so, is harder to say. It is promising that this bluetooth stack only needed 4 lines of unsafe though!
Since the interop is zero overhead doing piecewise migrations is certainly possible, as has been going on with firefox, and curl and discussions of doing it in linux as well. You do complicate your build system and there is a non trivial amount of work to stitch the two languages together.
Firefox have.
Everything else, including drivers post Treble, doesn't have anything to do with Linux.
I had been sticking with an old USB wireless headset for a long time because it Just Worked (tm), but even with a new battery the life wasn't really up to the modern work from home. So I chanced it with a bluetooth noise cancelling headset.
My first experience using bluetooth under Linux in probably a decade. It has been super reliable. I used the CLI tools "bluetooth_ctl", I didn't have a button to click in my i3 setup.
Not saying this rewrite isn't needed, to be clear. But I've been surprised how reliable it's been.
iOS and macOS have CoreBluetooth, Linux has BlueZ, Windows has Windows.Devices.Bluetooth and Android has android.bluetooth.
I've seen a few projects trying to fix this, like https://github.com/deviceplug/btleplug, and I hope one of them becomes production ready.
Sometimes I wonder how a technology that is so common on modern devices is still so unreliable.
It doesn't help that almost none of the ChromeOS / Android subsystems or tools have not made it to any mainstream / regular Linux. They remain Google-only products.
I wish this company doing so much Linux work would be part of some broader community. There's some reciprocal question, of how hard it would be, why haven't other people gone in & say picked out some of the, say, ChromeOS containerization tools: how much effort has the world made to use the offerings in these mono-repos? Community takes two. But it still feels incredibly weird, so against-the-grain to see such an active but non-participatory Linux user in the world.
Backkground chit-chat aside though, technically what (if anything) makes BlueZ unsuitable for Android? Why is Google on their fourth bluetooth stack (NewBlue, BlueDroid, the Fuchsia one, now this)?
There's a history of wanting BSD licenses at Android's inception. If the BSD distributions hadn't run into problems relating to legal battles at the time, Android would be built on Mach with a BSD userland rather than Linux. Additionally, there was more vendor support and drivers for the Linux kernel than Mach. Sadly, for the fledgeling enterprise that was Android, it was better to start from Linux, and use Apache/BSD style licensing and write their own userland.
Curious about your take on this. Why do you think it would be better if Android were mach kernel + BSD userland akin to Mac/IOS instead of Linux?
What legal battles were there? Wikipedia puts Android being started in 2003 [0] and then only legal battle I recall with BSD having settled in 1994 [1].
[0] https://en.wikipedia.org/wiki/Android_version_history
[1] https://en.wikipedia.org/wiki/UNIX_System_Laboratories,_Inc.....
The Glass connectivity team (of which Zach and I were a part of) actually had a few more engineers than the main Android team did, and given that connectivity was absolutely critical for our device, we had the strength to stand up to this mess and plumb its depths, and Zach was a key driver in most of the rework. Lots of our changes made it into mainline, and when Glass ended, I left Google and Zach kept up the fight, moving closer to Android proper.
BlueZ, btw, has its own problems all throughout the stack, and unfortunately suffers from political issues w.r.t. the hardware vendors.
I really really really appreciate you writing in. It feels.lile there is so little to go on, so little available to understand the weird twists & turns of how the world, the software world especially, developed. A little bit of background & insight is so refreshing to hear. Thanks again!
[1] https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/READ...
And as a person running the latest mainline kernel on their daily driver laptop--I would not want bluez running the wireless peripherals on my phone. I can barely keep a wireless keyboard attached and working on this thing... in 2021.
Firecracker however is based on Chrome OS' container solution and lives on as an OSS project run by AWS.
??? Android crash little things left and right, and have leaks just for existing.
According to dtolnay, there are only 4 lines of unsafe rust in the Rust component. It's a bit small though at the current moment in time, with 4 thousand lines. Most of the code is still C++. Note that it's "with Rust" in the headline, not "in Rust".
* 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.
Just turned it on and will be reconnecting some things to see if it helps with some of the small issues I've always had.
Rather Java-like. All we need now is a FacadeServiceManagerFactoryBuilder.
> Please see this informative video we've prepared[0].
Source: https://developer.android.com/about/versions/12/overview
On Pixel, developer options, bluetooth, enable "Gabeldorsh" if you want to live on the bleeding edge.
On the one hand, it might be interesting to try it. On the other hand, at least with the one BT device I regularly use, the current stack works flawlessly...
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 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.
You phrase this as a negative but it's overwhelmingly a positive. Imagine how difficult it'd be to write an app using the NDK in Rust if the NDK had been C++ instead. The C ABI remains by far the most portable & common target. Everything can call it.
Everything can call it, and everyone has to redo the safety work.