[flagged]
Hard Rust requirements from May onward
251–260 of 797 posts
Re: Hard Rust requirements from May onward
#252[flagged]
What if the person promising the first thing is not the person doing the second thing?
Re: Hard Rust requirements from May onward
#253It's about time. Critical infrastructure still written in C - particularly code that parses data from untrusted sources - is technical debt that is only going to get worse over time. It's not as if Rust is that much more difficult to write than C. Rust is explicitly designed to be what you'd get if you were to re-create C knowing what we know now about language design and code safety. If 32-bit x86 support can be dro…
> Rust is explicitly designed to be what you'd get if you were to re-create C knowing what we know now about language design and code safety. I don't know about that. Look at the code for the COSMIC desktop environment's clock widget (the cosmic-applet-time directory under https://github.com/pop-os/cosmic-applets >), for example. It's pretty much unreadable compared to a C code base of similar complexity (GNU coreuti…
To be fair GUI code is going to be harder to read than a non-interactive utility, in any two languages
Re: Hard Rust requirements from May onward
#254Earlier quoted context omitted.
If people really, really want to have all infra written in Rust, they should step-up and stop using LLVM.
What is the concern with LLVM? I'm asking because I genuinely don't know.
I would assume that because it is written in unsafe C++, it creates technical debt that should addressed rather soon.
Re: Hard Rust requirements from May onward
#255Earlier quoted context omitted.
Basically correct, but Zig is not a memory safe language. It may be an improvement wrt. syntax over C, and its standard library facilities may be genuinely better than Rust's wrt. writing unsafe code, but it's simply not interesting from a safety perspective. I'm sure that even the most rabid Zig advocates would readily acknowledge this point. > Garbage collection is a huge dealbreaker for the people still on C/C++.…
Rust technically isn’t a memory safe language the second you use “unsafe”. Rust advocates tend to pretend the can have their cake and eat it too when comparing it to other low level languages. No, just because you have the word unsafe next to the scary parts doesn’t make it okay. I’ve written a good chunk of low level/bare metal rust—unsafe was everywhere and extremely unergonomic. The safety guarantees of Rust are a…
The point of unsafe is you have small bubbles of unsafe which you can verify rigorously or use tools like Miri to make sure they upheld and you build safe abstraction on top of that unergonomic part. Looking at embedded-hal and even to extreme embassy you can see the value of it. If you don't do any abstraction I definitely agree Rust is not fun to write at all.
Re: Hard Rust requirements from May onward
#256[flagged]
can you link what you're referring to? As I understand, this announcement is about Debian tooling, & you're referencing Linux kernel development discussions
Re: Hard Rust requirements from May onward
#257It's about time. Critical infrastructure still written in C - particularly code that parses data from untrusted sources - is technical debt that is only going to get worse over time. It's not as if Rust is that much more difficult to write than C. Rust is explicitly designed to be what you'd get if you were to re-create C knowing what we know now about language design and code safety. If 32-bit x86 support can be dro…
> Rust is explicitly designed to be what you'd get if you were to re-create C knowing what we know now about language design and code safety. I don't know about that. Look at the code for the COSMIC desktop environment's clock widget (the cosmic-applet-time directory under https://github.com/pop-os/cosmic-applets >), for example. It's pretty much unreadable compared to a C code base of similar complexity (GNU coreuti…
I think the Rust example’s biggest readability sin is using the full names of things like foo::bar::Baz instead of just Baz, but I get why they did that. When you import a lot of things into a file the latter way, it’s easy to get lost in “was that a foo Baz or a wiz Baz?” Sometimes it’s easier just to use the long names everywhere to be explicit.
If I wanted to tweak the Rust project, I’d feel pretty confident I was calling the right things with the right params.
Re: Hard Rust requirements from May onward
#258I'm happy for all developers programming in their favorite programming languages. Programming for over 30 years I have seen entire ecosystems come and go. What I don't get is the burning need for Rust developers to insult others. Kind of the same vibes that we get from systemd folks and LP. Does it mean they have psychological issues and deep down in their heart they know they need to compensate? I remember C vs Pasc…
Rust developers have corporate backing and therefore feel superior even though the language is an ugly OCaml knockoff.
They have the backing to doing the right thing, because their language is memory safe and this everytime means absolutely secure. Irony off.
Re: Hard Rust requirements from May onward
#259Earlier quoted context omitted.
It would've saved the Mars Climate Orbiter: https://en.wikipedia.org/wiki/Mars_Climate_Orbiter > An investigation attributed the failure to a measurement mismatch between two measurement systems: SI units (metric) by NASA and US customary units by spacecraft builder Lockheed Martin.[3]
That was exactly what I was thinking of when I wrote that. But also think of how many libc functions take multiple ints or multiple chars in various orders. You can get carried away with typing, i.e. by having a separate type for everything*. Still, imagine you’re writing, say, a hypothetical IDE device driver and had separate types for BlockNumber and ByteInBlock so that it’s impossible to transpose read(byte_offset…
I sometimes think about a related issue: suppose you have a function whose n parameters have n different types. Should the programmer be required to provide those parameters in a specific order? There's no ambiguity.
There appears to be some tension between different conveniences you might afford yourself. If you have read(offset: offsetTypeForRead, address: addressTypeForRead), you can catch when someone accidentally passes an address where the offset should be and an offset where the address should be.
Or, you can say "hey, I'm always adding the offset to the address; it doesn't matter which one gets passed first" and relieve the programmer of needing to know the order in which two semantically distinct variables get passed to `read`.
But if you do provide that convenience -- and it's not unintuitive at all; there really is only one valid interpretation of a combination of an address and an offset, regardless of the order you mention them in -- you lose some of the safety that you wanted from the types. If your variables are declared correctly, everything is fine. If there's a mistake in declaring them, you'll wave through incorrect calls to `read` that would have been caught before.
Re: Hard Rust requirements from May onward
#260Earlier quoted context omitted.
If people really, really want to have all infra written in Rust, they should step-up and stop using LLVM.
What is the concern with LLVM? I'm asking because I genuinely don't know.
I think the issue he's pointing at is that LLVM is itself written in C++ - so the entire "trusted" Rust toolchain depends on trusting a huge C++ app.