I wish it was mostly C++. It may be C++ in the higher power MPU world...
You put your finger on it, it is strongly dependent on how powerful the embedded platform is. This may alarm you
In that survey, C++ and C are in a dead heat. Obviously, C++ will be ahead of C next year and Python will probably be even further ahead. Shudder.
For my part, I was coding embedded for a 16KB part in C++ back in 1999, I think the compiler was Wind River. The development environment was the lap of luxury, that is, source level debugging using one of those JTAG wigglers. Operating system just coded inline, maybe about 300 lines. I had no idea this was unusual, so thanks much to whoever had the foresight to set that environment up.
The embedded world isn't like that any more. Now people think that a NUC is embedded. Now you typically run Linux, I think Linux is even running in my thermostat now. It certainly is running in all my TVs. Yes, there are still tiny embedded processors out there, particularly in toys, but it's a rapidly shrinking world, and there isn't a lot of new blood flowing into it. That may explain why you see a lot of attachment to old ways of doing things, like straight up C. And you see a lot of EEs in there, I think you know pretty much how open to change they tend to be.
I pointed out that the answer was an evasion. I believe it is apparent that the real answer to my question is "no". Is there shame in that simple answer, and if so, why? Nothing stops anybody from following up with "no, but..." However, evasion... just don't do it. The message you send is "the true answer to the question would be harmful to my argument".
In this case, "no I have never used it" could be followed up with "however I have researched the question a lot, and I have these other data points I can also offer..." But that didn't happen. So now I am left with the impression that the anti-Rust argument was just rhetoric, based on nothing more than personal prejudice.
For the record, I have not written anything in Rust, however I have researched it a fair amount, I have installed it, and I do intend to try some toy programs in it. So far I mostly like what I see, especially the rather impressive performance.
I understand that some significant parts of Firefox have been re-implemented in Rust from the original C++. And I notice that Firefox has improved a lot in recent months, particularly in terms not leaking like it used to.
Source: Every single tab and string machine, robotic arm, and conveyor system in my shop uses C, and they were made last year
Do you actually know that, or are you guessing? I think you are guessing. Here is an actual survey. That was 2012, I am sure the gap is much wider now. A quick survey of job postings on dice.com supports this assessment.
You sound sincere enough, but you really ought to admit: 1) you are guessing and 2) your sample size is one.
People have been attempting to replace C since it was conceived.
With some success. Today, C is relegated to a small number of (important) niches, like OS kernel, base libraries and... the list gets very short. Free free to add to it if you like.
Correction, Intel will provide hardware mitigation for Meltdown with its Cascade Lake 14nm parts announced last week without any details, including no release date more precise than "later this year." Benchmark wars with Epyc promise to be, well, epic.
Will a whole new architecture need to be designed?
Speaking as a layman in terms of processor engineering, it's more than a mask tweak but less than a new architecture. Given that Intel already has to tear up its entire 10nm fab line to fix the yield issues, this processor re-engineering will probably be done in parallel without delaying Ice Lake any more than it already is, but that is scant comfort. Intel already has hardware fixes for Whiskey Lake laptop processors. Chances are, Intel will just grin and bear it with their desktop and server parts. For the laptop parts, they might have sacrificed some performance for the Meltdown fix. It's going to be really hard to tell, given all the other factors involved. For desktop/server parts it would be really easy to tell, which is maybe why Intel won't bother.
Basically, this completely erases Intel's single thread advantage over AMD. I am sure that Intel will fix their speculative execution blunders in some future processor generation, I suspect it can be fixed without any slowdown, just re-engineering and maybe a bunch more transistors in the cache and dispatch logic. But by the time Intel does fix it AMD will already be shipping 7nm processors. So I don't see Intel getting back into the high end processor lead any time soon.
It's a one-two-three whammy for Intel. Almost starting to feel sorry for them. Almost.
It's not our job as software developers to save the world.
That's not quite it. We did see it as our job to save the world, at least the part of it that was within our power to save. If we weren't trying to save the world then we would never have built Linux, instead we would have used our talents to make Windows or OS/X better. This does not apply to everybody involved of course, but certainly to enough key players that if there were no sense of mission then there would be no world domination today.
All those articles point to one idiot that quit because he couldn't take criticism.
First, that is an easily falsified lie (just read the links) and second, you outed yourself as one of the toxic assholes who helped ruin the Linux kernel community's reputation. Now you are being a toxic ass here. Sucks to be you.
Linus steered clear of toxic community issues and the interviewer softballed him on it, or actually completely glossed over it. Can't see that as a good thing, it looks a lot like the ostrich defence.
I wish it was mostly C++. It may be C++ in the higher power MPU world...
You put your finger on it, it is strongly dependent on how powerful the embedded platform is. This may alarm you
In that survey, C++ and C are in a dead heat. Obviously, C++ will be ahead of C next year and Python will probably be even further ahead. Shudder.
For my part, I was coding embedded for a 16KB part in C++ back in 1999, I think the compiler was Wind River. The development environment was the lap of luxury, that is, source level debugging using one of those JTAG wigglers. Operating system just coded inline, maybe about 300 lines. I had no idea this was unusual, so thanks much to whoever had the foresight to set that environment up.
The embedded world isn't like that any more. Now people think that a NUC is embedded. Now you typically run Linux, I think Linux is even running in my thermostat now. It certainly is running in all my TVs. Yes, there are still tiny embedded processors out there, particularly in toys, but it's a rapidly shrinking world, and there isn't a lot of new blood flowing into it. That may explain why you see a lot of attachment to old ways of doing things, like straight up C. And you see a lot of EEs in there, I think you know pretty much how open to change they tend to be.
And did you write that C code?
I pointed out that the answer was an evasion. I believe it is apparent that the real answer to my question is "no". Is there shame in that simple answer, and if so, why? Nothing stops anybody from following up with "no, but..." However, evasion... just don't do it. The message you send is "the true answer to the question would be harmful to my argument".
In this case, "no I have never used it" could be followed up with "however I have researched the question a lot, and I have these other data points I can also offer..." But that didn't happen. So now I am left with the impression that the anti-Rust argument was just rhetoric, based on nothing more than personal prejudice.
For the record, I have not written anything in Rust, however I have researched it a fair amount, I have installed it, and I do intend to try some toy programs in it. So far I mostly like what I see, especially the rather impressive performance.
I understand that some significant parts of Firefox have been re-implemented in Rust from the original C++. And I notice that Firefox has improved a lot in recent months, particularly in terms not leaking like it used to.
Source: Every single tab and string machine, robotic arm, and conveyor system in my shop uses C, and they were made last year
Do you actually know that, or are you guessing? I think you are guessing. Here is an actual survey. That was 2012, I am sure the gap is much wider now. A quick survey of job postings on dice.com supports this assessment.
You sound sincere enough, but you really ought to admit: 1) you are guessing and 2) your sample size is one.
It was a yes or no question.
People have been attempting to replace C since it was conceived.
With some success. Today, C is relegated to a small number of (important) niches, like OS kernel, base libraries and... the list gets very short. Free free to add to it if you like.
Even embedded is mostly C++ now.
Have you written anything in Rust?
Mission critical systems have been written in C and they all work without idiots like him having to talk bad about it.
Spoken as someone who has never written a mission critical system, or in C.
You must be lots of fun at parties
the parody is strong in this one
He better keep a firm grip on the soap.
Correction, Intel will provide hardware mitigation for Meltdown with its Cascade Lake 14nm parts announced last week without any details, including no release date more precise than "later this year." Benchmark wars with Epyc promise to be, well, epic.
Will a whole new architecture need to be designed?
Speaking as a layman in terms of processor engineering, it's more than a mask tweak but less than a new architecture. Given that Intel already has to tear up its entire 10nm fab line to fix the yield issues, this processor re-engineering will probably be done in parallel without delaying Ice Lake any more than it already is, but that is scant comfort. Intel already has hardware fixes for Whiskey Lake laptop processors. Chances are, Intel will just grin and bear it with their desktop and server parts. For the laptop parts, they might have sacrificed some performance for the Meltdown fix. It's going to be really hard to tell, given all the other factors involved. For desktop/server parts it would be really easy to tell, which is maybe why Intel won't bother.
Basically, this completely erases Intel's single thread advantage over AMD. I am sure that Intel will fix their speculative execution blunders in some future processor generation, I suspect it can be fixed without any slowdown, just re-engineering and maybe a bunch more transistors in the cache and dispatch logic. But by the time Intel does fix it AMD will already be shipping 7nm processors. So I don't see Intel getting back into the high end processor lead any time soon.
It's a one-two-three whammy for Intel. Almost starting to feel sorry for them. Almost.
The only problem with AMD processors is they don't implement transactional memory operations.
I can understand your concern if you need this for research, but as an optimization, transactional memory has so far proved pretty underwhelming.
*Parades 1000 random people in front of you* Pick out the "nazi".
The guy wearing the the swastika?
It's not our job as software developers to save the world.
That's not quite it. We did see it as our job to save the world, at least the part of it that was within our power to save. If we weren't trying to save the world then we would never have built Linux, instead we would have used our talents to make Windows or OS/X better. This does not apply to everybody involved of course, but certainly to enough key players that if there were no sense of mission then there would be no world domination today.
should we have let Hitler use Linux?
If Hitler failed to respect the GPL then corrective action would be needed, up to and including defeating his army.
What if Hitler's use of Linux was the deciding factor in NAZI Germany winning the war?
Not tough enough, try this one: if Hitler submits a great patch, should Linus accept it?
I read them, they all [lie] concern Sarah Sharp, the looney feminist substandard kernel dev...
Your filth speaks for itself.
All those articles point to one idiot that quit because he couldn't take criticism.
First, that is an easily falsified lie (just read the links) and second, you outed yourself as one of the toxic assholes who helped ruin the Linux kernel community's reputation. Now you are being a toxic ass here. Sucks to be you.
Let me google that for you.
Linus steered clear of toxic community issues and the interviewer softballed him on it, or actually completely glossed over it. Can't see that as a good thing, it looks a lot like the ostrich defence.
See, Apple astromods are already on the job.
Apple never comes clean on anything