Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

android.googlesource.com

Post reply on HN
Print view View original

241–250 of 393 posts

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

#241

Post by geraneum »

gameswithgo wrote: post #54
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.

I think Zig could end up being much more popular for domains where Rust's safety and correctness features are less important. Something like a bluetooth stack is exactly where Rust is ideal though imho. Some for crypto libs.

I believe the number of domains which benefit from Rust’s safety features combined with its runtime performance are vast. IoT, hardware drivers, autonomous systems, embedded systems, (cars, drones) infrastructure, etc. I would choose Rust in these scenarios if I have choice.

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.

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

#242

Post by Infinitesimus »

kungito wrote: post #226
mondoshawan wrote: post #174

Earlier quoted context omitted.

I can't speak to this directly because of numerous reasons, chiefly among them being that I don't get to make those decisions. Standard disclaimer follows: I rejoined in the last two years, what follows are my opinions, these opinions are my own, blah blah. 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 w…

Google throws money at problems which don't generate revenue all the time. I feel like all it takes is someone inside Google with enough leverage to push it through without the thing having to make business sense

That could work but the other side of that coin is: if it stops making financial sense Google will do the responsible thing and end it. "Your BT hardware's software is no longer supported" will do more damage to the problem they're trying to solve here

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

#243

Post by mrpippy »

cptskippy wrote: post #229
qbasic_forever wrote: post #161

Earlier quoted context omitted.

Serious question, why doesn't Google build its own bluetooth & BLE chips? Please put some competition on Broadcoam and the like and either push them entirely out of the market (good riddance), or force them to step up their game.

> Serious question, why doesn't Google build its own bluetooth & BLE chips? 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 usual…

> In fact I think with Bluetooth 4 the file transfer profile just establishes an adhoc WiFi network.

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.

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

#244

Post by kllrnohj »

nicoburns wrote: post #118
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…

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

But why wouldn't I use Rust in those scenarios, which gives me even more safety & compile-time bug checking? Zig isn't actually a small or simple language, after all, that's just marketing bullshit. Manual, mostly unassisted memory management isn't simple, and compile time evaluation & reflection isn't small. It keeps making claims about being simpler because it doesn't have macros or metaprogramming, but that's incredibly deceptive at best since it does have compile-time code generation (aka, metaprogramming). It's how Zig's printf function works! https://ziglang.org/documentation/0.7.1/#Case-Study-printf-i...

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?

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

#245

Post by est31 »

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…

C++ has to have structs because it wants to be (mostly) backwards compatible with C. I think that's the main reason they exist in C++.

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

#246

Post by dilippkumar »

shadowgovt wrote: post #119
oriolid wrote: post #99

Earlier quoted context omitted.

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…

My social network orbits around several people who experience apple’s testing rigor- and the stories I’ve heard aligns with the parent comment.

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)

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

#247

Post by rigrassm »

Just found on my Note 10+ in Developer Options was a setting labeled "Enable Gabeldorsh - Enables the Bluetooth Gabeldorsh feature stack".

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.

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

#248

Post by fouric »

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…

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

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

#249

Post by anthk »

ampdepolymerase wrote: post #124
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.

Common Lisp had itself and its community to blame. Their dependency managers were decades behind other scripting languages. Poor defaults for build tooling. Even now building a statically-linked binary is an exercise in frustration. 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 lac…

You forgot Scheme.

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

#250

Post by ModernMech »

cultyyy123 wrote: post #232
ModernMech wrote: post #217

Earlier quoted context omitted.

> "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 have worked with decades old codebases. I use up-to-date compiler where you get to use smart pointers and all the Modern C++ features. It's your fault if you not teach them how to upgrade the compiler. There is zero risk when compiling C++98 with C++11. 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 drivi…

Ok. I'll take your advice and give it the consideration which it's due. Thanks for taking the time out of your day to create a throwaway account just to tell me how to do my job. Cheers.
Post reply on HN