Announcement

Collapse
No announcement yet.

Rust-Written Redox OS Now Supports GDB Debugging

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

  • #61
    Originally posted by mdedetrich View Post

    Are you talking about Result or something else?
    I'm talking about this sequence of events:

    1. You should define your own error types manually; it's long and here's how to do it.
    2. Actually, use this crate called error-chain to define your error types; it's limited, though.
    3. Nevermind error-chain, use this crate called failure; it will inject its own types into your public API, though.

    Finally, BurntSushi (author of byteorder) had seen enough of this crap and released this-error. It basically makes generating your own errors really easy, to include propagation and specifying the underlying cause, but uses only types from standard Rust.

    Comment


    • #62
      Originally posted by wswartzendruber View Post
      Finally, BurntSushi (author of byteorder) had seen enough of this crap and released this-error. It basically makes generating your own errors really easy, to include propagation and specifying the underlying cause, but uses only types from standard Rust.
      Ah thanks I will look into it

      Comment


      • #63
        Originally posted by mdedetrich View Post
        Are you talking about Result or something else?
        Probably talking about how the systems built on top of the provided primitives were insufficient. Result is good in theory, but how do you create custom errors and reconcile the different error types that are going to be coming out in Results so you can easily create errors, pass them around, and bubble them up to the appropriate level?

        It was only recently that the necessary changes were made to std::error::Error to make it easy to do those sorts of conversions without a lot of manual boilerplate-juggling, and then the anyhow and thiserror crates were developed to automate what boilerplate still exists in that approach.

        EDIT: anyhow is the application-side stuff for using errors, where you often don't care so much about specific types, as long as you can do things like catching errors or attaching some context to an error you received and then passing it up the call stack. thiserror is the library-side stuff for defining custom errors and type conversions easily.
        Last edited by ssokolow; 07-28-2020, 08:25 PM.

        Comment


        • #64
          You can see how I define my error type via thiserror on lines 31-50.

          https://github.com/wswartzendruber/p...rc/pgs/read.rs

          Line 33 is where I configure it to be able to propagate up when caused by std::io::Error (see my typedef on line 24).

          It's quite easy to propagate errors up to the caller via the ? operator.

          Comment


          • #65
            Originally posted by ssokolow View Post

            Probably talking about how the systems built on top of the provided primitives were insufficient. Result is good in theory, but how do you create custom errors and reconcile the different error types that are going to be coming out in Results so you can easily create errors, pass them around, and bubble them up to the appropriate level?
            Yeah the main language I code in (Scala) has similar problems however it has subtyping so its easier to create an error supertype that can combine other types of errors that can be propogated.

            I didn't get to this problem yet in Rust though because I am still writing basic AST transforming code and haven't really gotten to error management yet (also not writing a library). Thanks for the tip.
            Last edited by mdedetrich; 07-28-2020, 08:41 PM.

            Comment


            • #66
              I simultaneously feel like I've learned a lot of interesting stuff by taking the time to read through this thread, and that a lot of words were spent for little gain...

              I've tinkered with Rust in the past, but not got very far. But then, for the last few years, most of my coding time is spent either in MATLAB/Octave and C#, or fighting with ancient FORTRAN code.

              Comment


              • #67
                Originally posted by jrch2k8 View Post

                There is a reason C and C++ has survived every killer new language for so many decades and believe or not C/C++ is really really lean and that is because every language that have tried to kill C/C++ end becoming C/C++ and at that point is meaningless and for that same reason many features are double edge swords, specially for developers that learned programming but not the hardware.

                Why? because the hardware itself is not safe nor provide any guarantee and it assumes(wildly in some architectures) that you understand what is supposed to do properly, hence C and then C++ were created to be extremely granular to be able to adapt to almost if not every situation the hardware can throw at you and all this features that people fear so much are really needed.

                The problem is, granularity is error prone if you don't understand the hardware and this is where C/C++ gained its fame.

                C/C++ are not languages for the faint of heart but due to its fame for performance many devs jumped in without proper understand of it, just to end in a loop of fixes and errors because if something is logic for the software may not be for the hardware.

                If Rust wanna kill C/C++ completely it will have to allow you drop security, type safety, give you control flow over LLVM(or any other backend) code generation, etc. and at that point every possible mistake with C/C++ will be possible with Rust.

                What Rust should do is go for replacing certain aspect of C++ and aim to become a general application language because honestly C/C++ is way too low level for most of the things a normal desktop application should do.

                So, leave C/C++ for the real close to metal code that really need to be that low and Rust from there with all its safety nets active and you can have the best of both worlds.
                I don't think so. Yes, many of security mechanisms in Rust are not exactly free, but:
                - for most code, they can come close
                - if you don't like them, you can switch them off

                Even looking at kernel sources, it is not that low-level everywhere. Most sources are quite ordinary.
                Then there are special header declarations ( alignment etc stuff) etc.

                This can be done in Rust AFAICT easily, with Rust taking care of more than 80-90% of the sources with its default protections.

                I like mostly about Rust is that it's C/C++ _rethink_ . It has been implemented not as some academic project but actively in the field with language implementers getting real-time feedback from various project re/done in Rust. Redox is great, if for nothing else, just that reason.

                Every change in Rust is made after getting confirmation "from the ground" and language at this stage doesn't have to wait for standardisation body etc.

                To me, its learning curve looks infinitely lower than for friggin C++. C++ has too many abstractions that require from code writer to be on the same "mental wavelength" as langauge implementer. And much of that was just untested hype and wet dreams that were standardised and then proven faulty or with too much baggage.

                Barring Nazi borrow-checker, Rust is free of most of that. At least I can't find any big deal. WRT to borrow checker, this is one pain point, but it's neccessary. Alternative is chasing stupd bugs in C or going through insane iterative C++ language increments for partial result. This sort of errors one has to get under control. It's either WC or chasing/linting them manually, which is not foolproof.

                Comment


                • #68
                  I have no doubt Rust is capable to replace C/C++. An over simplified way to look at it is, put boundary checking and pointer ownership checking in C/C++ and you get Rust. So performance number could vary a little bit but it is not that significant and also depends on optimization. In some cases small things like using string with explicit length could improve performance a lot in C/C++.

                  I just wish it keeps a C compiler and can use Linux driver source code as is, so that enough people can get a chance to at least boot it.
                  Any OS without enough drivers is not going to fly. GUI stack is another bigger issue as amount of code in GUI is actually much larger than kernel.
                  Last edited by goTouch; 07-28-2020, 11:30 PM.

                  Comment


                  • #69
                    Originally posted by jjkk View Post
                    Nothing new here. Absolutely every topic mentioning rust is flooded with rust marketing monkeys pushing it with insane zeal. They just unable to realize how it causes natural reaction of disfavor and antipathy. Hope they get paid for this and will show even more convincing results in future.
                    I'd suggest going back to the first page of comments and re-reading.

                    There are a handful of innocuous comments made asking why this is useful, others explaining why it might be, etc. And then the inflammatory post that kicked off this long thread was posted by gnulinux82 on post #6. I suspect he would not consider himself a "rust marketing monkey".

                    Both sides of this "argument' were frankly really dumb, and should have just ignored each other, but it's odd to blame the person responding to inflammatory comments more than the original commenter, especially when said comments are being made on a thread about a prominent Rust project. It's like someone from Gnome showing up on a KDE thread or vice versa, throwing out some flamewar statements, and then blaming the fans of that desktop for responding back.

                    If this was a thread about some C library and someone posted that they should port it to Rust then the same would be true there as well, and all the people that would inevitably respond about why Rust sucks would have some level of justification.
                    Last edited by smitty3268; 07-29-2020, 02:32 AM.

                    Comment


                    • #70
                      Looks like we are dealing with 2 issues here:
                      1)fans of penguine do not tolerate anything that could turn into competition
                      2)for certain set of people performance is more important than safety. That they go bash Intel CPU's in the next thread is hypocrisy, is lost to them.

                      Comment

                      Working...
                      X