My impression is that most Cruise employees liked and respected Kyle a lot. I have seen external people with a negative opinion of him but I am surprised to see someone say they have never seen anyone with a positive opinion, I saw far more positive than negative.
Yes, this should not be discounted. Cruise has stunningly terrible reviews from verified employees. Based on my dataset from Blind, they were top 5% lowest ratings. Clearly morale there has been very bad, and at least since 2018.
For rust code, I have found https://github.com/japaric/cargo-call-stack to be the best available option, as it does take advantage of how Rust types are implemented in LLVM-IR to handle function pointers / dynamic dispatch a little better. An even better solution would try to use MIR type information as well to further narrow down targets of dynamic calls in a Rust-specific way, but no such tool exists that I know of.
The email gets marked as read once you click out of the email to view a different one (which I agree is unintuitive, but it is not true you have to explicitly click "mark as read").
> no one is criticizing Apple while being pragmatic [...] it is expensive and complicated for them to do that and have waterproof devices
and
> with the airpods, Apple needs to be roasted endlessly for creating time-bomb trash
I feel like every discussion of airpods and e-waste on HN totally misses the mark. The average lifespan of a pair of airpods (across all users) is probably not very different than the average lifespan of a pair of wired headphones -- people lose/replace stuff all the time, and wired headphones fail because of stress! Just because 1% of eco-conscious power users are now forced to throw away usable headphones doesn't actually make a big difference in terms of total e-waste. Also, it takes ~4000 pairs of airpods being thrown away to match the by-weight e-waste of throwing away a single 70 inch TV. Even if you are just worried about batteries, a single e-bike battery is like 2000 times larger than an airpod battery. If one was trying to minimize e-waste through by improving the reusability, Airpods just seem like totally the wrong target compared to the hundreds of much larger products with slightly worse rates of reuse / recycle
Yeah, I definitely only expect my wired earbud headphones to last 2-4 years, which sounds consistent with airpods. Often one of the ears goes in that time because the wire breaks.
Ofc I refuse to believe airpods would last 6months before I dropped/lost/etc them. But that is just me rather than a criticism :D
I don't agree that the rules for UB are virtually the same as in C. One example: if your unsafe Rust code modifies any memory address for which there exists a reference elsewhere, that is instantly UB. In C, that is not necessarily the case. https://www.youtube.com/watch?v=DG-VLezRkYQ has some good details on this.
Similarly, in Rust you have to be careful to never instantiate a value that is out-of-range for a given type (e.g. a bool with value > 1), even if you will never read or access that value before it is changed to something valid. In C this same concern does not exist since it is not insta-UB in the same way.
A brief search on Mouser seems to indicate that The AVR Xmega costs roughly 2.5 times as much as other 8 bit MCUs from Atmel with comparable amounts of flash/RAM -- are there other "selling point" on-chip perpiherals significantly contributing to that cost?
Generally a lot more stuff than the average AVR, so (IIRC) you have a multi level interrupt controller, a DMA unit, more adaptable clock / power configuration, and just more of things like UARTS and ADCs (which tended to have more features) and so on[1]. It feels more like an AVR core bolted onto something nearer to the “everything and a kitchen sink” peripheral set you get with a 32 bit ARM MCU. The projects I worked on weren’t particularly super cost sensitive though, so I’m perhaps a bit isolated from the “every cent matters” level.
(Also, you’d probably just use one of those 32 bit ARM chips nowadays).
[1] I don’t have an encyclopaedic knowledge of the AVR range and haven’t looked at in a couple of years, so I’m sure some of the advanced stuff is available on Mega models.
Rust integer overflow bugs in release mode are still much safer than C++ integer overflows -- Rust integer overflow is well-defined to wrap in release mode, whereas it is UB in C++.
That's not meaningfully safer which is why it's still a panic in debug builds. It's really just kinda worse even. You can't use it as a programmer (because it panics) and the compiler can't use it even though you've already promised (and debug mode verified) that it never happens.
If you want an add to wrap, you should use a wrapped_add, useful for angle math or whatever. If you want it to saturate, use a saturating_add, and if you want to check for overflow, use a checked_add. If I were to write a rust coding standard it would prohibit + in favor of explicitly using those functions.
MediaSourceExtensions (https://caniuse.com/mediasource)is one good example of a useful API which has been supported by roughly ~every browser for years except for safari on iPhone.
On that page it says that media source was implemented in 2014, on year before Firefox and Edge.
I guess in your world "every other browser" is Chrome. And, sure enough, there are some parts of the API that are only implemented by Chromium-only browsers, and are not implemented by either Safari or Firefox.
If you need to interact with connected peripherals from the linux environment a VM is still usually a much less productive experience. I do a lot of embedded development, and while it is often possible to do USB passthrough to connected boards, lots of things don't work the same as they do when running Linux natively, and I have never found it to be a seamless experience (on VirtualBox or VMWare)
