Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

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

    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...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    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.

    Comment


    • #3
      Originally posted by cl333r View Post
      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?

      Comment


      • #4
        Originally posted by cl333r View Post
        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.

        Comment


        • #5
          Maybe based on this:

          Comment


          • #6
            will this serve the same pupose as rusts rayon ?

            Comment


            • #7
              Originally posted by kpedersen View Post

              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.

              Comment


              • #8
                Originally posted by RahulSundaram View Post

                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.
                Last edited by cl333r; 20 June 2019, 08:50 AM.

                Comment


                • #9
                  Originally posted by RahulSundaram View Post
                  How is that different from unsafe Rust?
                  Rust is a steaming pile of shit, and this doesn't want to be.

                  Comment


                  • #10
                    Originally posted by cl333r View Post

                    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
                    Last edited by kpedersen; 20 June 2019, 03:02 PM.

                    Comment

                    Working...
                    X