Depends if you mean "replaced" in a binary sense because C and C++ have been utterly annihilated in a lot of problem domains, particularly middleware, business logic, web front ends, application development.
All the domains where speed isn't the biggest deal and where reliability / uptime / portability / maintainability are more important. That's why languages like Java,.NET, Python, Ruby, JS have made headway.
So where C/C++ tended to be all-encompassing, they're now relegated to performance critical areas where until recently there wasn't much choice. Kernels, embedded, systems services, games. Places where performance and/or memory footprint were critical.
But even there choice is opening up. Rust in particular produces code, that is for all intents and purposes as fast as C/C++ but which tends to be safer, more portable and reliable. If you prefer to tradeoff some speed for programming niceties then you can go for Swift and Go too.
If I were writing software from scratch these days I definitely consider other languages before C++. I might reject them for reasons but C++ and C would be the bottom of the pile.
We'll judge the "open revolt" when EA outright drops the idea, or doesn't. The only way they'll do that is if they lose more money in sales thanks to loot boxes than they gain in sales thanks to loot boxes.
Personally I'm quite okay about ignoring games that pull this shit. Grind stinks, skinner box gambling stinks. But clearly this common sense hasn't permeated the mainstream consciousness or 99% of mobile games wouldn't be this way. I expect EA knows it too.
Speed isn't always the primary concern. Stability, reliability, portability, ease of development and ease of can be far more important than raw speed. This is especially true in a lot of business software and middleware that powers websites, banks etc.
Speed still remains a concern in games, video / audio capture, telemetry, databases, HMIs, industrial control, services / daemons etc. which tends to be referred to as systems programming. C and C++ still dominate in this space but I suspect Rust and Go will eat significantly into that.
Rust or Go. Rust for when you want absolute performance and reliability at the expense of programming convenience, and Go when you don't mind sacrificing a bit of performance and reliability for ease of programming convenience. Whatever Cx is doesn't stand a chance.
And the general sentiment that C or C++ is good enough if you program them right flies in the face of reality. Yeah they can be programmed right but rarely are. Rust for example shuts down classes of programming error from even happening.
This is Netflix we're talking about. If a story can be told in 8 episodes they'll make 16. And Lord of the Rings is an easy 3 seasons. So they'll make 6. It'll be thin, like butter scraped over too much bread as Bilbo would say.
Tom Bombadil will probably get one all to himself, gaily prancing around the forest and singing for 50 minutes.
The production plan for the model 3 was absurdly short and ambitious, so much so that it strains credulity that anyone thought it could be met. Those first cars are going to be rife with kinds of flaws - poor quality control, failing components, welding and other structural issues, recalls etc.
That said, detailed videos of the model 3 are appearing and it's still a stylish, well designed, technologically advanced vehicle. After tens of thousands of cars have rolled off the production line and their owners have beta tested the bugs out it, I think it will become a classic.
Perl is super terse to the point of incomprehensibility and has a dozen ways to achieve any one thing. This might suit people trying to write quick and dirty scripts but it doesn't scale and it doesn't result in maintainable code.
Once upon a time, it might have been the least painful way of writing scripts but these days we have Ruby, Python, NodeJS and a bunch of others. I'd be hard pressed to want to use Perl unless there was some material reason that every other scripting language was unsuitable.
Maybe read the contributor licence agreement and you'll understand. Or read this. If you are Intel or Qualcomm you're not going to help Canonical when they get to enjoy rights to use the code in ways that you yourself do not.
Now compare to Wayland's license which is a drop in replacement for X11. It's a no brainer why Canonical's support dried up.
I don't see how the choice of being an upstream is lost by going GPL. If the ZFS group said "we're GPL now but we're not ready to land yet, give us some time" then the kernel won't land it.
But this is Oracle we're talking about. I doubt they would GPL something because in their minds they'd lose control of it and allow the competition to exploit their code. After all, that's what Oracle has done itself to competitors like Red Hat. Aside from that, assuming they did GPL it, then it would immediately fork because Oracle suck at stewarding open source projects.
HOWEVER++ they are talking diesels. DIESEL ENGINES ARE ACTUALLY GREENHOUSE NEGATIVE! WTF you say?
The danger from diesel is albedo. Soot in ice and snow from causes the ground to reflect less solar radiation and therefore retain more heat. Diesel exhaust emits a lot of soot and is therefore a major contributor to this process.
Unity and Mir were an attempt to own a large chunk of the display stack. Made in preparation for when Ubuntu for tablets, phones came out, Ubuntu could release software under a proprietary Canonical licence while their competitors were forced to release under an onerous GPLv3 or pay Canonical not to do so. That's primarily why Intel pulled their support from Mir because their contributions benefited Canonical more than themselves. It's also why Canonical had to take on the burden of making things like GTK, QT work with their software because nobody else in open source was going to help them. And then the mobile plans went nowhere.
So these projects eventually became a money pit and the sensible thing was to dump them. The really sensible thing would have been to not start them in the first place, but I guess we should be thankful again that Ubuntu Linux is converging again instead of diverging.
Who'd have thought that an addictive substance could be addictive. E-cigarettes might be "better" than regular cigarettes but that's damning with faint praise.
The XBox 360 and PS3 both had PowerPC cores which had poor branch prediction. So yes you'd inline code if for no other reason than to avoid a branch. If I had to loop 10 times and call a function each times, I might be tempted to unwind the loop and inline the function. But as with all things you would balance inlining against cache consumption. I expect some console code is horrifically hacky with lines moved into odd places or other weirdness simply to eke out an extra frame from the hardware.
I don't know why you think virtualising a console to be "easy". The problem is not emulating the instruction set but getting the timing of both the CPU and GPU correct. The GPU is especially hard since the game is going to feed it broken shaders and use GL extensions that have to be emulated with the new GPU. And mapping the firmware calls (for audio, video, controls, achievments, copy protection, storage, chat / music, resolution negotiation) to their equivalents in the new console, or stubs. I expect also that some libraries such as Unreal, Havok, PhysX etc. are so prevalent in games that emulators will have special cases for when they encounter that code.
Is that over the duration of the entire lifespan over the vehicle, within the first year, or what?
It should be very obvious to all but the most blinkered that the model 3 has and will continue to have a lot of issues with quality control until they sort their production out and discover how their car breaks in the field. That is going to take a few years and the chances are the vehicle will be reliable after that.
As the adage goes, never buy version one of anything. This is true for software and should be double underlined and highlighted for cars.
No, it's not "whatever hysteria has been whipped up". It is clear that the US government received intelligence that Kaspersky was used to spy on government agencies and now they've cancelled all use of it. As have other companies. It's a violation of trust, plain and simple and Kaspersky gets to reap what they sowed.
If you want an analogy, it's like learning your doctor groped another patient. Even if you are not sure if you might be groped yourself, the trust has already been violated and it's time to find a new doctor.
Maybe US AV companies do what you say. But that "you too" argument doesn't negate Kaspersky's actions or that people should leave this potential attack vector running on their computer.
Using software from your main adversary is profoundly bad security. The same is true when Russia uses US software.
Antivirus software is second only to the operating system in terms of privilege and therefore makes an ideal attack vector. I bet most AV software is more than capable of maliciously stealing files, keystrokes, or planting a trojan if they were so directed.
Slashdot Mirror
I'm starting to wonder if my Digital Noise Reduction tattoo was a bad idea in hindsight.
I'm not sure who'd want to use Edge given that it's a bit crap but yay?
All the domains where speed isn't the biggest deal and where reliability / uptime / portability / maintainability are more important. That's why languages like Java, .NET, Python, Ruby, JS have made headway.
So where C/C++ tended to be all-encompassing, they're now relegated to performance critical areas where until recently there wasn't much choice. Kernels, embedded, systems services, games. Places where performance and/or memory footprint were critical.
But even there choice is opening up. Rust in particular produces code, that is for all intents and purposes as fast as C/C++ but which tends to be safer, more portable and reliable. If you prefer to tradeoff some speed for programming niceties then you can go for Swift and Go too.
If I were writing software from scratch these days I definitely consider other languages before C++. I might reject them for reasons but C++ and C would be the bottom of the pile.
Your contribution to the human race has been gratefully accepted by Charles Darwin.
Personally I'm quite okay about ignoring games that pull this shit. Grind stinks, skinner box gambling stinks. But clearly this common sense hasn't permeated the mainstream consciousness or 99% of mobile games wouldn't be this way. I expect EA knows it too.
Browsers have to deal with random shit and not crash. By definition. Otherwise they are exploitable in some form or another.
Speed still remains a concern in games, video / audio capture, telemetry, databases, HMIs, industrial control, services / daemons etc. which tends to be referred to as systems programming. C and C++ still dominate in this space but I suspect Rust and Go will eat significantly into that.
And the general sentiment that C or C++ is good enough if you program them right flies in the face of reality. Yeah they can be programmed right but rarely are. Rust for example shuts down classes of programming error from even happening.
Tom Bombadil will probably get one all to himself, gaily prancing around the forest and singing for 50 minutes.
I've been insightful the whole time, thanks for asking.
That said, detailed videos of the model 3 are appearing and it's still a stylish, well designed, technologically advanced vehicle. After tens of thousands of cars have rolled off the production line and their owners have beta tested the bugs out it, I think it will become a classic.
Once upon a time, it might have been the least painful way of writing scripts but these days we have Ruby, Python, NodeJS and a bunch of others. I'd be hard pressed to want to use Perl unless there was some material reason that every other scripting language was unsuitable.
Now compare to Wayland's license which is a drop in replacement for X11. It's a no brainer why Canonical's support dried up.
But this is Oracle we're talking about. I doubt they would GPL something because in their minds they'd lose control of it and allow the competition to exploit their code. After all, that's what Oracle has done itself to competitors like Red Hat. Aside from that, assuming they did GPL it, then it would immediately fork because Oracle suck at stewarding open source projects.
HOWEVER++ they are talking diesels. DIESEL ENGINES ARE ACTUALLY GREENHOUSE NEGATIVE! WTF you say?
The danger from diesel is albedo. Soot in ice and snow from causes the ground to reflect less solar radiation and therefore retain more heat. Diesel exhaust emits a lot of soot and is therefore a major contributor to this process.
So these projects eventually became a money pit and the sensible thing was to dump them. The really sensible thing would have been to not start them in the first place, but I guess we should be thankful again that Ubuntu Linux is converging again instead of diverging.
Who'd have thought that an addictive substance could be addictive. E-cigarettes might be "better" than regular cigarettes but that's damning with faint praise.
I don't know why you think virtualising a console to be "easy". The problem is not emulating the instruction set but getting the timing of both the CPU and GPU correct. The GPU is especially hard since the game is going to feed it broken shaders and use GL extensions that have to be emulated with the new GPU. And mapping the firmware calls (for audio, video, controls, achievments, copy protection, storage, chat / music, resolution negotiation) to their equivalents in the new console, or stubs. I expect also that some libraries such as Unreal, Havok, PhysX etc. are so prevalent in games that emulators will have special cases for when they encounter that code.
I think the phone display is pretty neat looking. That would be the selling point for me assuming I hadn't bought a phone just recently.
It should be very obvious to all but the most blinkered that the model 3 has and will continue to have a lot of issues with quality control until they sort their production out and discover how their car breaks in the field. That is going to take a few years and the chances are the vehicle will be reliable after that.
As the adage goes, never buy version one of anything. This is true for software and should be double underlined and highlighted for cars.
If you want an analogy, it's like learning your doctor groped another patient. Even if you are not sure if you might be groped yourself, the trust has already been violated and it's time to find a new doctor.
It's not about threat, it's about violation of trust.
Then either you're profoundly naive, or a shill.
Maybe US AV companies do what you say. But that "you too" argument doesn't negate Kaspersky's actions or that people should leave this potential attack vector running on their computer.
Antivirus software is second only to the operating system in terms of privilege and therefore makes an ideal attack vector. I bet most AV software is more than capable of maliciously stealing files, keystrokes, or planting a trojan if they were so directed.