Announcement

Collapse
No announcement yet.

Rust-Written Redox OS Now Supports GDB Debugging

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

  • #51
    Originally posted by mdedetrich View Post
    How do you think left shift is implemented, hint its not magic or "chance".
    Oh wow, you are unstoppable. On x86 it can be "shl", "lea", "mul", "add" or something else depending on constant folding/propagation and countless optimizations involved. On arm/aarch64 there are even more ways to do left shift, you can literally have it with any instruction. How does it matter at all? Just clarify to yourself what is UB.

    Comment


    • #52
      Originally posted by mdedetrich View Post

      This is very misleading. There hasn't been any new language to compete against C/C++ in the same niches apart from Rust and D. D didn't get far because its just an incremental improvement over C++ (also other reasons, i.e. system library wars with phobos).

      You do realize that Rust was specifically created by Mozilla because of how shitty C/C++ was, Mozilla maintaining an entire browser written in C++ (browsers are probably the most complex pieces of software apart from maybe AAA game engines).



      Except that Rust is just as low level as C/C++, I really don't know what you are trying to say here. Apart from bounds checking Rust has the same (or slightly better) performance as C/C++ for equivalent code but much more secure. Of course you can drop to lower level and write in LLVM bytecode/ASM but then we are not talking about Rust/C/C++ but bytecode/ASM. You can use unsafe in Rust (which is basically a variant of C) however apart from interfacing with external systems/IO its often unneeded, by this I mean people have tried to use unsafe specifically for performance reasons and they either create security issues or there wasn't a performance improvement (see latest Rust debacle with their actix web server).

      You are making a false equivalence between security and performance. Yes they are related but it doesn't mean that in order to be fast you have tbe insecure.
      1.) there is a bunch more from the 80's and 90's, outside D i think the most influential was Pascal when Borland was on its prime and tried really hard to move people from C++, back then i received 20 mails daily about how turbo pascal and then delphi do this or that better, this or that company switched and now the TCO is 20x better, etc.
      2.) yet, Google seems fine and is faster and not even close but lets say top mid, also Firefox webrender for me still is way more crash prone than chromium
      3.) sure, lets leave it at that cuz without very detailed code exchanges is hard to keep up and honestly that is a pain here, if at some point i post some code in that rust bench site then we can discuss more in depth.
      4.) I've never said unsafe but "people think is unsafe" and is obviously not related. let me clarify

      What i mean literally is this:

      Everything C/C++ do is for a reason and there is a time when you really need all that fine control without safety nets and for that you really need understand how the hardware will react when you use them because if you don't you may introduce a lot of problems, sadly many developers often come here thinking they know best just to find out the hard way they didn't.

      Also i like to point out undefined behavior does not mean "will return random crap with no sense and expose your ram to the internet" but the result depend on the usage and the developer/hardware intention not the C/C++ standard body, hence why they may become dangerous on the wrong hands.

      Also all those ultra fine control options often require very specific scenarios/algorithms to show performance advantages, so simply use them on regular algorithms is not a great idea as the actix team found out.

      Comment


      • #53
        Originally posted by jrch2k8 View Post

        1.) there is a bunch more from the 80's and 90's, outside D i think the most influential was Pascal when Borland was on its prime and tried really hard to move people from C++, back then i received 20 mails daily about how turbo pascal and then delphi do this or that better, this or that company switched and now the TCO is 20x better, etc.
        Pascal was not suitable for the same use cases as C so its not a valid comparison. C was actually created because at the time there was no other systems level language apart from assembler (and Pascal existed at the time).

        Pascal with Turbo Pascal might have tried to pull over C++ developers for the same reasons as Java, but these reasons are different ones than what we are talking about.

        Originally posted by jrch2k8 View Post
        2.) yet, Google seems fine and is faster and not even close but lets say top mid, also Firefox webrender for me still is way more crash prone than chromium
        Again a terrible example, chrome was built way before Rust even existed and V8 (one of the main hotspots for browsers is JS) is hand written assembler.

        Originally posted by jrch2k8 View Post
        Everything C/C++ do is for a reason and there is a time when you really need all that fine control without safety nets and for that you really need understand how the hardware will react when you use them because if you don't you may introduce a lot of problems, sadly many developers often come here thinking they know best just to find out the hard way they didn't.

        Also i like to point out undefined behavior does not mean "will return random crap with no sense and expose your ram to the internet" but the result depend on the usage and the developer/hardware intention not the C/C++ standard body, hence why they may become dangerous on the wrong hands.

        Also all those ultra fine control options often require very specific scenarios/algorithms to show performance advantages, so simply use them on regular algorithms is not a great idea as the actix team found out.
        On this I agree but I again I don't see how this is relevant to the discussion if we are doing apples to apples comparisons. Of course some C/C++ codebases use undefined behaviour/inline assembler etc etc but then its not an apples to apples comparison with Rust.

        Comment


        • #54
          Originally posted by gnulinux82
          That's my cue to leave. See you in the next Rust thread, genius.
          See you later! BTW next time if you want a photo album of me maybe just ask politely rather than posting my photos on the internet. Maybe we can add your photos as well?

          (If its not obvious to you and judging from your posting history you seem to have a habit of missing points, next time try to be more mature instead of shaming people due to how they look)
          Last edited by mdedetrich; 07-28-2020, 06:56 PM.

          Comment


          • #55
            Originally posted by mdedetrich View Post

            Pascal was not suitable for the same use cases as C so its not a valid comparison. C was actually created because at the time there was no other systems level language apart from assembler (and Pascal existed at the time).

            Pascal with Turbo Pascal might have tried to pull over C++ developers for the same reasons as Java, but these reasons are different ones than what we are talking about.



            Again a terrible example, chrome was built way before Rust even existed and V8 (one of the main hotspots for browsers is JS) is hand written assembler.



            On this I agree but I again I don't see how this is relevant to the discussion if we are doing apples to apples comparisons. Of course some C/C++ codebases use undefined behaviour/inline assembler etc etc but then its not an apples to apples comparison with Rust.
            1.) pascal was very dark before C since it was mostly very system specific for main frames until borland took it on its umbrella and turbo pascal did almost all the things C did at some point but it become so messy and broke pascal features so bad, pretty much no ever even knew they existed

            2.) Firefox exist before Rust, before Chrome, before KHTML, Webkit, etc. Netscape became Firefox when it got open sourced at the end of the 90's, so i don't see the point of pointing ages and was C with lot of assembly as well and im pretty sure was the same for IE as well. My point is both are browsers and one is measurably superior to the other and more stable(at least for me on Linux, i do agree Chrome on Windows have issues tho) but don't get me wrong i do use Firefox as well since there are some extensions that i prefer for certain jobs over chrome and vice versa.

            3.) the point is exactly that when rust can slug with C++ apple vs apple is then a C++ replace until then is WIP because while i do agree your run of the mill desktop user facing application will go better using Rust, other markets like finance, military, industry, etc. need those "codebases use undefined behaviour/inline assembler etc etc" and some more.

            But like i said to keep going on this will require both have access to the same hardware and very specific code to benchmark and compare, and that is a pain to do, i'm sure at some point this data will come and then we can retake it with proper measures.

            Comment


            • #56
              Originally posted by marios View Post
              PS. I like the "Rust Evanglism Strike Force" characterization. Maybe i will start using it instead of "aggressive fanboys". Well played gnulinux82...
              From what I remember, that was actually coined sarcastically by sane, responsible Rust enthusiasts who were fed up with having to run damage control for the the fanboys.

              Originally posted by gnulinux82
              This example just demonstrates that people absolutely will use unsafe frivolously and unleash the exact same category of bugs that Rust supposedly "avoids". Ergo, Rust does nothing to tackle the problem of know-all programmers who think they know better than conventional wisdom (e.g. you).
              Of course Rust gives you the power to shoot yourself in the foot, because sometimes that power is needed. Rust is intended to have sufficient low-level power that, when you use compiler intrinsics, lower-level languages are as unnecessary as in C or C++. (Before you mention asm!, remember that Microsoft's attitude is "Visual C++ doesn't allow inline assembly for 64-bit targets. Use intrinsics.")

              ...however, Rust also gives you #![forbid(unsafe_code)] and tools like cargo-geiger. (Putting the former in your main.rs or lib.rs turns use of unsafe inside that crate into a compile-time error which cannot be selectively overridden with allow. The latter displays a readout of unsafe use throughout your dependencies, including flagging crates which use #![forbid(unsafe_code)] in green, so you can choose your dependencies responsibly.)

              The point of Rust is to manage unsafety, so you can have small chunks of it, with many auditing eyes looking at them, wrapped in APIs that prevent incorrect use.

              Comment


              • #57
                In general I don't have a problem with Rust. On paper it solves a lot of the things that bothered me about C over the years.
                In practice though, it seems to be a tar pit to get anything compiled.
                Not even this Redox OS will compile cleanly from freshly checked out sources.
                Maybe it is still too early and Rust needs to mature some more, but then the "Rust fanboys" should not push it so hard ...

                Comment


                • #58
                  Originally posted by Raka555 View Post
                  In general I don't have a problem with Rust. On paper it solves a lot of the things that bothered me about C over the years.
                  In practice though, it seems to be a tar pit to get anything compiled.
                  Not even this Redox OS will compile cleanly from freshly checked out sources.
                  Maybe it is still too early and Rust needs to mature some more, but then the "Rust fanboys" should not push it so hard ...
                  Rust is hard. I've been using it to write my custom tooling for several months now. There are still things I don't understand about it. But I've found that the best way to get things done with Rust is to forget everything I know about C.

                  EDIT: I don't think a lot of the Rust evangelists actually know the language that well. If they did, they would acknowledge some shortcomings. For example, it wasn't until earlier this year that the language finally got a suitable system for error handling and propagation.

                  Comment


                  • #59
                    Originally posted by wswartzendruber View Post
                    Rust is hard. I've been using it to write my custom tooling for several months now. There are still things I don't understand about it. But I've found that the best way to get things done with Rust is to forget everything I know about C.
                    You can watch Rene here struggle with the same kind of issues that I experience with rust software:
                    https://www.youtube.com/watch?v=LPFh...em-lbcastemail

                    Comment


                    • #60
                      Originally posted by wswartzendruber View Post
                      EDIT: I don't think a lot of the Rust evangelists actually know the language that well. If they did, they would acknowledge some shortcomings. For example, it wasn't until earlier this year that the language finally got a suitable system for error handling and propagation.
                      Are you talking about Result or something else?

                      Originally posted by wswartzendruber View Post
                      Rust is hard. I've been using it to write my custom tooling for several months now. There are still things I don't understand about it. But I've found that the best way to get things done with Rust is to forget everything I know about C.
                      Yup and ironically left shift is always defined behavior in Rust!


                      Last edited by mdedetrich; 07-28-2020, 08:16 PM.

                      Comment

                      Working...
                      X