Announcement

Collapse
No announcement yet.

Making The Case For Using Rust At Low Levels On Linux Systems

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

  • #51
    Originally posted by Hi-Angel View Post
    Although I do agree about C++ being unreadable for no reason when templates are come in place, I'd say that «verbosity» have little to do with code readability. More over, C++ with templates is verbose, too verbose!

    The most readable language from ones that I know, in my opinion, is Haskell (so called ML-syntax), and it by no means is verbose, the code is very short. I even have for a year in mind the idea of creating a parser for a text editor, which would translate on the fly parts of code in C or C++ or C# or whatever, into Haskell like syntax look — i.e. the real code remains unchanged, it's just the reader sees it like this (the idea though not even close to its realization for a number of different reasons).

    I'm not saying anything against Ada though, as I don't know this language.
    In case of Ada, it push the "readability" up to that by just reading the code out loud, even a non-Ada developer can understand the algorithm.

    Comment


    • #52
      Originally posted by atomsymbol

      Immutable data structures are an efficient computational model of just a restricted subset of phenomena of the world.
      I sympathize with folks' potential feelings of frustration over generally widespread misunderstanding of functional programming (primarily Haskell) and purity (though personally I find laziness to be more annoying). Still, I find the above tautological and perhaps a bit too reductionist---sure efficient solutions are efficient solution, but what is the class of problems efficiently solved with persistent data structures? Prior to Okasaki's aggregation/work I'm sure most of us thought far fewer problems could be efficiently tackled than exist.

      That being said, I take the sentiment. Working with the prototypical non-inductive data structures like graphs and matrices is a huge pain without mutation.
      Last edited by codensity; 14 June 2016, 05:08 AM. Reason: spelling

      Comment


      • #53
        Originally posted by mmstick View Post

        C++ isn't good for anything. There's good reason why everyone is moving away from C++ and using other languages instead, and why both Google and Mozilla decided to attempt to ditch their usage of C++ for Go and Rust respectively. C++ really isn't good for software libraries either due to C++ not having a stable exportable interface. That's a good reason why everyone writes their software libraries in C, and why all languages implement a C ABI as the foreign interface of choice. Rust, likewise, has the ability to export Rust libraries with a C interface, and many languages are now starting to take advantage of that, including Python and Ruby.
        I think this is too strongly worded. I really like Rust so far (I'm an avid fper) but faulting C++ for lack of library support on one hand and praising Rust's ffi on the other is inconsistent. Rust largely copied the C++ approach to exporting functions and data, after all neither have an abi (however unlike Rust, C++ has proposals).

        My biggest current complaint with Rust is that library support (Rust to Rust) is currently bad and as far as I can tell, not considered a problem (see: https://github.com/rust-lang/rust/issues/16402 and "non-goals" https://internals.rust-lang.org/t/pe...-the-plan/2767). Fetching the world and statically linking everything is such a boring solution. Imagine if libc were written in a way that required the machine to be rebuilt on update.

        Cargo is a particularly badly designed, hyper-coupled tool requiring a python script (that appears to reimplement much of cargo, https://github.com/dhuseby/cargo-bootstrap) to bootstrap. As a package manager myself I'm not quite sure how to cope with rust software---some suggestions strike me as crazy, e.g.
        In Debian's packaging solution for Rust they are not planning on installing Rust libraries globally, only Rust applications, so will not hit this problem. They will be packaging Rust libraries as source to a custom system location. When their package Rust applications are built, they will redirect cargo to look in that location for the source code to their dependencies, which will then be built and statically linked to the application. But the libraries will never be installed anywhere that could cause such a conflict.
        Not even the rust compiler itself can be built if it's already installed system-wide.

        In any case, if you want to look deeper into issues around packaging, at least there's work being done to address some issues (though personally it doesn't satisfy me): https://internals.rust-lang.org/t/pe...-the-plan/2767

        I understand that to get really high-performance specialization as seen in C++ header libraries you're effectively statically linking but I feel like the community at large gives much thought to libraries and abi (e.g. pimpl).

        Comment


        • #54
          Originally posted by atomsymbol

          In a sense, mutability is "native" also to functional programming languages because it is possible to implement a Turing machine in a functional programming language.

          A problem to solve is how create a compiler that can recognize the presence of Turing machines in functional programs and thus can generate efficient assembly code for such cases.
          Sure, the notion of what it means to be purely functional is widely debated (hence Conal's often cited description of C as purely functional). Sometimes mutability and pointers are valuable for expressing an algorithm in which case having something functionally equivalent is fine, however I more often find that it's valuable for making something efficient. In the latter case I want a pointer into ram. I agree that it would be nice if we didn't need ST in Haskell or if we could somehow make all operations on immutable arrays efficient on von neumann machines (perhaps something like a linearity analysis is a good start). If that were the case however, could we not argue that immutable data structures are an efficient computational model of all phenomena of the world [with respect to mutable data structures]?

          Comment


          • #55
            Originally posted by liam View Post

            This is a terrific account of possible reasons for the, apparent, success of rust.
            You mention the CoC (and if add its actual enforcement) but I think, in one case, at least, its attempt to fit everyone in a square slot (I realize civility shouldn't be viewed as such but it's an imperfect world) led to the loss of a really brilliant developer/contributor. For people like that, imho, you should provide an alternate* slot.

            *obviously, even for them, there are limits, but rudeness should be tolerated to degree that the person contributes
            Are you suggesting we grant safespaces to people opposed to safespaces?

            Comment


            • #56
              Originally posted by unixfan2001 View Post

              Are you suggesting we grant safespaces to people opposed to safespaces?
              In a limited sense, yes.

              Comment


              • #57
                Some few objections & observations:
                1) Low level code is not supposed to be large and complex in first place. If it is not a case, it is not a language to fix but project management I guess.

                2) Strong types are double edged sword and could be annoying as well.

                3) Furthermore, all low-level runtime environments are written in C. They are using C types anyway. Be it syscalls, low/mid level libs or something, you have to call it unless you're in mood to write whole OS and usermode from scratch (good luck with it, come back in ~10 years and show your superb achievements).

                4) Dealing with conversion of types is absolutely last thing one may want in low level program. Whatever, Pascal/Delphi are pain to use for low level things due to the fact virtually all OSes are using C as native implementation language. Therefore all low level calls are using C types all over place and doing conversions is no fun and even gives birth to whole new class of mistakes and errors.

                5) Sometimes it could be handy to be able to enter kernel side. A bit of kernel superpower does not hurts on low level. But wait, I could only use C to do that. Needless to say learning 2 different languages is a bit ridiculous and redundant, right?

                6) Writing perfect programs is cool. However there're thousands of C progs and libs. If you're McLeod, you would not mind rewriting everything in Rust. Mortals are really better off changing mere 20 lines of code in lib or prog which "almost does the thing". C got huge advantage here, you could literally write few lines of code yourself, while reusing the rest. Rust seems to be bad at it. It lacks bindings to most libs. Could it be used to create "universally reusable" lib like C, callable from almost any language around? Ability to create new building bricks which are reusable by others matters.

                7) Mozilla have shown us what they're up to, by enforcing signatures on extensions, with no way around. Relying on toolchain from someone like THIS looks shortsighted and hazardous to say the least. Especially when they pedal "package manager" theme. Wouldn't they introduce signatures on their package manager as well, with Mozilla being the only central authority deciding what is "good" and what is "bad", with no means of override?

                8) I'm really fine with installing somelib and somelib-dev using my system-wide package manager. I really do not want some third-party crap to bring some files and execute code in my system. It screws up OS management and brings winduz-like practices on my head.
                Last edited by SystemCrasher; 19 June 2016, 07:21 AM.

                Comment


                • #58

                  I hate topics like this... lots of misinformation.

                  Originally posted by mmstick View Post

                  C++ isn't good for anything. There's good reason why everyone is moving away from C++ and using other languages instead, and why both Google and Mozilla decided to attempt to ditch their usage of C++ for Go and Rust respectively. C++ really isn't good for software libraries either due to C++ not having a stable exportable interface. That's a good reason why everyone writes their software libraries in C, and why all languages implement a C ABI as the foreign interface of choice. Rust, likewise, has the ability to export Rust libraries with a C interface, and many languages are now starting to take advantage of that, including Python and Ruby.
                  C++ can also export a C interface. I made a small library for IRC showing how this can be done here, which uses Boost ASIO and cppformat while providing a C interface: https://github.com/computerquip/cqirc/blob/master/

                  Some few objections & observations:
                  1) Low level code is not supposed to be large and complex in first place. If it is not a case, it is not a language to fix but project management I guess.
                  This doesn't make any sense. The whole reason we created higher-level languages is because machine code is too complex and large to write large projects with.

                  3) Furthermore, all low-level runtime environments are written in C. They are using C types anyway. Be it syscalls, low/mid level libs or something, you have to call it unless you're in mood to write whole OS and usermode from scratch (good luck with it, come back in ~10 years and show your superb achievements).
                  This is blatantly false. D writes its runtime in D. Rust writes its core in Rust: https://github.com/thestinger/rust-c...ee/master/core

                  4) Dealing with conversion of types is absolutely last thing one may want in low level program. Whatever, Pascal/Delphi are pain to use for low level things due to the fact virtually all OSes are using C as native implementation language. Therefore all low level calls are using C types all over place and doing conversions is no fun and even gives birth to whole new class of mistakes and errors.
                  There is no "type conversion". Machine code doesn't understand what a type is outside of an address and contents of a register. C does not pass "C types", it simply passes data that the language simply has to provide to the user in a way that's fit for the language. It has to do this anyways in order to be a systems programming language. For instance, in Rust, https://doc.rust-lang.org/book/ffi.html
                  The inter)face may be dangerous according to the Rust guide but that doesn't mean it's something that's specific to C.

                  5) Sometimes it could be handy to be able to enter kernel side. A bit of kernel superpower does not hurts on low level. But wait, I could only use C to do that. Needless to say learning 2 different languages is a bit ridiculous and redundant, right?
                  I have no idea what you're talking about. You do not enter "the kernel side" just because you're using a low-level language. You enter "the kernel side" when you write a driver module or writing part of the kernel. Also, C is not specific to the creation of a kernel. Haiku, which is based on BeOS, uses C++. There's another kernel actually written in rust here: https://github.com/redox-os/redox

                  6) Writing perfect programs is cool. However there're thousands of C progs and libs. If you're McLeod, you would not mind rewriting everything in Rust. Mortals are really better off changing mere 20 lines of code in lib or prog which "almost does the thing". C got huge advantage here, you could literally write few lines of code yourself, while reusing the rest. Rust seems to be bad at it. It lacks bindings to most libs. Could it be used to create "universally reusable" lib like C, callable from almost any language around? Ability to create new building bricks which are reusable by others matters.
                  C lacks things like generic containers, a decent benchmark/profiler library, and so forth. Using your logic, even if C was the most flawed language in the world, we should still use it because it has libraries... which is easily debatable. In addition, Rust can already export using a C interface, just like C++ and D can.

                  7) Mozilla have shown us what they're up to, by enforcing signatures on extensions, with no way around. Relying on toolchain from someone like THIS looks shortsighted and hazardous to say the least. Especially when they pedal "package manager" theme. Wouldn't they introduce signatures on their package manager as well, with Mozilla being the only central authority deciding what is "good" and what is "bad", with no means of override?


                  8) I'm really fine with installing somelib and somelib-dev using my system-wide package manager. I really do not want some third-party crap to bring some files and execute code in my system. It screws up OS management and brings winduz-like practices on my head.
                  This is ridiculous, it's not even funny. You're saying the only possible trusted source for anything is your package manager. Why do you trust your package manager so much, compared to the next package manager? Hell, in OpenSUSE, the package manager has completely fucked my setup several times due to various dependency issues. The only person executing the code is you, it's your job to verify that everything is safe, whether it's the package manager or... well, this other package manager you don't trust for some reason.

                  And not all libraries should be slapped into the system library directory. I'd honestly appreciate if we *didn't* do that all the fucking time since I might want to modify the library for my specific purpose and not rely on some generic build configuration provided and forced onto me. We have no way of distributing applications with our package manager with modified libraries unless we statically linked them (which a lot of GPL-based libraries actively prevent) which, in 2016, is frankly ridiculous and embarrassing.
                  Last edited by computerquip; 19 June 2016, 04:30 PM.

                  Comment


                  • #59
                    Originally posted by computerquip View Post
                    This doesn't make any sense. The whole reason we created higher-level languages is because machine code is too complex and large to write large projects with.
                    Sorry to butt in like this but I read the remark you're responding to as that the software written with low level languages shouldn't be large and complex; not the actual language itself.

                    Comment


                    • #60
                      Originally posted by F1esDgSdUTYpm0iy View Post
                      Sorry to butt in like this but I read the remark you're responding to as that the software written with low level languages shouldn't be large and complex; not the actual language itself.
                      Yes. The confusing part here is that low-level language can refer to various things and needs a point of reference to understand what it actually means. A large project in assembly is difficult and hard to maintain, one reason we created higher-level languages. A large project in C or C++ is quite common and viable. Unless I'm still misunderstanding something.

                      Comment

                      Working...
                      X