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

#111

Post by oriolid » Wed, Mar 31, 2021, 4:51 PM UTC

steveklabnik wrote: post #98

bluGill wrote: post #78

Earlier quoted context omitted.

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.

I mean, C++ has the "class" and "struct" keywords for a reason. (they are very similar, Rust structs are closer to "struct" than "class" though) There are a lot more things going on with C++ classes than syntax sugar for functions that have access to "this." Also, while not in C++, in many languages, classes imply heap allocation, where structs do not.

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 allocate memory?

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

#112

Post by kevincox » Wed, Mar 31, 2021, 4:51 PM UTC

zozbot234 wrote: post #79

kevincox wrote: post #52

Earlier quoted context omitted.

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.

There are generics and dependent types. But these are still gaining features and not nearly as powerful as templates and SFINAE. (but way easier to understand)

Macros are an option but don't have access to the same type information so often they solve different problems.

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

#113

Post by zozbot234 » Wed, Mar 31, 2021, 4:51 PM UTC

dagmx wrote: post #102

moldavi wrote: post #80

Earlier quoted context omitted.

I'd imagine given another language (e.g. Python), they'd learn a lot faster and be a lot more prodictive throughout the course.

Possibly but Python is a completely different level of programming too. 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

The Rust book as currently written assumes that the user has some programming experience. That's mainly b/c there hasn't been much of any experimentation in teaching Rust as a first time programming language. Although obviously it's been done for C++ and even C, so it ought to be quite doable, if perhaps with a bit of a "learn programming the hard way" style.

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

#114

Post by burnte » Wed, Mar 31, 2021, 4:51 PM UTC

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!

It's almost impossible to be worse than the existing Bluewooth stack. IT's the single biggest problem I have with Google phones and it's shameful it took this long to fix.

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

#115

Post by ModernMech » Wed, Mar 31, 2021, 4:51 PM UTC

dagmx wrote: post #102

moldavi wrote: post #80

Earlier quoted context omitted.

I'd imagine given another language (e.g. Python), they'd learn a lot faster and be a lot more prodictive throughout the course.

Possibly but Python is a completely different level of programming too. 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 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 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.

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

#116

Post by signal11 » Wed, Mar 31, 2021, 4:51 PM UTC

cogman10 wrote: post #92

est31 wrote: post #83

Earlier quoted context omitted.

> The buying power that Apple has for designing in a particular chip is much bigger than any individual Android manufacturer (even Samsung) 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?

I'd imagine lots of reasons. Apple has the hardware guys to design whatever chip they need. They also have a mountain of reserve capital (Something like $1 trillion I believe?). Further, Apple's closed ecosystem means that if you want them to sell them your hardware you have to conform to their standards. With Samsung and android, it's a different story. There are many android vendors and the people producing the Blu…

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.

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.

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

#117

Post by Mindwipe » Wed, Mar 31, 2021, 4:55 PM UTC

tschellenbach wrote: post #101

I'm always curious why bluetooth is such a terrible piece of technology. Did anyone write blogposts analyzing what went wrong?

It's pretty simple really. It tries to do a lot of complicated things, and it's underspecified so it's possible to have compliant devices that behave wildly differently between vendors. It also rarely breaks compatibility so there's a lot of cruft for ancient devices.

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

#118

Post by nicoburns » Wed, Mar 31, 2021, 4:55 PM UTC

kllrnohj wrote: post #89

fouric wrote: post #31

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

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…

> It's not better-enough to motivate switching away from C in places where C is still used

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.

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

#119

Post by shadowgovt » Wed, Mar 31, 2021, 4:56 PM UTC

oriolid wrote: post #99

est31 wrote: post #83

Earlier quoted context omitted.

> The buying power that Apple has for designing in a particular chip is much bigger than any individual Android manufacturer (even Samsung) 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?

It's because Samsung can get away with selling total garbage. I work on an audio-related app, and a huge majority of the hacks in the app to work around bugs in phones are for different Samsung models. Still more than half of our users keep buying them.

This, but slightly revised: it's because Samsung is in the market of selling cheap hardware. Apple sells luxury products and part of their value-add is leverage with their vendors.

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.

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

#120

Post by jillesvangurp » Wed, Mar 31, 2021, 4:56 PM UTC

nahuel0x wrote: post #61

Fuchsia network stack is also being rewritten from Go to Rust [1] and it follows a functional core/imperative shell pattern, something very unusual in network stacks [2]: [1] https://fuchsia.dev/fuchsia-src/contribute/contributing_to_n... [2] https://cs.opensource.google/fuchsia/fuchsia/+/master:src/co...

Interesting; makes you wonder about the potential for code sharing between that and Android or even linux as well. The Linux kernel developers are open to allowing some Rust usage for things like drivers at this point. So the time seems right for this kind of thing. I guess there is also some decent code from e.g. redox os that might be adapted. Licensing (MIT) should not be an obstacle for this as far as I understand it. Likewise Fuchsia also uses GPL2 compatible licenses (MIT, Apache2, BSD). So, there's some potential to avoid reinventing a few wheels across these platforms.

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.