379 karma · joined May 25, 2015
https://www.cnet.com/tech/services-and-software/digital-cont...
It's a legal requirement for drones above 250g to broadcast not only their position but also the position of the operator and their identification number.
As he mentioned the current situation with return position impl trait + 'a was surprising even to some of the core rustc developers so it's not like they intended for it to be like that.
Soldered on RAM and expensive upgrades are defacto planned obsolescence.
There's no meaningful way to limit access to any of this when it's purely software based and the hardware required to run it are commodities.
It's nothing like chemical weapons were the reagents can be controlled as they're hard to come by or synthesise in a amateur lab.
This is a pretty negative and unfortunate take on rust that I cannot recognize after having spent the past 2 years professionally writing backend rust. I did write c++ before that so it's likely that it takes some experience with the pain of an unhelpful (and in some cases downright hostile) to fully understand and appreciate the so called "yelling" rust does.
From my perspective every lifetime complaint the compiler has is a deeply appreciated hint that not only saves you countless hours of debugging down the line but also makes me feel confident/safe in the code which you never could achieve in a c++ codebase without making defensive copies everywhere.
Being able to lend/borrow data without fear truely is rust's greatest strength and something people coming from GC languages have a hard time appreciating.
It's frankly ridiculous what people consider acceptable behavior from apple.
Another aspect to this is that it board repairs could be made significantly easier if companies bothered designing boards with proper test points and expected values documented in a diagnostics manual. Just take a look at how old school oscilloscopes and other test equipment was designed with not only full schematics but well defined diagnosis procedures.
A lot of what you request can be achieved by using Vulkan wrappers that simplifies these things without making the driver API more magic/implicit and regress back to the dx9/openGL style API's that mantle/vulkan/dx12 was made in opposition of.
Unfortunately it's an industry with a lot of stubborn old people so I don't see any major changes happening until they've retired but I'm willing to bet that async is going to revolutionize embedded development. Being able to await interrupts and doing efficient cooperative scheduling while writing straight forward code is a massive QoL improvement which is what embassy is enabling: https://embassy.dev/
What exactly is your problem with them? The chips are fairly capable and the newest ones have transitioned to RiscV in case you're unaware. Sure I wouldn't use them for anything serious realtime but that rarely requires wifi/ble anyway so not sure why you'd pick an ESP to begin with for that :)
I work as an embedded software engineer who's tasked with ripping all the terrible arduino code out of a fairly large codebase where I work and the arduino core libraries are the lowest quality code I've ever had the displeasure of working with.
It's full of awful decisions everywhere in the arduino core libraries such as defining min and max macros when they're writing C++ code which in turn results in STL includes blowing up if you attempt to use something simple and safe as std::array.
I could go on for days about all the terrible decisions that reeks to high heavens of always taking the path of least resistance... </rant>