And even alibaba's own qwen3.6-plus is $1.95, so it's kinda easy to come to a conclusion that alibaba (nor anyone else) is really interested in hosting that model.

And don't get me wrong, I fully agree with you, qwen3.6 27b is an amazing model. I run it on my own hardware and every day I'm constantly surprised with what it can zero shot.

Might be easier to chuck it over the fence and let other providers handle it as it'll run in almost any commercial grade card?

Also speculating, but I wonder if it might also create a bit of a pricing problem relative to Gemini flashlight depending on serving cost and quality of outputs?

As a comparison, despite being SotA for their size, the smallest qwen models on openrouter (27b and 35b) are not at all worth using, as there are way bigger and better models for less oricemon a per token basis

However protobuf is ridiculously interchangeable and there are serializers for every language. So you can get your interfaces fleshed out early in a project without having to worry that someone will have a hard time ingesting it later on.

Yes it's a pain how an empty array is a valid instance of every message type, but at least the fields that you remember to send are strongly typed. And field optionality gives you a fighting chance that your software can still speak to the unit that hasn't been updated in the field for the last five years.

On the embedded side, nanopb has worked well for us. I'm not missing having to hand maintain ad-hoc command parsers on the embedded side, nor working around quirks and bugs of those parsers on the desktop side

But why do you think we live in a world that likes to hide recursion? Why is it common for tree data structure APIs to expose visitors, rather than expecting you write your own recursive depth/breadth-first tree traversal?

Is there something innate in human nature that makes recursion less comprehensible than looping? In my career I've met many programmers who don't 'do' recursion, but none who are scared of loops.

And to me the weird thing about it is, looping is just a specialized form of recursion, so if you can wrap your head around a for loop it means you already understand tail call recursion.

In fact, by not doing so they are making a subtle implicit statement that it is uninteresting to consider actually attempting to execute these snippets.

The third paragraph of the "P.S" of the article (you have to press submit to see it) is the one that really gives the game away.

It comfortably surpasses the capacity of most of the Actel aerospace FPGAs that I tend to work with.

And I think it's so "micro" that the majority of all of Lattice's FPGAs wouldn't fit it either.

And the Lattice ECP5 is advertised with 85k LUTs, which would seemingly limit its use to edification as instantiating this softcore would consume the entire chip. For any other purpose if you wanted a chip that was only a CPU, you would buy a CPU.

They have weird "trick" geometry that means you can move the rotor to many different angles (tens, hundreds) with far fewer stator windings.

The cost of this is really low power and efficincy if you just want to spin them.

Just could the two sets of coils be optimized for their own purposes?

Just guessing, does ZF mostly put out induction motors, and they need to make them look less unfashionable so that people choose them for new designs?

And agreeing with the other reply, nobody jumps up and down with joy when choosing an error handling crate. You pick the right poison for the job and try not to shed a tear for code beauty as you add in error handling.

I'd guess the physical CPU package of an i386 would cope just fine with the few (hundreds?) of gates toggling in that small loop.

I wonder if it might be possible to do on a modern FPGA, if you artifically create some unstable circuit and pack deliberately it in a corner of the die?

There's probably some AVX512 concoction that would be the closest equivalent on a modern X64. There's probably an easy experiment -- if that concoction makes CPU freq drop and also makes whole-package thermals drop, it /could/ be due to localized die heating.

First and most important, the title claims these are safety-critical rules, but the conclusion says that they are only being used on mission-critical projects. I get the feeling that there might have been some late-change copyediting done here, as the content is far too generalizing to be taken seriously in any specific safety critical context, and hopefully the author would have known that.

* Agree that many safety-critical coding standards are a grab-bag of sometimes dubiously-valuable rules.

* Agree with the implication that stylistic guidelines are almost totally worthless, and may distract reviews from their core task of finding functional errors.

* The document states that manual review of large cases may be infeasible, but I have never worked on a project that didn't mandate it. Drudgery goes hand-in-hand with safety-critical, and mindnumbing close review is an accepted element of this.

* Agree that less rules is good, but the author doesn't justify why 10 rules is the best. Unfortunately this is a field where correctness trumps easiness or simplicity, and any class of error with unacceptable risk to life/limb must be prevented. Thus any ruleset cannot justify itself simply because it is small.

* In fact, there are many wordings in this document that are generally-unacceptable because they are admitting incompleteness in the general case (and therefore unsuitability for any safety-critical purpose), such as "Although such a small set of rules cannot be all-encompassing" or "In return, it should be possible to demonstrate more convincingly that critical software will work as intended"

commentaries on specific rules:

* rule 4: "No function should be longer than what can be printed on a single sheet of paper". In my experience, readability is not always improved by limiting function length. The main goal of safety-critical be correct (and hopefully be obviously so). Sometimes splitting up code is harmful to this. (also this is actually a stylistic rule of the kind rejected in the 2nd paragraph of the document.)

* rule 5: In the safety-critical domain, defensive checks and "assertions" are usually considered at low-level-design. It's generally unacceptable for a coder to "just" insert defensive behaviours into the implementation, because all such behaviours must be analyzed for correctness. I don't disagree with the idea behind this rules, but a coding standard is the wrong place for it.

Or the same but for testing some verilog/vhdl CPU implemetation in a simulator?

Or since it's only 500SLOC, maybe it's just for fun!

Otherwise I agree with you, that library code should not fail/crash/exit(1) just because of some judgement about recoverability, and out to clean up after itself before passing control back to the caller. If the user wants to fix some ENOSPC deep in my library by shelling out to "rm -rf /" and then trying again, that's fine by me, and this should be reflected in the API.

The flow of responsibilities is strictly hierarchical. If Boeing specified to to their outsourcers that the software should have read from two sensors, then the outsourcer would be 'in the wrong' if they didn't implement that. With a strict interpretation of the rules Boeing doesn't necessarily have to check their outsourcer's work (In Safety-Critical the outsourcer has not just a commercial but also a moral obligation to perform all actions with competence)... But at the same time, because Boeing retains overall responsibility for its products no matter who it subcontracts to, it would be a mistake to not double check the work.

So to at least some extent (at least with moral-tinted glasses), it doesn't actually matter whether or not the fault was introduced by the subcontractor or not. Boeing is responsibility either way, Answering your question only tells us if the subcontractor is also at fault.

It's very important to note that in the Aerospace world, the subcontractor's moral duty only requires them to do exactly what they're told to do (assuming that the subcontractor was only reponsible for software design and not systems design). If Boeing told them to use one sensor, then the subcontractor has done nothing wrong if they failed to notice that this was fundamentally unsafe.

I think it's possible to accidentally use that straw man to justify fears when looking at embedded rust.. But as other people have pointed out in this thread, just because rusty interrupt handlers look weird doesn't work any better or worse than one written in C.

I think there is another side to this coin though. IMO there are too many embedded shops that overlook reliable 3rd-party code in favour of spending man-hours growing their own code from seed instead. Or if not that you spend days debugging some greybeard coworker's "Oh I think I wrote something like that 25 years ago for a PDP-11, I'll just email it to you.."

But to be honest I don't really disagree all that much -- As much as the embedded world needs to keep up with the times, there's no way that the level of audit required for a reliable embedded project just can keep up with how quickly crates are being changed.

> 2. A big departure from how things used to be done in this world.

Sometimes I cringe too when takes a massive server board with 9999GB of RAM and a 4g modem and calls it "embedded" just because they screwed it to the side of a helicopter... But if the root question is "will rust be viable on a puny AVR" I hope that the answer is definitely yes.

One example in my head individual strings that need to be constructed dynamically but live for the lifetime of the application (better to leak it with Box::leak or lazy_static! than pollute all code with lifetimes)

Another is writing in lifetimes for single purpose objects that live on the stack and might only ever get passed by ref into a single function and then get destroyed soon after.

Lifetimes are super important in rust and are a core part of the language, but in such degenerate cases they take up a lot of programmer effort for little benefit. In my head a "automatic" solution such as GC /could/ have a home in the language. Perhaps this would make rust a slightly better fit for really complex monolithic GUI apps (word processing, spreadsheets, CAD) where full GC would be performance-onerous but data lifetimes would be too complex for rust's strictly ordered lifetime concept