I see this view very often being pulled into the debate but demand is not only driven through a (low) cost. Demand obviously cannot grow infinitely so the actual question IMO is when and how do we reach the market saturation point.
First hypothesis is that ~all SWEs will remain employed (demand will proportionally rise with the lower cost of development).
Second hypothesis is some % of SWEs will loose their jobs - over-subscription of SWE roles (lower cost of development will drive the demand but not such that the market will be able to keep all those ~30M SWEs employed).
Third hypothesis is that we will see number of SWEs growing beyond ~30M - under-subscription of SWE roles (demand will be so high and development cost so low that we will enter the era of hyperinflation in software production).
At this point, I am inclined to believe that the second hypothesis is the most likely one.
What alternatives there are that exist and can replace ROS? I imagine that not all companies are using ROS, however, I'm not in that field exactly so I don't know. I always thought that the quality of that code is mediocre at best.
Most companies in production are inventing their own purpose-built systems and not open-sourcing them. High speed control loops usually use some form of real-time OS, AI-forward robots are starting to use fused CUDA kernels.
It's not rust per se. It's a human trait. People make uneducated assumptions about the topics all of the time, and it's completely normal since your have to bootstrap yourself somehow to be able to grow further. It's impossible to know everything. And it's also a difficult situation because you do have to arrive to some conclusion. I do think, though, that in this particular case, assumptions made are a little bit all over the place and the tone is overconfident.
M4 is 38 TOPS at INT8 precision whereas SpacemiT K3 is 60 TOPS at INT4 precision so at best they would be equal in "AI" performance but they are not because the rest of the K3 chip is much less capable than M4 (as I would expect).
E.g. M4 total system memory bandwidth is 120GB/s whereas K4 is 51GB/s, single core memory bandwidth is 100-120GB/s vs ~30GB/s. M4 has 10 CPU cores and neural engine with 16 cores whereas K3 has 8 CPU cores and 8 "AI" cores, K3 clock frequency is almost half the clock frequency in M4 etc. etc.
But anyway thanks for sharing, always good to learn about new hardware.
I remember taking down some notes wrt SiFive P870 specs, comparing them to x86_64, and reaching the same conclusion. Narrower core width (4-wide vs 8-wide), lower clock frequency (peaks at 3GHz) and no turbo (?), limited support for vector execution (128-bit vs 512-bit), limited L1 bandwidth (1x 128-bit load/cycle?), limited FP compute (2x 128-bit vs 2x 512-bit), load queue is also inconveniently small with 48 entries (affecting already limited load bandwidth), unclear system memory bandwidth and how it scales wrt the number of cores (L3 contention) although for the latter they seem to use what AMD is doing (exclusive L3 cache per chiplet).
Not firmware sure, but if one boots the Pi from the software that's just as bare metal as anything else. And the age of the GCC version is completely irrelevant to whether something is bare metal.
Pi runs Linux. That's software. Not bare metal. Bare metal is when you're running without OS, or at light abstraction such as RTOS. Bare metal is normally associated with chips without MMU. Pi runs SoC.
I didn't say that GCC version is relevant to bare metal definition, I said it's 15 years old. And when you try to draw conclusions, and derive strong opinion, based on the codegen output but you're using 15 year old toolchain, and btw pretty shitty CPU core, something isn't quite right. This article is just a good display of never ending cargo-cult programming myths.
Let someone from the Redox team go read [1], [2], and [3]. If they still insist on keeping their position then ... well. The industry is being redefined as we speak and everyone doing the push-back are pushing against themselves really.
“Our approach is harness-first engineering: instead of reading every line of agent-generated code, invest in automated checks that can tell us with high confidence, in seconds, whether the code is correct. “
that’s literally what The whole industry has been doing for decades, and spoiler: you still need to review code! it just gives you confidence that you didn’t miss anything.
Also, without understanding the code, it’s difficult to see its failure modes, and how it should be tested accordingly.
So you read the three-part series of blogs that are packed in details in 3 minutes after I shared the link and put yourself into a position of entitled opinion and calling my position a silly take? Sure thing.
Their profile generally comes up here on HN very often with Dunning-Kruger effect like comments so it makes me believe it is no AI. AI would do a better analysis, for the better or worse.
Implementing a Redis and Kafka rewrite (in Rust) but with workload-aware and self-balancing JIT-like engine deployed at Datadog-scale is no fluff. You obviously have no idea what you're talking about.
> The industry is being redefined as we speak and everyone doing the push-back are pushing against themselves really.
No, they’re pushing back against a world full of even more mass surveillance, corporate oligarchy, mass unemployment, wanton spam, and global warming. It is absolutely in your personal best interest to hate AI.
6500 EUR net in Berlin/Munich would equate to ~140k EUR gross. For a FAANG salary, considering that startups pay these figures for similar expertise, I would expect more. What level is that if you don't mind sharing?
Intermediate lvl, not Amazon.
And indeed I’ve also observed this to be the case, too startups pay such base salaries (eg Gitlab and Neon did) for similar lvl. But there aren’t too many such openings.
I agree with some of your points, they make sense, but China has been building combustion engines too, for a very long time which is why I don't think that sidestepping the technology with EV was the main reason for their success
They had been trying to for decades but were never able to make even remotely competitive combustion engines. Nothing that would get VW, Toyota or Ford in trouble. The article I posted is sadly paywalled, but it's basically about exactly that.
What does it mean "remotely competitive combustion engines"?
China has been building ICEs for decades, that's for sure, and if they had not been anywhere to remotely competitive people wouldn't be buying them and therefore OEMs wouldn't be producing them, no? But they do. And still do.
The last notable example is [1] twin turbo-charged 4.0 V8 from GWM reportedly delivering 450kW and 800Nm of torque. You can't build such an engine without the very deep expertise in materials, mechanics, chemistry, and everything it takes to manufacture such a beast.
GWM builds traditional gasoline and diesel engines too but then you have other similar OEMs like Geely, BYD, MG, Chery which have been doing the same.
And then you find out that China builds their own diesel engines too but for heavy machinery like trucks, vessels, tractors, ... [2]
So, I see no evidence that they are not capable in manufacturing ICEs. Quite the contrary. Reason why we don't see it in European or American markets, or have not so far, is of a different kind and not competitiveness.
Their wikipedia lists many engine models, all of which seem to be either small industrial engines or engines for range extenders only. This does not sound like a portfolio that can compete with the legacy OEMs but it does explain how they ship so many units.
I see this view very often being pulled into the debate but demand is not only driven through a (low) cost. Demand obviously cannot grow infinitely so the actual question IMO is when and how do we reach the market saturation point.
First hypothesis is that ~all SWEs will remain employed (demand will proportionally rise with the lower cost of development).
Second hypothesis is some % of SWEs will loose their jobs - over-subscription of SWE roles (lower cost of development will drive the demand but not such that the market will be able to keep all those ~30M SWEs employed).
Third hypothesis is that we will see number of SWEs growing beyond ~30M - under-subscription of SWE roles (demand will be so high and development cost so low that we will enter the era of hyperinflation in software production).
At this point, I am inclined to believe that the second hypothesis is the most likely one.
reply