SIMD, GPGPU, GUI, embedded platforms, iOS, Android, UWP, COM, certified compilers, ...
Regardless, yes, that’s the whole point. What’s been accepted is https://doc.rust-lang.org/nightly/core/arch/index.html , that is, intrinsics that map 1-1 to the vendor APIs. (I belive this is the same in C++ but not my area of specialty so I may be wrong)
https://doc.rust-lang.org/nightly/core/simd/index.html is the first level up the abstraction chain; this hasn’t gone through an RFC process yet, but will eventually happen.
On top of that, you have stuff like https://crates.io/crates/faster , which is very high level. Looks like they need to fix up the README... but you get the idea.
Also, autovectorization has existed this entire time. This stuff is for when that falls down.
Most compilers do a reasonable job with auto-vectorization, and if more is needed, there are instrisics.
No need to write straight Assembly.
Are the intrinsics standard? If so, what version of the standard were they in? How good is compiler support for them?
They are not portable between CPU architectures either way
For reference, C got real alignment support in C11 and C++ in C++17. Without this, even starting on SIMD is risky.
That said, you can go really far with a good C++ math library like Eigen which has singe vectorization in the operations themselves.
For example,
https://www.iar.com/iar-embedded-workbench/certified-tools-f...
Maybe someone else can jump in.
However, I can tell you that in general proprietary compilers for embedded devices make Visual C++ feel state of the art, let alone when compared with gcc or clang.
Many of them are stuck in partial support for C99 or C++98 (e.g. TI), with no clear roadmap of future improvements.
No one can replace it, but everyone has to try.
Ada also had a shot, I think, but they screwed it up with no C compatibility and expensive SDKs - or something. For some reason, Ada is just not perceived as "cool". It actually seems like a pretty good language!
Joe Duffy mentioned on his Rustconf talk that Windows devs even with Midori running in front of them, it was still a very hard sell for them to psychology accept it as doable.
The problem with Ada was basically expensive SDK, Pascal-like syntax and not being part of OS SDKs.
Only systems programming languages that are bundled with OS SDKs survive on the market, others either get a niche (Ada - high integrity systems) or fade into oblivion/maintenance (Modula-2, Delphi, ...).
The main reason being, companies already payed for OS SDK or gotten it for free with the OS.
Any other language must add a very worthwhile set of benefits for them to look beyond the SDK and possible toolchain integration issues.
There were GC'ed operating systems in the 80s. The point is not this. It's writing applications where you can maximize your CPU usage.
If it's a game, it means that you want to write your code so that the highest number of objects are visible on screen and are being updated on each tick. If its's a multimedia software, you want to be able to run most sounds / videos in parallel at the same time. If it's an interpreter, you want to have the highest instructions-per-second count.
etc etc... the point is not to have "good enough" performance, it never has been as soon as you use non-trivial apps. It's always "how fast can it be" / "how far can I push it", and an implicit language-level GC puts limits to this.
The last generations of Oberon OS had support for video editing applications as an example.
There are real time GC applications in production being used to control weapons systems, including live targeting and soft real time factory automation systems.
Regarding D, using @nogc or -vgc allows the developer to control when the GC works, it at all. What the language lacks is a GC that can match real-time GCs used in soft real time systems.
Hmm. To Rust, this would seem to say "get bundled or die".
In your view, is it enough to be a free download?
At very least, there needs to exist painless interoperability with the SDK toolchain, debugging tools, IDE, platform libraries.
Every piece of the puzzle that doesn't quite work like the SDK tools, means additional development/debugging effort.
Naturally the big question is always if the added benefit of using language X outside the expected workflow outweighs the extra development costs.
Just look at C++, it was on the path of being widely adopted by desktop OSes, every C compiler vendor was adding support for it.
Then BSD and Linux large scale adoption happened with GNU manifesto favouring C as the language to write portable software, Java and .NET came into the scene.
Microsoft was probably the only major OS vendor still caring about it, until LLVM happened and the wind started blowing again with C++11.
The embedded space is still an area where C++ is hardly seen, with a few conference talks last year discussing on how to advocate for it.
Now all major C compilers are written in C++, but had Microsoft focused only on .NET or LLVM never happened, and history would probably followed another path.
For instanced I used it here to write Ada programs for the C API of the Pebble smartwatch: https://blog.adacore.com/make-with-ada-formal-proof-on-my-wr...
Which is actually partially true... the long tail of programming languages today is very, very big. There's probably 10-50x more programmers now than there were back in 1995. The programming world can probably sustain 10-20 mainstream languages these days, if not more.
Don't know about that. But only yesterday afternoon I spent like 2 hours writing a Perl script to heavy lift some Unix file work, Which I factored would take a week at-least to do in any other language.
Perl is still largely a very useful language without any replacements. So are awk and sed.
Web development world seems to have moved on to something else now.
I'm guessing you're more familiar with Perl, because I personally find it hard to believe that Perl by itself is an order of magnitude more efficient to write than Python or Ruby.
Ruby is ok. But Perl is million times a better language than Python.
Python is an extremely overrated language.
To comment briefly on the learning curve, the trade off is basically, C++ is easier to get started, but harder on the high end. Rust is a bit harder for C people to get started, but then the high end is much easier. Rust’s curve is flatter, in a sense.
Oh and also: learning one will certainly help you learn the other in many cases. I advocate learning many languages :)
This week I’m visiting a ~700 person company in London that’s moving away from C and towards Rust. They’re not doing a Big Rewrite, obviously, so they still have quite a bit of C too. They chose Rust over C++ though. It always depends!
Especially the Rust borrow checker will make you mad in the first place, and then teach you something about memory management you will be able to use in C++. It really improves your mental model in places you didn't expect.
Rust is “move by default, move always means memcpy (and they often can be elided), no move constructors,” to (possibly too) succinctly describe it.
You should check out Rust, it aims to replace C++ and do a better job in memory management, and developer experience in general (cross-platform compatibility, package management, etc)