Why is that so unbelievable? TypeScript isn't JavaScript, and while they have the same runtime, compiled TypeScript often don't look like how you'd solve the same problem in vanilla JS, where you'd leverage the dynamic typing rather than trying to work around it.
The TS code looks very different from the JS code (which obviously is the point), but given that, not hard to imagine they have different runtime characteristics, especially for people who don't understand the inside and outs of JavaScript itself, and have only learned TypeScript.
One thing to consider, is that with JavaScript you put it in a .js file, point a HTML page at it, and that's it.
TypeScript uses a ton more than that, which would impact the amount of energy usage too, not to mention everything running the package registries and what not. Not sure if this is why the difference is bigger, as I haven't read the paper myself :)
But if you do, please do share what you find out about their methodology.
This image comes from running the different versions of the benchmark games programs. Some of the difference between languages may actually be just algorithmic differences, and also those programs are in general not representative of most of the software that runs.
That, and also because rust compiler is a very good guardrail & feedback mechanism for AI. I made 3 little tools that I use for myself without knowing how to write a single rust line myself.
I can see that a reality but I am more comfortable using Golang as the language compared to rust given its fast compile times and I have found it to be much more easier to create no-dependices/fewer-dependencies project plus even though I wouldn't consider myself a master in golang, maybe mediocre, I feel much easier playing with golang than rust.
The resource consumption b/w rust and golang would be pretty minimal to figure out actually for most use cases imho.
As a computer engineer I usually copy reference schematics and board layouts from datasheets the vendors offers. 95% of my hardware problems can be solved with it.
Learning KiCad took me a few evenings with YT videos (greetings to Phil!).
Soldering needs much more exercise. Soldering QFN with a stencil, paste and oven (or only pre-heater) can only be learned by failing many times.
Having a huge stock of good components (sorted nicely with PartsDB!) lowers the barrier for starting projects dramatically.
But as always: the better your gear gets - the more fun it becomes.
Even as a professional EE working on high speed digital and mixed signal designs (smartphones and motherboards), I used reference designs all the time, for almost every major part in a design. We had to rip up the schematics to fit our needs and follow manufacturer routing guidelines rather than copying the layout wholesale, but unless simulations told us otherwise we followed them religiously. When I started I was surprised how much of the industry is just doing the tedious work of footprint verification and PCB routing after copying existing designs and using calculators like the Saturn toolkit.
The exception was cutting edge motherboards that had to be released alongside a new Intel chipset but that project had at least a dozen engineers working in shifts.
"The intelligence agency, called the Bundesnachrichtendienst (BND) discovered that some calls on Air Force One were unencrypted and it was able to tap into radio frequencies that were used for those calls, according to the book, "
No hacking or deployment of listening devices, just passive listening. Unless you have other sources?
RISC-V is eating the "low power low performance"-niche alive right now. ARM-licensed microcontrollers (like STM32C0) cannot keep up with this price class. That's a huge business.
Have a look at WCH. If you are used to the ST-HAL style you get that stuff running within a hour. They stuff works will fully opensourced compilers.
They basically can shoot (not only throwing!) entire frozen chicken cadavers into engines with zero damage.
The only way they managed break the entire engine was to place little explosives on the turbine wings. Even that didn't cause a fatal disintegration of the jet engine.
Somewhere on YT there's a super entertaining video from a test facility.
Well first, the linked article was regarding a weather balloon that impacted the windscreen, not the engine, and it did cause an injury to the flight crew. Here are pictures of the bloody, glass-shard filled flight deck. https://www.facebook.com/aviation247/posts/n17327-united-air... So the hazard is real.
Now back to your uninformed comment. I do certification testing of jet engines, and we most certainly DO NOT test jet engines against the ingestion of airborne electronics.
I have personally loaded and fired the five barrel bird gun at General Electric’s Peebles Test operation many times over the years. We use a range of birds and bird simulators, but none of them are ever chickens, and none of them are frozen.
There is not any requirement for zero engine damage. Little sparrows will do no damage. Ducks and geese cause extensive damage every single time. Extensive engine damage is permitted so long that the engine shuts down without causing catastrophic damage to the airframe. The specific damage that must be prevented, per 14 cfr 33.75, is below. Any other damage is acceptable.
(i) Non-containment of high-energy debris;
(ii) Concentration of toxic products in the engine bleed air intended for the cabin sufficient to incapacitate crew or passengers;
(iii) Significant thrust in the opposite direction to that commanded by the pilot;
(iv) Uncontrolled fire;
(v) Failure of the engine mount system leading to inadvertent engine separation;
(vi) Release of the propeller by the engine, if applicable; and
Thanks for the very informative post on airline engine testing. One of the quickest upvotes ever. Never knew the details on the range of birds fired and actual damage allowables.
Couple follow on questions. What are the test conditions like? Is the test basically a static air test with a fixed engine and a 500 mph duck / goose carcass striking an operating engine? Or do they put it in a wind tunnel to simulate high speed wind forces also?
Also, what's the method of actually firing and accelerating a duck / goose carcass up to airline speeds for impact. Did this a bit for NASA impact testing, and we tended to use peel away sabot rounds to throw bricks at objects.
Also, borders a bit on a Monty Python joke, yet is there a regulation duck / goose? They can vary pretty wildly in size / weight. 5lb, 10lb, 20lb? Are they firing all the way up airline cruise speeds (500-600 mph? or just take off / landing runway issues?
Finally, being in the industry, any idea on what's been going on with the engines peeling off airplane wings, like that Louisville, Kentucky cargo plane? That seems like a rather drastic failure mode, since apparently there were cracks in the mounting and people just weren't checking?
Yeah, and pico baloons are extremely tiny, often at 10 grams or less, comprising some very thin plastic, some thin wire and tiny PCBs - this is also how they can fly so high for so long.
Lost of types of hail will be much heavier and harder on impact for example.
Can it mine bitcoins or run worms?
reply