Announcement

Collapse
No announcement yet.

Grep 3.7 Released To Fix "Extreme Performance Degradation"

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

  • #31
    Originally posted by tildearrow View Post
    The problem with Rust is that even though it enforces checks, it does so in a bizarre way and the syntax is hell (as I mentioned before).
    Syntax is subjective and there is nothing bizzare about how Rust is doing it, its just functional programming. i.e. Rust's Option is just a type checked null, so you are forced to either handle the empty (i.e. null) case or when there is a value there and as mentioned previously there is syntax sugar for this as well.

    There is a difference between bizzare and unfamiliarity (which I suspect is what you are dealing with).

    Comment


    • #32
      When Rust/Java developers try to tell me their language is so much better, in my mind, I'm picturing a kindergartener riding up to a first grader and saying, "My tricycle is SO much better than your bicycle! It's got THREE wheels instead of only TWO, and look, it can't fall over!"
      Last edited by ed31337; 16 August 2021, 05:42 PM.

      Comment


      • #33
        Originally posted by pkunk View Post

        In C/C++ something is correct when someone can use it correctly, but in Rust something is correct when someone can't use it incorrectly.
        Uh... what? Why would you say the same thing twice but act like its different?

        What you said: (A == True when C == True) =/= (B == True when C =/= False), therefore, A =/= B

        But

        B == True when C =/= False -->B == True when C == True

        That means that you actually said: (A == True when C == True) =/= (B == True when C == True)

        Therefore, A == B

        Comment


        • #34
          Originally posted by binarybanana View Post
          No, it's not as stupid at you make it sound. If you get a Result, or Option that's because the value might be missing. This requires handling one way, or another. If you don't, it's a segfault because you didn't check for NULL.

          That doesn't mean you have to do verbose error checking like Go. There's the ? operator that extracts the value, or returns from the function, passing on that error value down the stack.
          Thanks. But in that case, you're right: it's not as stupid as I "make it sound": it's even worse. I'm sorry, did I ASK you to bail from the function? No? Then why are you doing that instead of letting me handle the problem locally? ugh...

          Exception handling in C++ also began life as "for exceptional conditions only", but there are patterns that *require* EH to be viable, and since those patterns are critical to avoiding resource leaks, enforcing known state in objects, and so on, EH evolved to become part of the natural workflow of the language. (And as a result, the overhead of EH went from about 20% to ~0%, which in turn encouraged adoption of the safety patterns, so that's nice. )

          What you're describing is basically "error handling capabilities on par with K&R C". We moved on from that literally last century!

          It's not that you "can't" write code that way, but having gone through this transition in the other direction, it's hard to imagine why anyone would WANT to have to only have shitty error handling that requires adding boilerplate to basically every function call. The fact that you don't have the option of just not bothering is "good" as far as ensuring that returns are checked etc, but it doesn't in any way reduce the amount of work you have to do (which is a pain in the ass if you're just throwing together a POC), and it doesn't lend itself to being able to handle errors without poisoning the code with an unreadable / maintainable mess.

          TLDR: Rust is clearly still very immature in this area, and will need to improve substantially for it to be able to graduate from the "only really suited to toy programs" stage.

          Comment


          • #35
            Originally posted by ed31337 View Post
            When Rust/Java developers try to tell me their language is so much better, in my mind, I'm picturing a kindergartener riding up to a first grader and saying, "My tricycle is SO much better than your bicycle! It's got THREE wheels instead of only TWO, and look, it can't fall over!"
            C/C++ is like a Penny Farthing (old and easy and unsafe), Rust is like a regular bike and Java is a tricycle.

            Comment


            • #36
              Originally posted by arQon View Post

              Exception handling in C++ also began life as "for exceptional conditions only", but there are patterns that *require* EH to be viable, and since those patterns are critical to avoiding resource leaks, enforcing known state in objects, and so on, EH evolved to become part of the natural workflow of the language. (And as a result, the overhead of EH went from about 20% to ~0%, which in turn encouraged adoption of the safety patterns, so that's nice. )
              Uh, exception handling is only "free" as long as you never catch the exception (ergo throwing is free). If you do catch the exception its actually incredibly expensive, which is why it should only be used for exceptional situations.

              Otherwise you should treat your error case as normal values and pass them along (and thats what Rust's Result/Option is for). The same goes for Java/Scala and other languages that have exceptions.

              Comment


              • #37
                Originally posted by mdedetrich View Post
                Uh, exception handling is only "free" as long as you never catch the exception (ergo throwing is free). If you do catch the exception its actually incredibly expensive, which is why it should only be used for exceptional situations.
                Dude, I used "overhead" for a reason! You're right that "free" would be an acceptable synonym in this case in standard spec use, in that the capability cost is basically non-existent these days (vs 15+ years ago, when making EH *available* to the code had its own independent and significant overhead just by existing) but you're going to give the non-developers a headache like that.

                Even when EH *is* actively used though, it simply just *isn't* "incredibly expensive" any more. That's not even actually all that important, but it's worth correcting. You're still talking about the distant past. But for now, let's just agree that it's non-zero and leave it at that.

                But to your main point: well, yeah. I don't think anybody's suggesting that we should start writing code like "if (a != b) throw compare_failed()" for integer types.
                But I think you're misunderstanding the term "exceptional", based on - again - guidance from 20 years ago.

                > Otherwise you should treat your error case as normal values and pass them along (and thats what Rust's Result/Option is for).

                You're conflating two very different things here - and neither of them is even the point!
                It's late, and I'm tired, and if you're seriously trying to understand then this deserves a much more detailed reply than I can give it tonight. I'll try to come back to it, but if I forget over the weekend feel free to PM me a reminder.

                Comment


                • #38
                  Originally posted by lyamc View Post

                  Uh... what? Why would you say the same thing twice but act like its different?

                  What you said: (A == True when C == True) =/= (B == True when C =/= False), therefore, A =/= B

                  But

                  B == True when C =/= False -->B == True when C == True

                  That means that you actually said: (A == True when C == True) =/= (B == True when C == True)

                  Therefore, A == B
                  That's because you didn't understand what he said and therefore made a wrong abstraction in your propositional logic.

                  Comment

                  Working...
                  X