Announcement

Collapse
No announcement yet.

Experimenting Is Underway For Rust Code Within Mesa

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

  • #11
    Originally posted by mdedetrich View Post
    Now lets waste another 20 pages of Phoronix armchair "experts" making a massive s**tstorm out of Rust's non issues even though they clearly have no real experience in the language.

    ...

    Ontop of this, Zig doesn't have as many guarantees that Rust's borrow checker can prove and picking another another language to use is a very expensive decision and taking this into account Rust brings the most value on the table.
    Frankly, one doesn't necessarily need to have "real experience" with one language to validly criticize it, as long you've done your research on it. You yourself perfectly demonstrate this by claiming Rust's superiority over Zig (where I'm assuming it is extremely unlikely you've had any real and complex project done in Zig yet). You're not wrong here, Rust *is* superior, but it proves the point that such criticism is still valid.

    On the topic of Rust: Rust is definitely filling a needed gap and is a better alternative to C and C++ in many projects. The problem I have is more with fanboys than with Rust. Fanboys who want to see Rust universally everywhere, evangelizing Rust is the perfect fit for everything, for all libraries, for all applications, for all use-cases, for servers and for the desktop, for the kernel, for drivers, for the web, for microcontrollers, for all markets and for all industry sectors. Nope. I will go as far as to say Rust is the better alternative to C and C++ for the larger part / majority of codebases, but not for everything, not unconditionally and not always. Fanboys are being stupid and ignorant trying to preach or to "force" Rust onto areas for which it has not yet matured up to. This isn't always a problem of the language itself. Sometimes it is the language, sometimes it is its libraries, sometime it is tool support (and here I don't just mean compilers), sometimes it is the collective knowledge and/or expertise, sometimes it is interoperability, sometimes it is existing standards etc.. And frankly, anybody who ignores these factors is showing they have not yet had enough professional experience in some applicable areas and sectors, so they shouldn't be the ones downtalking others. Which is the reason I've taken the "audacity", oh my dear Rust Lords save me from my crimes, to speak my mind in a total of two forum threads in the past.

    Comment


    • #12
      Originally posted by kpedersen View Post
      I absolutely "reserve judgement" on Karol but no developer is infallible in their decisions. This is what peer review is for.
      It's called "peer review", not "random person on the internet review", for a reason.

      Comment


      • #13
        If memory management is a problem, Rust might be the perfect solution. Frankly I think they should rewrite the network stack, kernel, and browsers using Rust. Pretty much any part of the system that keeps getting exploited due to memory leaks/overflow bugs should get rewritten to eliminate those flaws.

        Comment


        • #14
          I might take a jab at using it for the GLSL frontend. That thing is so easy to crash lol.

          Comment


          • #15
            Originally posted by DMJC View Post
            If memory management is a problem, Rust might be the perfect solution. Frankly I think they should rewrite the network stack, kernel, and browsers using Rust. Pretty much any part of the system that keeps getting exploited due to memory leaks/overflow bugs should get rewritten to eliminate those flaws.
            Because of the giant boon increased memory safety is, I think people too often overlook Rust’s other major features. Particularly it’s inherent love for concurrency/parallel execution. I don’t know how multithreaded Mesa currently is, but rewriting parts of it in Rust could bring better performance on higher core cpus. Obviously architecture of the driver comes first (multi threaded isn’t always the answer) but if they do decide to add threads, Rust would make it extremely easy.

            Comment


            • #16
              Originally posted by jbranso View Post
              I'm starting to wonder if Zig is a better C alternative? Sorry to start the resulting flame-war....
              No flame-war, people have an issue with this name and with it's debugger called Heil.

              Comment


              • #17
                Originally posted by ultimA View Post

                Frankly, one doesn't necessarily need to have "real experience" with one language to validly criticize it, as long you've done your research on it. You yourself perfectly demonstrate this by claiming Rust's superiority over Zig (where I'm assuming it is extremely unlikely you've had any real and complex project done in Zig yet). You're not wrong here, Rust *is* superior, but it proves the point that such criticism is still valid.
                Your kind of really stretching the barrel when it comes to making an apt comparison. The people that spent 20 pages arguing in Rust where arguing over nitpicking that they themselves had no clue about, which is different from realizing generic points about a language by reading about it.

                i.e. people were claiming ridiculously that the borrow checker runs at runtime, there is a world of difference between that and making a surface level argument

                Originally posted by ultimA View Post
                On the topic of Rust: Rust is definitely filling a needed gap and is a better alternative to C and C++ in many projects. The problem I have is more with fanboys than with Rust. Fanboys who want to see Rust universally everywhere, evangelizing Rust is the perfect fit for everything, for all libraries, for all applications, for all use-cases, for servers and for the desktop, for the kernel, for drivers, for the web, for microcontrollers, for all markets and for all industry sectors. Nope. I will go as far as to say Rust is the better alternative to C and C++ for the larger part / majority of codebases, but not for everything, not unconditionally and not always. Fanboys are being stupid and ignorant trying to preach or to "force" Rust onto areas for which it has not yet matured up to. This isn't always a problem of the language itself. Sometimes it is the language, sometimes it is its libraries, sometime it is tool support (and here I don't just mean compilers), sometimes it is the collective knowledge and/or expertise, sometimes it is interoperability, sometimes it is existing standards etc.. And frankly, anybody who ignores these factors is showing they have not yet had enough professional experience in some applicable areas and sectors, so they shouldn't be the ones downtalking others. Which is the reason I've taken the "audacity", oh my dear Rust Lords save me from my crimes, to speak my mind in a total of two forum threads in the past.
                Rusts design means that it will handle every use case C does, the only issue with embedded right now is that LLVM doesn't target all architectures (this is now fixed with a GCC backend that rust has) and being able to handle failure of memory allocation explicitly as a value (this is also being worked on right now).

                I mean essentially you are complaining that a language that is designed to replace C shouldn't be replacing C in all areas because?????

                Also theirs a reason there is a lot of evangelism over Rust, it effectively solved one of the most biggest and critical problems with low level software (i.e. memory management) with almost no downsides (i.e. no GC) so yeah don't be surprised that people are going to push for it. Then you take into account how easy concurrency is in Rust compared to C/C++ and its not hard to see why people are enthusiastic about it.
                Last edited by mdedetrich; 18 September 2021, 03:49 AM.

                Comment


                • #18
                  Originally posted by jbranso View Post
                  I'm starting to wonder if Zig is a better C alternative? Sorry to start the resulting flame-war....
                  It might very well be, Rust was really designed as a C++ alternative more than a C alternative. But Rust has behind it momentum and money, Zig is still essentially a hobby language. Which is why they are well advised to use Rust rather than Zig.

                  Comment


                  • #19
                    Originally posted by mdedetrich View Post
                    Your kind of really stretching the barrel when it comes to making an apt comparison. The people that spent 20 pages arguing in Rust where arguing over nitpicking that they themselves had no clue about, which is different from realizing generic points about a language by reading about it.
                    Haha says the Rust fanboy who didn't know that RefCell doesn't do reference counting.

                    Originally posted by mdedetrich View Post
                    (bla-bla-bla...) Then you take into account how easy concurrency is in Rust compared to C/C++ and its not hard to see why people are enthusiastic about it.
                    Indeed, Rust 1.0 has been around for 6 years already and here's the full list of AAA games that dumped C++ in favor of Rust thanks to its awesome concurrency:

                    Comment


                    • #20
                      Originally posted by cl333r View Post

                      Haha says the Rust fanboy who didn't know that RefCell doesn't do reference counting.
                      It does, just in a different context (i.e. not borrow checking). I also linked the source code of RefCell which demonstrates this. You conveniently ignored this part in the other thread (i.e. https://www.phoronix.com/forums/foru...70#post1278570)

                      Originally posted by cl333r View Post
                      Indeed, Rust 1.0 has been around for 6 years already and here's the full list of AAA games that dumped C++ in favor of Rust thanks to its awesome concurrency:
                      It takes like 20 years for languages to displace what is already existing, especially if you take into account massive game engines that have been written in C++. Also C++, unlike C, has a frequently breaking ABI which makes it hard to incrementally use Rust in such projects (which is why you see Rust disrupting C more than C++).

                      The biggest issue with game engines is a lot of them is WYSIWYG and a huge amount of that tooling is built ontop of their C++ engines, its not just pure code and so recreating this with Rust is a huge effort.
                      Last edited by mdedetrich; 18 September 2021, 04:36 AM.

                      Comment

                      Working...
                      X