hra5th

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.

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

I am surprised to see the same user post

> 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

I would be surprised if bugzilla.mozzila.org has over 5 million users

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?

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

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.

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)

SpaceX pays significantly higher than NASA if you believe levels.fyi, so I think it depends what industry average you are using. If you compare to general software engineering then it certainly pays less, but that is because there are many talented engineers happy to take a pay cut to work on something they find personally motivating (space exploration).

To be clear, removing the bounds checks led to the observed performance degradation. Your statement beginning with "I am a Rust fan, but..." suggests that you might have interpreted it as the other way around

In addition to the other comment, the primary problem with malloc() in embedded environments is that you push the memory exhaustion error to runtime, rather than compile time (not memory fragmentation). A call to malloc() in a rarely-called function might not exhaust available RAM until a system has been deployed for days or weeks, which is much worse than finding out your program requires too much memory at compile time, or at boot time. While stack overflows are always possible, many embedded projects at least have static analysis tools that can (with varying degrees of soundness) calculate worst-case stack use.

For Cortex-M embedded topics, memfault's blog is simply one of the best out there. Consistently great posts even though they are written by a bunch of different authors. I go back to https://interrupt.memfault.com/blog/cortex-m-fault-debug all the time when debugging hard faults on different systems.

Even if you regularly write embedded code for Cortex-M MCUs, scroll through their list of posts and you'll find several that will teach you something new and useful.

I find it hard to imagine that a product which lasts 2 years and is smaller than a shot glass can be much of an environmental concern. I would have to throw away 10000 pairs of airpods to match the volume in a landfill of throwing out a single TV. Similarly, 10000 pairs of airpods use about as much raw materials as that single TV. This just seems like the wrong battle to fight

What ARM chip are you considering this for? Is it a Cortex M?