Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust • Hacker News Board

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

#341

Post by anonuser123456 » Thu, Apr 01, 2021, 5:01 AM UTC

seanalltogether wrote: post #28

mondoshawan wrote: post #2

I know the guy that heads up the team that did this work -- he and I spent 2+ years fighting Broadcom's old, god-awful bluetooth code. Our whole team used to play what-if games about replacing the thing while massive code dumps came in from vendors, making the task ever larger. 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!

Any insight into why Apple seems to have a much better bluetooth stack? I do a lot of BLE development that has to work cross platform, and we see constant GATT connection issues on android compared to almost none on ios.

> Any insight into why Apple seems to have a much better bluetooth stack?

This is a joke right? My M1 BT goes out to lunch several times an hour. It is literally unusable.

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

#342

Post by stjohnswarts » Thu, Apr 01, 2021, 5:06 AM UTC

fouric wrote: post #31

jmull wrote: post #22

It seems like Rust is really catching on. 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…

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.

I don't think so, too many heavy hitters are adopting rust, and rust has the advantage in adoption across the board. To beat rust you have to be at least 2-10X as desirable as rust.

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

#343

Post by zibzab » Thu, Apr 01, 2021, 5:18 AM UTC

perryizgr8 wrote: post #339

SketchySeaBeast wrote: post #34

Earlier quoted context omitted.

That's bizarre. I have a Samsung phone with Samsung Bluetooth earbuds and I've only ever experienced a single connection issue in the whole year I've owned them and they are a daily driver for me. I wonder what the difference is.

Samsung bluetooth is different from Android, and it has been much better for many years now. In fact I use Galaxy Buds with my S10 and it is an amazing seamless experience. No lag, no disconnections, great audio quality, and I don't even need to have bluetooth enabled for them to connect, just need to open the buds' case. I don't know how that last part works.

I havet not had any issues with Bluetooth on standard android or Samsung devices.

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)

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

#344

Post by perryizgr8 » Thu, Apr 01, 2021, 5:26 AM UTC

zibzab wrote: post #343

perryizgr8 wrote: post #339

Earlier quoted context omitted.

Samsung bluetooth is different from Android, and it has been much better for many years now. In fact I use Galaxy Buds with my S10 and it is an amazing seamless experience. No lag, no disconnections, great audio quality, and I don't even need to have bluetooth enabled for them to connect, just need to open the buds' case. I don't know how that last part works.

I havet not had any issues with Bluetooth on standard android or Samsung devices. 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…

I like the gear app, it has many options to customize the buds sound and gestures. How else do you propose they deliver those features and software updates to users? Keep I mind that Samsung needs to support other Android and ios phones too.

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

#345

Post by otabdeveloper4 » Thu, Apr 01, 2021, 5:26 AM UTC

johnnycerberus wrote: post #134

kllrnohj wrote: post #89

Earlier quoted context omitted.

Zig is too uninteresting to eclipse anything. It's the same problem as D's -betterC option. It's not better-enough to motivate switching away from C in places where C is still used, and it's far too stripped down & basic to attract the majority that's gone to C++, Rust, Go, ObjC, or Swift (or even "full" D). It doesn't offer much to justify switching costs. If C++11 had never happened then maybe Zig would attract the…

I share your view partially. As you said, code generation is difficult and it can get messy pretty fast, but this is the beauty of Zig, you have these features tightly packed, there is a capped number of ways for doing things. In Zig you learn how to use the wand properly, instead of being distracted by trying different sizes and colors of wands. While many languages focus on the breadth of ways of doing things, Zig…

I've been using Python since it was version 1.4.

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.

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

#346

Post by Godel_unicode » Thu, Apr 01, 2021, 5:30 AM UTC

cogman10 wrote: post #193

signal11 wrote: post #116

Earlier quoted context omitted.

I get what you're saying, but Samsung is also huge and Bluetooth is used in lots of electronics that Samsung sells -- including laptops, tablets, smart watches, TVs... or conceivably could sell, like future IoT products. 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. Inc…

I get what you are saying but they are simply in different positions. Broadcom can say "Hey, there's a bunch of work here to make this not suck" and Samsung, even if they wanted to do their own thing, realizes they too would have to go through that effort to make everything work. It wouldn't be a simple matter of just making non-sucky bluetooth, they'd have to also work with the android OS to improve the bluetooth st…

Except that's not how it works? Chip manufacturers just care about selling chips, not about being in the iPhone or being in an Android phone. It doesn't matter that some chip works in OnePlus phones, if it doesn't work in Samsung phones Samsung's not going to buy it.

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.

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

#347

Post by Godel_unicode » Thu, Apr 01, 2021, 5:36 AM UTC

mschuster91 wrote: post #272

dflock wrote: post #219

Earlier quoted context omitted.

> go and implement the technology on their own Samsung could obviously do this too, but as you say, they lack the will - and motivation.

Besides that they also lack the amount of control over the software side. Google is the entity that controls the stack, not Samsung - their responsibility ends at the kernel / HAL interface. So why should Samsung invest more than the bare minimum when they can't get anything measurable in return?

This is, of course, totally untrue. Samsung changes a ton of things about their flavor of Android, at every level of the stack.

Edit: Samsung has apparently already ripped out the Bluetooth stack and replaced it with their own - https://news.ycombinator.com/item?id=26650447

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

#348

Post by otabdeveloper4 » Thu, Apr 01, 2021, 5:38 AM UTC

ModernMech wrote: post #217

cultyyy123 wrote: post #200

Earlier quoted context omitted.

"new" and "delete" considered as bad practices. 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.

> "new" and "delete" considered as bad practices. 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…

I haven't seen a 'new' or 'delete' in C++ in 15 years. (And I have worked on teams writing custom malloc implementations and lots of other low-level things.)

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.

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

#349

Post by logicchains » Thu, Apr 01, 2021, 5:45 AM UTC

steveklabnik wrote: post #129

oriolid wrote: post #111

Earlier quoted context omitted.

What's the difference between struct and class in C++? IIRC the standard says they're the same except that members are public by default on struct and private by default on class. You could as well argue that C++ doesn't have structs. 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 alloc…

So, I dug into this a bit more, and you're right! 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…

In D there's more of a difference: https://stackoverflow.com/questions/10965577/usage-preferenc...

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

#350

Post by fulafel » Thu, Apr 01, 2021, 5:49 AM UTC

kllrnohj wrote: post #308

fouric wrote: post #248

Earlier quoted context omitted.

> Zig is too uninteresting to eclipse anything. 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 a…

> Also, as Python illustrated, a language doesn't have to be interesting to be popular. 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 ou…

"Perl but readable" and "batteries included" are true but leave out some equally important things: The explicit reference / dereference business in Perl makes handling nested data structures pretty annoying and strongly guides programmers to avoid those, which has a lot of compounding effects to structure of prgorams. Also Python embraced multiplatform early on, and had eg excellent Windows support, whereas Perl was always Unix first. Also the culture is important. Python was always beginner-friendly whereas Perl people were less likely to suffer fools gladly.