Announcement

Collapse
No announcement yet.

Cloudflare Ditches Nginx For In-House, Rust-Written Pingora

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

  • #81
    Originally posted by piotrj3 View Post
    I don't think you understand the issue. Any big C++ has tons of hacks. So does C. I seen hacks in MPV, firefox, chromium, etc codebases. Linux, BSD and much more have a lot of goto (for good reason but still). Valve open sourced stuff also have funny programmer comments "this is a stupid fix", "this seems like bad idea but it is fine for now" etc. etc.
    If goto was used, it most likely was a very good usage (unless the codebase is shit), so if Rust doesn't have it, then it sucks. I didn't even know that one, though.

    Originally posted by piotrj3 View Post
    And yes Rust handle concurrency better then C++ because smart pointers of C++ are runtime based. Rust system is compile time based. What basicly means Rust in that case not only is faster, but also can give you guarantee before program even runs. This is something that Cloudflare, discord, NPM developers, or even Karol Herbst (that recently wrote openCL driver in rust) mentioned - that they had to not deal with random memory bugs at all. Many of them also mentioned that cost of maintaining this software is low.
    Out of bounds array checks at compile time can only be done if the array size is constant / known at compile time. In which case C++ compilers will warn about it. Otherwise it's a runtime check, an overhead introduced by Rust. And the funny thing is that C++ has the same thing with std::array if you use the automatic bounds checking of it. So what's the point of Rust here?

    Originally posted by piotrj3 View Post
    Also Rust compiler information is really good, when C++ compiler errors are pure garbage.
    Might be true, but C++ errors improved in newer compiler versions. Concepts also made template errors a lot more bearable.

    Originally posted by piotrj3 View Post
    In case of Rust there is few checks that are not possible in C++ - in static memory bounds checking is done at compile time (you can easly go out of bounds in C++), in dynamic memory out-of-bounds checking is done in runtime.
    Both are done in C++ if you use the non-raw arrays (e.g. std::array) and compiler warnings.

    Originally posted by piotrj3 View Post
    Of course errors for sake of errors are bad examples of real issue but...

    Code:
    std::vector<std::string> v;
    std::string str = "example";
    v.push_back(std::move(str)); // str is now valid but unspecified
    str[0]; // undefined behavior: operator[](size_t n) has a precondition size() > n​
    Rust won't allow you such thing. Entire large family of bugs like use-after-move, Iterator invalidation​, Null pointer dereference​, are still possible in c++ and modern C++ doesn't protect anyhow user against them. And those bugs still plague as CVEs even biggest and most modern C++ codebases.

    And most important issue, C++ concurency is in its infancy and it is not as far performance optimized as Async from Rust. Meanwhile typical Rust async runtime like Tokio is runned by.... a lot of big companies.
    Finally! A good example. That's exactly what I was looking for, thanks. That's actually not possible in C++, and I mean the "moving invalidates the object" part. Because "move" is not a magic thing, so it can't implicitly know it. I guess C++ needs a compiler extension to mark moved objects as "moved" so the compiler can at least warn about it.

    Preventing use-after-free is not really a Rust thing. Freeing memory is part of the library, not language, so a C++ compiler could just as well special case the freeing functions, or use builtins to mark them as such. There are actually GCC function attributes you can use for this, btw. For example, __attribute__((__malloc__(...))).

    The reason these are not Rust or language specific is because you can use external memory allocation functions, such as from Windows API, and they will have the same issues in Rust as they do in C++ without such compiler attributes. So that's not a point for Rust.


    So far I only seen one benefit of Rust over C++ in terms of safety: moving invalidates the source object and lets the compiler know about it. This is a good thing, now let's hope GCC or Clang add it as an attribute or something to mark it as invalidated after a move constructor/assignment operator happens.

    Comment


    • #82
      Originally posted by Anux View Post
      That is the typical "real programmers" fallacy. The problem is that there are no "proper C programmers" out there or atleast not enough.
      If you think returning address of stack variable is an acceptable mistake then you clearly are one of the amateur ones out there, sorry to say. This kind of mistakes is not something hard to reason about. It's beyond implicit when you code. And anyway they are so basic that even the compiler has no problem detecting and warning about it.

      So please.

      Comment


      • #83
        Originally posted by Weasel View Post
        If you think returning address of stack variable is an acceptable mistake
        Hu? Where did you read that? It's not in you're quote and I'm pretty sure I never said that.

        Comment


        • #84
          Originally posted by Weasel View Post
          If goto was used, it most likely was a very good usage (unless the codebase is shit), so if Rust doesn't have it, then it sucks. I didn't even know that one, though.
          Rust has other constructs such as labelled break to serve the same purposes.

          It's similar to how C only has structured goto, compared to, say, assembly languages, so it doesn't let you use goto to violate the single-entry-point principle by jumping into the middle of a function, bypassing its beginning.

          Comment


          • #85
            Originally posted by Anux View Post
            Hu? Where did you read that? It's not in you're quote and I'm pretty sure I never said that.
            Maybe you should read what you respond to first, then, since that's what you basically responded to. So of course I had assumed you were talking about it.

            Comment


            • #86
              Originally posted by Weasel View Post
              Maybe you should read what you respond to first, then, since that's what you basically responded to. So of course I had assumed you were talking about it.
              You claimed that all those mistakes are only done by dumb programmers and "real programmers" don't make these mistakes, that's what I responded to.

              Comment


              • #87
                Originally posted by Weasel View Post
                Finally! A good example. That's exactly what I was looking for, thanks. That's actually not possible in C++, and I mean the "moving invalidates the object" part. Because "move" is not a magic thing, so it can't implicitly know it. I guess C++ needs a compiler extension to mark moved objects as "moved" so the compiler can at least warn about it.
                That would be the point. Rust compiler verifies that it is valid to use some value if it was assigned to something else previously. For C++ it would require extra work for a partial mitigation since the language doesn't enforce enough to be sure the compiler can catch all the permutations in code. 'Modern' C++ improves on the situation but it is not perfect and developers may just overlook they made a mistake or forgot to use only allowed features. Programmers are humans unfortunately.

                I'm sorry I don't have a good example to share. There should many since a significant part of security vulnerabilities are related to memory handling. Usually we don't go to the level to see the code for those.

                I found this article interesting: https://alexgaynor.net/2019/apr/21/m...-wont-save-us/

                Preventing use-after-free is not really a Rust thing. Freeing memory is part of the library, not language, so a C++ compiler could just as well special case the freeing functions, or use builtins to mark them as such. There are actually GCC function attributes you can use for this, btw. For example, __attribute__((__malloc__(...))).
                Executing memory free may be part of the library but Rust does a very good job of helping preventing use-after-free at compile time. It is much more difficult to do that in languages like C or C++ that are not designed to prevent memory issues. One could say that they seem created to encourage them ;-)

                The reason these are not Rust or language specific is because you can use external memory allocation functions, such as from Windows API, and they will have the same issues in Rust as they do in C++ without such compiler attributes. So that's not a point for Rust.
                I believe that the usual approach is to encapsulate those system calls into unsafe wrappers so the rest of the application is isolated from issues there. So in that regard I agree with you, but with the caveat that unsafe sections of code need to be annotated explicitly with unsafe, unlike C/C++ where anything can be unsafe by default. I would give some credit to Rust because of that.

                So far I only seen one benefit of Rust over C++ in terms of safety: moving invalidates the source object and lets the compiler know about it. This is a good thing, now let's hope GCC or Clang add it as an attribute or something to mark it as invalidated after a move constructor/assignment operator happens.
                That's actually the main 'selling' point of Rust; being safe by default. C and C++ aren't safe by default. You can potentially use only 'modern' C++ features to achieve a higher level of safeness but you can not have the same guarantees that Rust is designed to achieve. Other nicer features of Rust are more related to being a much modern language, however they would not be a reason strong enough to encourage a migration at this time.

                Comment


                • #88
                  Originally posted by darkonix View Post
                  That's actually the main 'selling' point of Rust; being safe by default. C and C++ aren't safe by default. You can potentially use only 'modern' C++ features to achieve a higher level of safeness but you can not have the same guarantees that Rust is designed to achieve. Other nicer features of Rust are more related to being a much modern language, however they would not be a reason strong enough to encourage a migration at this time.
                  And actually a lot of the safety mechanisms in Rust are not really possible to do in C/C++ because it would either be breaking change or other constructs in the language would just invalidate that safety mechanism. What you see right now in modern C++ is likely close to the limit of what can be done without having to make a new language (at which point you may as well use Rust). C/C++ are fundamentally designed to give you free access to memory, a lot of language constructs have this assumption. Of course you can make new constructs/abstractions to give you more guardrails but you then end up hitting stone wall due to the languages original designs (along with having to deal with the fact that the original language constructs can often bypass those newer safe constructs).

                  Rust was designed from the opposite angle, which is that by the default the language is safe. This is initially quite limiting and in the early days there was more usage of unsafe than what was deemed as ideal but over time more safe abstractions and improvements were added. Its close to getting to the point whereby Rust almost all abstractions that could be done safely can be done, but of course due to Gödel's completeness theorem and practical concerns this will never be 100%.
                  Last edited by mdedetrich; 20 September 2022, 04:32 AM.

                  Comment


                  • #89
                    Originally posted by Anux View Post
                    You claimed that all those mistakes are only done by dumb programmers and "real programmers" don't make these mistakes, that's what I responded to.
                    "all those mistakes" being the stupid ones like returning address of a stack variable because that's what I was talking about. And yes, they're only done by dumb programmers. Sorry, it's the simple truth.

                    Comment


                    • #90
                      Originally posted by Weasel View Post
                      "all those mistakes" being the stupid ones like returning address of a stack variable because that's what I was talking about. And yes, they're only done by dumb programmers. Sorry, it's the simple truth.
                      So do you now understand why rust is such a good thing? There seem to be mostly dumb programmers out there that couldn't make half of their mistakes if they used rust.

                      Comment

                      Working...
                      X