Originally posted by sinepgib
View Post
Announcement
Collapse
No announcement yet.
Aya Makes It Easy To Write Rust-Based eBPF Programs For The Linux Kernel
Collapse
X
-
-
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.
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?
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.
- Likes 1
Comment
-
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
Comment
-
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.
- Likes 1
Comment
-
Originally posted by sinepgib View PostAgree 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.
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
-
Originally posted by RahulSundaram View PostLearning the former doesn't teach you anything about the latter.
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
-
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.
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 PostOne of the developers posted this:
Comment
-
Originally posted by NobodyXu View Post
Though TBF, all books that introduce you to low level programming all assumes you have knowledge in C...
Comment
-
Originally posted by sinepgib View PostSo 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?
Comment
Comment