3K Lines Of New Rust Infrastructure Code Head Into Linux 6.13

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • Old Grouch
    Senior Member
    • Apr 2020
    • 693

    #41
    Originally posted by ssokolow View Post

    Funny enough, the overwhelming majority of people I see pointing to formal specification are C or C++ programmers arguing in bad faith because they see it as a threat to the perceived value of the skills they've tied their sense of self-worth to and just want to put roadblocks in the way.

    Now, Rust getting specified to a level that C and C++ are not and never will never be because of politics between the various implementers? Yes, I'm all for that... but don't throw stones from glass houses swiss-cheese'd with holes labelled "implementation defined".

    ...especially when what the Linux kernel is currently written in (GNU C11 plus reliance on various GCC-specific ANSI C "implementation defined" decisions that Clang copied) isn't formally specified either.
    I do not program in C.

    As for throwing stones in glass houses: why perpetuate a bad practice if and when you have the opportunity not to?

    Comment

    • Old Grouch
      Senior Member
      • Apr 2020
      • 693

      #42
      Originally posted by intelfx View Post

      You probably meant to say "a standard". Neither C nor C++ have a "formal specification" in general usage, and the world seems pretty unfazed by that.

      But anyway, having a standard is not an end in itself. It is because C and C++ languages were historically implemented as a pile of independent and mostly proprietary compilers, they needed a standard. Not the other way around.

      When a language, like Rust, is developed from day 1 with a free/libre implementation that's simultaneously the reference implementation and the production implementation, any need for a standard is greatly diminished.
      Now, this does not preclude the potential need for a formal specification. But that's a very different story (and one which is already being worked on).
      Having an implementation that is simultaneously the reference implementation and the production implementation gets you to the same situation as ISO/IEC 29500 Transitional (Microsoft Office Open XML) where it is extraordinarily difficult to generate compatible documents, as part of the standard is implementation defined.

      A (formal) specification and standard validation suite would be a good thing to have. The same would apply to any language used for (kernel) programming, and saying that Rust lacks a formal specification is not meant (by me) to imply that C (or C++) does.

      The idea of trying to add another language with useful attributes to the stable of languages used for (linux) kernel programming is a good one. Finding out how easy, or difficult, it is, and where the pain points are is useful, because, without doubt, another language will come along at some point in the future that people will want to adopt. The cross-language/multi-language maintenance burden is one area where better ways of working are needed, and I trust that the kernel community will find a solution.

      Comment

      • Quackdoc
        Senior Member
        • Oct 2020
        • 5062

        #43
        Originally posted by kpedersen View Post

        More bindings to stagnate and rot as interfaces inevitably change.

        For people who believe bindgen/SWIG is as effective as C++'s direct interop with C, perhaps ask yourself why these bindings are needing to be hand written / maintained rather than just churned out by bindgen/SWIG.
        the question can be answered like this. "Why do something ok, and have ok results, instead of doing things right have having great results." Consuming the generated bindings with a higher level crate to make it easy to consume with great documentation is just a "good developer experience" you can absolutely consume the crates generated by bindgens directly, but why bother when doing a higher level crate is so easy.

        Comment

        • ZenoArrow
          Junior Member
          • Nov 2018
          • 35

          #44
          Originally posted by Phoronos View Post

          "Civilised" is british, very few people use it.
          I know that it's the British spelling, I'm British. As for "very few people use it". There are millions of people in the UK, and there are still links to other countries the UK had ties with, like Australia and India. Not everyone uses American English.

          Comment

          • ssokolow
            Senior Member
            • Nov 2013
            • 5096

            #45
            Originally posted by Britoid View Post
            Apple can distribute a automatic firmware update tomorrow and break the Apple Linux GPU driver, none of the GPU specification is open, nor is it supported by Apple in anyway, thus its a toy that can break at any time.
            Nice goalpost moving. PC motherboard vendors can also distribute a firmware update through the Windows Update support for UEFI Capsule updates and break Linux and, more often than not, the only specs they write to are "will it boot Windows?". Thus, Linux is a toy on anything not from a company like System76 or the enterprise division of companies like Dell.

            Comment

            • MillionToOne
              Phoronix Member
              • Aug 2024
              • 108

              #46
              Originally posted by Gusar View Post

              Phoronix reports on many kernel subsystem additions every cycle - input, graphics, filesystems, etc, etc. Are all those articles pointless too?
              I bet there are far more important articles to write than "3k lines of Rust code added" articles. Like nobody sane gives a fu*k. Nobody does this with C, so why does it have to be done with Rust? After all, it's just a language among others.

              Comment

              • ssokolow
                Senior Member
                • Nov 2013
                • 5096

                #47
                Originally posted by kpedersen View Post

                More bindings to stagnate and rot as interfaces inevitably change.

                For people who believe bindgen/SWIG is as effective as C++'s direct interop with C, perhaps ask yourself why these bindings are needing to be hand written / maintained rather than just churned out by bindgen/SWIG.
                Because "writing bindings" is Rust-speak for "tricking C/C++ developers into writing/maintaining the machine-readable annotations they should have moved out of their comments decades ago when things like splint came onto the scene".

                It's like asking why you can't have a "binding generator" automatically produce high-quality C or C++ bindings for raw assembly language modules.

                Comment

                • MillionToOne
                  Phoronix Member
                  • Aug 2024
                  • 108

                  #48
                  Originally posted by microcode View Post

                  So is it pointless or did you just tell us the point?
                  I'm not the one to argue about which language is better or call people Rust or C fanboys

                  Comment

                  • ssokolow
                    Senior Member
                    • Nov 2013
                    • 5096

                    #49
                    Originally posted by Old Grouch View Post
                    why perpetuate a bad practice if and when you have the opportunity not to?
                    Exactly why I don't want Rust to have a standard in the mould of C or C++. Have you read about the state of the people steering C++? It's the worst "my idea is correct by definition, regardless of implementability or technical merits" clique you've ever heard of. Think "mean high school girl politics" but they're old men.

                    ...plus, people really seem to have a skewed perception of what "having a standard" actually means for C or C++. People don't write ANSI C. They pick a compiler per platform they want to support (two if you're lucky) and write to the extensions that compiler offers because C and C++ as standardized are too incomplete for real-world use. That's what the Linux kernel does with GCC's "GNU C".

                    ...and there are a ton of C compilers that just implement what they want and don't care.

                    I'm reminded of this quote:

                    For a stupid example, I used to work at a company with an IBM mainframe. The C & C++ compiler was limited to lines of 72 characters -- any character after 72 characters was implicitly treated as a comment, no diagnostic. I am not sure whether this is a violation of the C89 standard -- I think that the only requirement is that logical source-lines of up to 4095 characters be accepted -- but it's certainly an unexpected limitation.

                    I don't have any direct experience of embedded vendor compilers; only testimonies that deviations from the standard -- or outright missing parts -- were the norm, rather than the exception.

                    ​-- /u/matthieum @ https://www.reddit.com/r/rust/commen...ing_c/gp81n33/
                    Standards don't magically override human and/or corporate behaviour... but they do increase the risk of bureaucratic tarpits and cliques. (Plus, given the Rust v1.0 Stability Promise, the likely outcome is "Sorry, your standard may say X, but ten times as many crates would break if we stopped doing behaviour Y, so your standard is wrong"... which is why Rust prioritized a regression suite and a bot for running tests against large swaths of crates.io over a standard.)
                    Last edited by ssokolow; 26 November 2024, 04:28 PM.

                    Comment

                    • BesiegedAce
                      Phoronix Member
                      • Sep 2020
                      • 108

                      #50
                      Originally posted by Volta View Post

                      Not only this. LWN became rust propagandistic tube. I bet rust woke foundation is paying them.
                      Not nearly enough fearmongering or buzzwords

                      Comment

                      Working...
                      X