Announcement

Collapse
No announcement yet.

Aya Makes It Easy To Write Rust-Based eBPF Programs For The Linux Kernel

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

  • #21
    Originally posted by sinepgib View Post

    There's exactly zero arguments against my claim here. All of those people who wrote kernels in C++ and Rust are perfectly capable of writing C. They chose not to because those languages are either safer, more ergonomic, or both. But if you _can't_ write C you _can't_ think in low level either
    Nah, I don't agree with this assertion. You can very well think low level without having to know the arcane and often undefined behavior you get from C. Ability to read assembly on the other hand can be useful.

    Comment


    • #22
      Originally posted by sinepgib View Post
      That's all nice in theory, but in reality if you've learned low level, you've coded C. That's the present situation.
      In short, in can't be anything else in the future, because it is what it is right now. Does that sum it up?

      Comment


      • #23
        Originally posted by RahulSundaram View Post

        Nah, I don't agree with this assertion. You can very well think low level without having to know the arcane and often undefined behavior you get from C. Ability to read assembly on the other hand can be useful.
        Agree to disagree I guess. Much of that arcane behavior comes from how machines work, or more specifically from the fact not all of them work in the same way.

        Originally posted by bug77 View Post

        In short, in can't be anything else in the future, because it is what it is right now. Does that sum it up?
        It depends on what we mean by "the future". 5 years from now? I expect you to know C if you claim to know low level. 20 years from now? Maybe you don't even know C existed and everyone moved to safer languages for systems programming at least a decade ago, and I'd believe you when you tell me you do know how stuff works at the bits and bytes level if you know Rust (or whatever replacement we come up with).
        But mostly, that thread was more about my claim that I wouldn't trust someone who can't write C. That's about the present.
        Let's put it in the form of a question: how did you learn low level programming as a person who codes in 2021? I'm pretty sure most people's answer will involve C at some point. That's core of the argument, not whether or not C is the best tool (it is not, IMO) or whether or not it's the only way to learn (obviously it is not). So arguing someone who now knows Rust is unfamiliar with C but at the same time competent in low level issues sounds a bit far fetched to me.

        Comment


        • #24
          Originally posted by sinepgib View Post

          Agree to disagree I guess. Much of that arcane behavior comes from how machines work, or more specifically from the fact not all of them work in the same way
          There are various idiosyncratic or undefined behavior in C that doesn't teach you anything at all about how machines work. You are conflating those two different things. Learning the former doesn't teach you anything about the latter.

          Comment


          • #25
            Originally posted by RahulSundaram View Post

            There are various idiosyncratic or undefined behavior in C that doesn't teach you anything at all about how machines work. You are conflating those two different things. Learning the former doesn't teach you anything about the latter.
            Though TBF, all books that introduce you to low level programming all assumes you have knowledge in C...

            Comment


            • #26
              Originally posted by sinepgib View Post
              Agree to disagree I guess. Much of that arcane behavior comes from how machines work, or more specifically from the fact not all of them work in the same way.
              A lot of C's arcane behaviour comes from supporting kinds of machines that nobody makes anymore, such as machines that don't use 2s-complement arithmetic. Rust plays in the same space without various quirks because, in the 21st century, they made the decision to not support machines with quirks beyond a certain point.

              One of the developers posted this:

              There are a lot of exotic platforms out there, and C is kinda jacked up from trying to support them all. Some of these distortions are annoying but technically fair, like not defining integers to be two's complement or not defining a byte (char) to be 8 bits, because those captured genuine differences between platforms at the time. Others are more just an artifact from C trying something that ended up being a mistake, like the weird integer size fuzziness and promotion stuff.

              A lot of the things C was trying to cope with have largely died off or been relegated to incredibly niche platforms. As such Rust took the opportunity to define more of the properties of the platforms it supports without breaking compatibility with C on those platforms.
              NOTE: this is not a normative document and the Rust devs haven't been very diligent in committing to these claims, so be a bit wary of relying on a property here that lacks a citation.

              For Rust to support a platform at all, its standard C dialect must:
              • Have 8-bit, unaligned bytes (chars)
              • Have a boolean be a byte, where true = 1 and false = 0 (defacto true but not strictly guaranteed)
              • Have integers be two's complement
              • Have IEEE 754(-2008?) binary floats, if they exist (e.g. we're comfortable with just disabling floats)
              • Be at least 16-bit (just in terms of pointer size, I think?)
              • Have NULL be 0 (although things may be mapped to 0, but that's messy since references can't be NULL)

              (Additional constraints exist for running the actual standard library, like atomics support)

              To a modern programmer, these are all incredibly reasonable constraints. In fact I expect most programmers would be very surprised if any of these things weren't true! To my knowledge the last great bastion of these properties being violated is some DSPs (Digital Signal Processors), because they really don't like 8-bit bytes. Rust is fine with not supporting those DSPs for the sake of making things cleaner for 99.9999% of its users.

              Comment


              • #27
                Originally posted by RahulSundaram View Post
                Learning the former doesn't teach you anything about the latter.
                We agree in this part actually, and you're right a lot of it that doesn't teach you a lot of how machines work. But there's a lot of it that comes from it too. Right shift of negative integers, for example, comes from not necessarily having a guarantee of whether your machine will use arithmetic or logical shift (tho it should be implementation defined IMO) when you're supposed to be able to infer what the outcome would be like.
                While that itself doesn't teach you anything particularly valuable, it shows that architectures vary. You may not have it off the top of your head constantly (that's why it's better to use something that actually reminds you of UB like unsafe blocks do), but if you're unable to understand why that happens you're living in the abstract world.

                But as I responded to bug77, it's mostly a matter of whether or not you're likely, today, to actually have learned low level without having been exposed to C. Now, I do think C has too many pitfalls and needs to be replaced. What I don't think is that currently anyone who did learn low level did not learn enough C to write some of it, even if it gets hard (it is a hard language, much more than it needs to be).

                Comment


                • #28
                  Originally posted by ssokolow View Post

                  A lot of C's arcane behaviour comes from supporting kinds of machines that nobody makes anymore, such as machines that don't use 2s-complement arithmetic. Rust plays in the same space without various quirks because, in the 21st century, they made the decision to not support machines with quirks beyond a certain point.
                  So you agree it comes from acknowledging hardware can be varied, right? Keep in mind I'm not saying Rust is not the right tool for the job, in actuality I think it is. I'm saying the programmer that in 2021 doesn't know C is simply unlikely to have dealt with hardware level stuff, so I wouldn't trust them to write that code. Rust is young. It's good, but it's not what most low level programmers used to learn low level stuff. It's not what is used in most bibliography or courses or code samples or drivers. If you haven't been able to interact with any of those, how can I believe you learned the subject?
                  And again, I'm not saying I wouldn't trust someone who decides to use Rust for the implementation, it's two different things.
                  I'm also not claiming Rust is not a valid way to learn. Just unlikely to have been the case for programmers right now.

                  Originally posted by ssokolow View Post
                  One of the developers posted this:
                  To understand those requirements you should be aware other ways to implement hardware exist. Now, I'm not saying those aren't entirely fair requirements. In fact, I wish we ditch big endian platforms too at some point, those were a mistake IMO. But sadly someone thought it was a good idea to build the whole network stack on those so now all routers need to be big endian to avoid a performance hit. The price is the actual devices making use of the network need to perform the swaps.

                  Comment


                  • #29
                    Originally posted by NobodyXu View Post

                    Though TBF, all books that introduce you to low level programming all assumes you have knowledge in C...
                    Not all of them, no. It just depends on the target. In the past, many books started out with assembly language and then we slowly moved over from that to C as a baseline knowledge. This is no longer a good assumption to make. Good understanding of architectural differences, optimizations and hardware specific quirks is certainly necessary but learning all the language specific quirks doesn't help you at all unless you are programming in that language and worse can teach you bad patterns that you need to unlearn.

                    Comment


                    • #30
                      Originally posted by sinepgib View Post
                      So you agree it comes from acknowledging hardware can be varied, right? Keep in mind I'm not saying Rust is not the right tool for the job, in actuality I think it is. I'm saying the programmer that in 2021 doesn't know C is simply unlikely to have dealt with hardware level stuff, so I wouldn't trust them to write that code. Rust is young. It's good, but it's not what most low level programmers used to learn low level stuff. It's not what is used in most bibliography or courses or code samples or drivers. If you haven't been able to interact with any of those, how can I believe you learned the subject?
                      I think our disagreement might be over how high the standards are before someone is considered to "know C". I'm on the paranoid end of the spectrum about that.

                      Comment

                      Working...
                      X