Since Android is Linux, will this become available to all Linux users?
Very unlikely, the Android driver infrastructure is quite different from Linux.
Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust
321–330 of 393 posts
Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust
#322This is great news. Hopefully it fixes a lot of the jank that I've always experienced with Android Bluetooth. I don't think I've ever had a smooth experience - even with a supposedly flagship device (Pixel 4a!) I've encountered all of the following problems: * Devices getting stuck at max volume (thankfully not headphones) * Devices getting stuck at really low volumes * Devices randomly switching between absolute vol…
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.
Generally, Samsung's bluetooth implementation has worked better than any other Android I've used. On top of that, Bluetooth seems to work better if both devices are from the same vendor
Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust
#323Earlier quoted context omitted.
Zig isn’t quite production ready.
And it doesn't have memory safety. Zig is really fun and it is excellent for small wasm modules, but until it gets memory safety it will never be a Rust alternative.
Safety is a matter of degree, not an absolute. Unsafe Rust isn't safe. Not to mention, safe Zig isn't unsafe. And, if you want a lot of memory safety -- more than Rust in some ways -- you can use something like Javascript.
Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust
#324Earlier quoted context omitted.
I use operator overloading in C++ all the time, you seem to be looking at it from a data science perspective, but other fields use math also, such as gamedev.
I would have imagined that in game dev you prototype first with a high level language and then you would write the math code. How much of game dev is actually math code, aside from critical components like rendering, physics, etc.?
3D rotation is maths. How many 3D game objects don't rotate anything in gameplay?
Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust
#325Earlier 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…
Yeah from the Android platform side it would be weird to build chips. For products like the Pixel phone though, that would be a great place to innovate. And realistically, Google needs to get into the custom chip game sooner rather than later... GCE needs to start competing with Amazon's Graviton ARM processors. The sooner you get the expertise and talent to churn out chips (and maybe even a fab or two?), the better.…
Aren’t they already with TPUs?
Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust
#326Earlier 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…
> Android has never been about driving the hardware narrative Apple has been building its own hardware from the beginning, but still also uses Broadcom chips.
>Apple has been building its own hardware from the beginning
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.
Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust
#327Earlier 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…
> 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…
A good example of what happens when the language is not sufficiently opinionated is the modern-day JavaScript/Node.js ecosystem.
Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust
#328Earlier quoted context omitted.
I use operator overloading in C++ all the time, you seem to be looking at it from a data science perspective, but other fields use math also, such as gamedev.
I would have imagined that in game dev you prototype first with a high level language and then you would write the math code. How much of game dev is actually math code, aside from critical components like rendering, physics, etc.?
Consider the fact that QuakeC had a native vector datatype back in the day, despite the fact that all rendering and physics was done in native C code.
Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust
#329Earlier 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…
Yeah from the Android platform side it would be weird to build chips. For products like the Pixel phone though, that would be a great place to innovate. And realistically, Google needs to get into the custom chip game sooner rather than later... GCE needs to start competing with Amazon's Graviton ARM processors. The sooner you get the expertise and talent to churn out chips (and maybe even a fab or two?), the better.…
Google doesn't have the volume on its first-party hardware to drive something like this yet & they would never start with BLE chips. Additionally, there's some really good vendors out of China already challenging BCOM & QCOM FWIW, which further complicates the "build it yourself" narrative (look at the Pixel buds which have an AirPods-like experience running a Chinese BLE chip for the buds which other Western vendors weren't able to match).
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.
Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust
#330Earlier quoted context omitted.
The issue is not "structs" v. "classes" per se, it's things like inheritance, vtables and RTTI (also other C++ features like templates and exceptions), that need special ABI support in C++ for which there is no Rust-side equivalent. (meanwhile Rust traits are quite different from anything in C++, although they're used similarly)
None of those things are required for a class. I'll admit they are all useful at time, but all are abused.
It largely depends on the definition of "class" you're using. You'll raise some eyebrows calling structs that can't support implementation inheritance "classes".
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.