Intel Developing "Data Parallel C++" As Part Of OneAPI Initiative

[phoronix]

Phoronix: Intel Developing "Data Parallel C++" As Part Of OneAPI Initiative

Intel announced an interesting development in their oneAPI initiative: they are developing a new programming language/dialect...

http://www.phoronix.com/scan.php?pag...a-Parallel-Cpp

[cl333r]

This isn't a systems programming language apparently, I was hoping for a brand new C++ with no backwards compatibility, basically Rust without a borrow checker.

[RahulSundaram]

This isn't a systems programming language apparently, I was hoping for a brand new C++ with no backwards compatibility, basically Rust without a borrow checker.

How is that different from unsafe Rust?

[kpedersen]

I was hoping for a brand new C++ with no backwards compatibility.

What sort of backwards compatibility are you talking about? auto_ptr? C++ is not like Python, there is very little cruft that needs to be removed once it is deprecated. I don't think this would have much value really.

Or do you mean compatibility against C code? This would be a very bad idea to remove.

[lucasbekker]

Maybe based on this:
https://ispc.github.io/

[GunpowaderGuy]

will this serve the same pupose as rusts rayon ?

[cl333r]

What sort of backwards compatibility are you talking about? auto_ptr? C++ is not like Python, there is very little cruft that needs to be removed once it is deprecated. I don't think this would have much value really.

Or do you mean compatibility against C code? This would be a very bad idea to remove.

I think I mean legacy solutions and starting from a clean sheet. Currently pretty much everything "new" in C++ must be compatible with the old.

[cl333r]

How is that different from unsafe Rust?

That? I don't know what you're referring to.
Unsafe Rust - I think you misunderstand the concept, it's just about putting unsafe {..} in rare cases around code blocks to relax certain things but nobody is programming in "unsafe rust" because it doesn't exist, it's just a Rust feature for a narrow set of things. You still have the borrow checker, lifetimes etc. If you don't know what I mean - try creating a circular dependency in "unsafe Rust" (e.g. a DOM tree) and using that.

Here's a quote:
It’s important to understand that unsafe doesn’t turn off the borrow checker or disable any other of Rust’s safety checks: if you use a reference in unsafe code, it will still be checked. The unsafe keyword only gives you access to these four features that are then not checked by the compiler for memory safety. You’ll still get some degree of safety inside of an unsafe block.

[Weasel]

How is that different from unsafe Rust?

Rust is a steaming pile of shit, and this doesn't want to be.

[kpedersen]

I think I mean legacy solutions and starting from a clean sheet..

When it comes to just high-level C++, I kinda agree, but it does still need perfect compatibility with C (and thus the actual OS). Without this, a developer will be spending their time writing pointless language bindings or fixing rotting ones instead of actually solving their original problem.
This is part of the reason why C++ is so successful; it certainly isn't the "pleasantness" of the language! It is the fact that C++ (and I suppose Objective-C) are the only languages that can consume C code directly.

Go is slightly closer than languages like C# or Java (Rust, not so much). Unfortunately, because of this I predict that C++ will outlive them all and I will still be stuck writing my software in C++ forever... ugh

That said, it does also mean Objective-C (still pretty nasty to write) will come back and outlive Swift... you just wait and see