Fish Shell Outlines Their Successes & Challenges Going From C++ To Rust

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • darcagn
    Phoronix Member
    • May 2021
    • 66

    #31
    Originally posted by Akiko View Post
    Yes, C++ is unsafe, especially if you have a fucking skill issue. And this is on purpose, because at the same time C++ is more flexible than Rust. Don't believe me? Implement a fast double linked list example and we speak again.
    If you don't have a skill issue, just use unsafe {} for it. You'll get the same speed, flexibility, and (lack of) memory safety guarantees as C++ for that code block, but gain the advantage of isolating the "unsafety" to one place within your application. Bonus points for putting the abstraction in a separate crate so that it can be re-used and have more eyes on it. Which is the principle of why there are fast linked lists using unsafe {} provided to users in the standard library.

    If you do have a skill issue, you can't do the fast implementation in C++ anyway, so then use the Rust smart pointers and you'll still end up with a more performant resulting application than one that would have been written in a higher level language.

    This makes Rust a better solution than C++ or other languages for me. But I'm not here telling you that you have to use it.

    Originally posted by Akiko View Post
    But Rust is memory safe! Uhm, just search github for "memory leak rust example" (or similar). It is something like a contest now on how to find the funniest and most simple way to show how Rust fucks up.
    I think "safe", "unsafe", "memory safety" are poor terms to describe the concept they're intended to describe. But a memory leak is not intended to fit under the umbrella of what Rust calls memory safety. The Rust standard library includes several functions that can be called from safe contexts that purposely leak memory, like mem::forget or mem::leak. You don't need to search github for a memory leak example, it's not some secret thing.

    Originally posted by Akiko View Post
    Please stop repeating the "memory safe" stuff, while the application links to the whole c-runtime, gcc-stubs and other c-based libs. This is annoying. There... the flame war can start now.
    Well, if someone claims that the resulting application is 100% memory safe they're an idiot. But the developers writing the application still have a greater insight to where errors or vulnerabilities may lie compared to using C++.

    Comment

    • Akiko
      Phoronix Member
      • Sep 2017
      • 69

      #32
      Originally posted by skeevy420 View Post
      Akiko
      That really highlights the downsides of using Rust and Cargo. Pull in the wrong Crate and you bring in all these dependencies that defeat the purpose of all of Rust's safeties. It'd be nice if there was a C-free, Unsafe-free, version of Crates.io.
      Yeah, exactly that. CPAN was flooded with ad- and malware and bad actors. Same is true for pypi. npm had the left-pad moment. And now the islands owning the *.io toplevel domains changing ownership and will drop the top-level domain. Isn't that lovely? Oh, not to mention that even on crates.io bad actors are already showing some activity. Convenience is the enemy of security.

      Originally posted by DumbFsck View Post
      From your specific POV, what are some of your general opinions on Zig?

      I like C so much more than C++, and from the outside it really does seem like Rust is trying to be a more functional, "better" C++, while Zig just wants to improve C ergonomics.

      Also, have you taken a glance at C3? I read a few interesting bits about the language, but haven't even opened the documentation even if to see subtitles...
      I prefer Zig over Rust and C, and I consider it the modern successor to C. I wish the kernel lead maintainers would have considered Zig instead of Rust. Zig is a drop-in compiler for C and C++, and yes, because of being a frontend of llvm/clang you really are 100% source-code compatible. I switched a lot of my C++ projects from cmake to build.zig files. Now I can easily build arm linux, bsd, windows and x86 linux, bsd and windows binaries in one shot. And the binaries have statically linked c++-runtimes, only requiring the c-runtime, or compile em fully statically linked. On linux the c-runtime gets dropped and is replaced by direct syscalls into the kernel. The guy who created Zig really knows how compiling/linking/building works. In short: I really like Zig. No, I don't know C3. I usually do not have the time to dig into everything. Currently I try to create an E frontend for GCC (yepp, AmigaE).​

      Originally posted by cl333r View Post
      I'm not akiko but to me the largest issue with Zig is it has no concept of interfaces, so if you want something that remotely resembles an interface you use "anytype" which sucks big time.
      Well, it is exactly the same with C. So no problem here. Btw, you can simulate interfaces to a satisfying degree using opaque pointers/types or anytype. The Zig stdlib does exactly that. This is absolutely fine if you come from the C ecosystem.

      Originally posted by darcagn View Post
      Rust people who claim Rust is perfect are stupid and anti-Rust people who try to hold Rust to the bar of perfection are also stupid.
      Yeah, exactly that, hence my first rule "there is a matching tool for every specific problem". I often get the feeling, that a lot of the developers out there are "I have a hammer and everything looks like a nail now" people, this is so stupid.

      Originally posted by darcagn View Post
      If you don't have a skill issue, just use unsafe {} for it. You'll get the same speed, flexibility, and (lack of) memory safety guarantees as C++ for that code block, but gain the advantage of isolating the "unsafety" to one place within your application. Bonus points for putting the abstraction in a separate crate so that it can be re-used and have more eyes on it. Which is the principle of why there are fast linked lists using unsafe {} provided to users in the standard library.

      If you do have a skill issue, you can't do the fast implementation in C++ anyway, so then use the Rust smart pointers and you'll still end up with a more performant resulting application than one that would have been written in a higher level language.

      This makes Rust a better solution than C++ or other languages for me. But I'm not here telling you that you have to use it.

      I think "safe", "unsafe", "memory safety" are poor terms to describe the concept they're intended to describe. But a memory leak is not intended to fit under the umbrella of what Rust calls memory safety. The Rust standard library includes several functions that can be called from safe contexts that purposely leak memory, like mem::forget or mem::leak. You don't need to search github for a memory leak example, it's not some secret thing.​
      Don't get me wrong. I'm on your side. I freely admit, that I have a Rust skill issue, but not a C/C++ skill issue. I started C and C++ with DICE and SAS/C, that was long before C++98 was a thing. And with Rust I started some years ago. For me it is fine if people rewrite stuff in Rust, I do the same. But I really dislike the hype and a lot of the misconceptions out there, and this is true for all languages. Though, I really dislike the ugly Rust syntax, but I like Perl. It comes down to personal taste, I guess.

      Originally posted by darcagn View Post

      Well, if someone claims that the resulting application is 100% memory safe they're an idiot. But the developers writing the application still have a greater insight to where errors or vulnerabilities may lie compared to using C++.
      ​Amen, brother...
      Last edited by Akiko; 29 December 2024, 04:25 PM.

      Comment

      • Jumbotron
        Senior Member
        • Jul 2015
        • 1246

        #33
        Originally posted by TheMightyBuzzard View Post

        lowflyer asked for specifics, you gave nothing even remotely resembling such. You didn't even give broad generalizations, only wholly unsubstantiated conclusions. As a result, I award you zero points and declare him the winner.
        < chuckle >….then I bow to your superior intellect

        Comment

        • unwind-protect
          Senior Member
          • Dec 2022
          • 143

          #34
          Speaking of speed, did they publish any benchmarks comparing the two implementations?

          (I know there isn't one cutoff point where everything is Rust)

          Comment

          • ssokolow
            Senior Member
            • Nov 2013
            • 5096

            #35
            Originally posted by Akiko View Post
            Did I miss something? Please stop repeating the "memory safe" stuff, while the application links to the whole c-runtime, gcc-stubs and other c-based libs. This is annoying. There... the flame war can start now.
            "The application links to the whole c-runtime" because, given that OpenBSD will kill your application if it tries to syscall without going through libc, and every POSIX OS except Linux has an unstable syscall interface where libc (or at least libSystem.dylib) is developed as "part of the kernel that just happens to run in userspace", the Rust developers decided it wasn't a priority to give the Rust standard library's abstractions a special platform backend, distinct from the POSIX one, just for Linux.

            Defining "memory safety" to require that something be memory-safe all the way down the stack basically overconstrains it to uselessness, since CHERI would be the only arch that could potentially meet that definition.

            The useful definition that academia agrees on is defined in terms of "as long as the lower abstraction layers are coded correctly". It's about reducing the volume of space where certain classes of bugs can still exist without getting caught at compile time.

            Comment

            • mdedetrich
              Senior Member
              • Nov 2019
              • 2537

              #36
              Originally posted by tobias View Post

              People go through so much effort to bash C++! This particular bunch spent 14 month to port away from C++, so they can report their experiences.

              I always find it surprising how many C++ devs assume Rust devs are out to get them and have zero idea how modern C++ works. I spent 25 years programming in what is now called contemporary C++, I love the language and what I archived with it in that time, but I absolutely do not want to ever go back to it...

              What I find almost funny is how out of touch big parts of the C++ are. Memory safety is so much more than just smart pointers. Check out the safe C++ proposal for a MVP of what would need to change to make C++ comparable to Rust.
              The problem with modern C++ is its in a terrible middle ground. Modern C++ is so different to typical C++ code that it doesn't make that much sense to use it in existing codebases since its advantages won't translate unless you migrate the entire codebase and/or project dependencies. On the other hand modern C++ is hamstrung to C++ which means it can't go all the way in providing all of the security guarantees that languages like Rust provides.

              Which means that if you are considering modern C++, most times Rust is the better choice hence why Fish shell made their decision.
              Last edited by mdedetrich; 29 December 2024, 09:28 PM.

              Comment

              • mdedetrich
                Senior Member
                • Nov 2019
                • 2537

                #37
                Originally posted by Akiko View Post
                Did I miss something? Please stop repeating the "memory safe" stuff, while the application links to the whole c-runtime, gcc-stubs and other c-based libs. This is annoying. There... the flame war can start now.
                Yes you did miss something, almost completely. When people talk about memory safety in this context, they mean the actual code that is written in Rust which rustc compiler has control over. Rust obviously cannot prove memory safety for programs that are written outside of Rust and/or unsafe.

                Your talking about having the entire operating system be memory safe, which is never a claim Rust makes. To do such a think you would need to use something like sel4 kernel, and not Linux so I have no idea what your point here is.

                Comment

                • Daktyl198
                  Senior Member
                  • Jul 2013
                  • 1576

                  #38
                  Originally posted by Weasel View Post
                  Rustards are not devs tho.
                  Pray tell what you have written that is on par with Cloudflare's Pangora which currently moves a significant portion of global web traffic every second. If you come up with a half decent answer, then your opinion might matter. Maybe.

                  Comment

                  • smitty3268
                    Senior Member
                    • Oct 2008
                    • 6956

                    #39
                    Originally posted by lowflyer View Post
                    As a C++ developer I am very much interested in exactly which features they found easier/less annoying in rust.

                    The whole thing really just looks like another attempt to bash C++.
                    Did you actually read the blog post, or just skim through what Michael wrote?

                    Considering there's a whole section called "The Gripes" and another couple called "The Mistakes" and "The Sad" where they talk about things that didn't work out as they wanted during the port to Rust, it's pretty silly to call the whole thing just anti-C++ bashing.

                    Comment

                    • Daktyl198
                      Senior Member
                      • Jul 2013
                      • 1576

                      #40
                      Originally posted by Akiko View Post
                      I prefer Zig over Rust and C, and I consider it the modern successor to C. I wish the kernel lead maintainers would have considered Zig instead of Rust. Zig is a drop-in compiler for C and C++
                      In actuality, what does Zig provide that Kernel C (GCC's proprietary C extensions specifically for the Linux Kernel) does not provide? And of the stuff it does provide, is it worth changing to an entirely different language? Especially one so new? People criticize Rust for being new, when Zig has been around 1/4 as long if even.

                      Comment

                      Working...
                      X