Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust

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.

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.

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.

I tried it and it can do a few basic things, though it’s in the early stages, apparently.

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.

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.

"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.

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.

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.

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.

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.

Bose bluetooth headphones, third party "high end" bluetooth devices... not so great. Lately it's been better, though.

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.

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.

Rust has all of those except in place binary patching and fast compile times.

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.

D themselves did that, that's what I was referring to: https://dlang.org/spec/betterc.html

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?

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.

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.

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 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

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?

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.