Earlier quoted context omitted.
I am pretty sure that those machines are not running Debian.
You'd be surprised.
Even if they are, they are not updating to latest Debian stable.
Hard Rust requirements from May onward
311–320 of 797 posts
Re: Hard Rust requirements from May onward
#312Yes, let’s introduce a hard dependency on a language which has no specification, only one compiler and supports a pitiful number of architectures. That’s what true progress looks like.
Flagged for deliberately spreading disinformation under the name StopDisinfo. As this user is aware, rust has a specification https://github.com/rust-lang/fls , which they have previously commented on: https://news.ycombinator.com/item?id=44927141 (and which I probably wouldn't have remembered if not for the rather remarkable name they are saying false things under). Rust also has multiple compilers (rustc, mrustc, a…
[flagged]
Re: Hard Rust requirements from May onward
#313Earlier quoted context omitted.
Because there's so many PIC, MIP, and PS/2 systems out there running debian? The war is over. ARM and x86 won.
RISC-V is well on its way to be a challenger to both, with (eventually) full support for Rust.
I'll be happy if it does, but I very much have a "I'll believe it when I see it" view of new archs like RISC-V.
Re: Hard Rust requirements from May onward
#314Earlier quoted context omitted.
What part of C package management defends against supply chain attacks? Does it audit third-party code for you?
I think it's mostly the fact that C dependencies are much rarer and much harder to add and maintain. The average C project has at most a handful of other C dependencies. The average Rust, Go or NodeJS project? A couple hundred. Ironically, because dependency management is so easy in modern languages, people started adding a lot of dependencies everywhere. Need a leftpad? Just add one line in some yaml file or an "Alt…
I never found it hard to add a C library to my projects using pkg-config. And yes, when the package came from Debian I have some trust that it is not a huge supply chain risk.
I think the problem started with the idea over language-level managers that are just github collections instead of curated distribution-level package managers. So my response "C has no good package manager" is: It should not have a packager manager and Cargo or npm or the countless Python managers should all not exist either.
Re: Hard Rust requirements from May onward
#315Earlier quoted context omitted.
Sadly most people don't agree with this I have been seeing hatred on this forum towards Rust since long time. Initially it didn't make any kind of sense. Only after actually trying to learn it did I understand the backlash. It actually is so difficult, that most people might never be able to be proficient in it. Even if they tried. Especially coming from the world of memory managed languages. This creates push back a…
I find Rust much easier to write than C. Its types let me be reasonably sure I’ve written appropriate code before I even get to the point of running tests, and I don’t have to memorize the flow of the whole program to have that assurance. For instance, struct Feet(i32); struct Meters(i32); fn hover(altitude: Meters) { println!("At {} meters", altitude.0); } fn main() { let altitude1 = Meters(16); hover(altitude1); le…
Structs in C are type safe as well.
Re: Hard Rust requirements from May onward
#316It'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…
Right now, there are approximately five languages that are presumed to be acceptable for core applications in the base system: C, C++, Shell (which probably means specifically bash), Perl, and Python. The most recent language to be added to that list is Python, about 20 years ago. That's not to say that everybody likes those languages (indeed, there's quite a few commenters here who I think would be surprised to learn that not only is C++ on this list, but that it's been on it for at least 25 years).
There's other languages that are considered acceptable, even desirable, languages to write applications in (e.g., Java, PHP, Go), but Rust is really the first language to compete sufficiently close to C's competence for people to contemplate adding it to the base-system-languages list. I'd say only Go has ever come close to approaching that threshold, but I've never seen it contemplated for something like systemd.
Interestingly, I wonder if the debates over the addition of C++, Python, and Perl to the base system language set were this acrimonious.
Re: Hard Rust requirements from May onward
#317It'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…
Sadly most people don't agree with this I have been seeing hatred on this forum towards Rust since long time. Initially it didn't make any kind of sense. Only after actually trying to learn it did I understand the backlash. It actually is so difficult, that most people might never be able to be proficient in it. Even if they tried. Especially coming from the world of memory managed languages. This creates push back a…
Assuming you're right about the language being too hard for most people, the outcome I'd expect given the history of computing is that the language will fail or be stuck in a niche
Time and time again, theoretically worse solutions that are easily accessible win
Re: Hard Rust requirements from May onward
#318It'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 this is a you problem
as in that "isn't the style of code you are used too"
I don't think "how well people not familiar with you language can read it" is a relevant metric for most languages.
Also IMHO while C feels readable it isn't when it matters. Because it very often just doesn't include information you need when reading. Like looking at function header doesn't tell you if a ptr is nullable, or if a mut ptr is a changeable input value or instead is a out ptr. which is supposed to point to unitialized memory and if there is an error how that affects the state of the validity of any mutable ptrs passed in. To just name some example (lets not even get started about pre processor macros pretending to be C functions). In conclusion while C seems nice to read it is IMHO often a painful experience to "properly" read it e.g. in context of a code review.
As a side note: The seemingly verbose syntax of e.g. `chrono::DateTime` comes from there being 2 DateTime-types in use in the module, one from the internationalization library (icu) and one from a generic time library (chronos). Same for Sender, etc. That isn't a supper common issue, but happens sometimes.
Re: Hard Rust requirements from May onward
#319Earlier quoted context omitted.
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.
IMHO, Rust is proof that many programmers prefer over-engineering and unnecessary complexity with obtuse syntax over sound language design. My personal theory is that they subconsciously like to keep their craft esoteric and "magic." The importance of readability, simplicity, and KISS just isn't taught enough nowadays.
Re: Hard Rust requirements from May onward
#320Earlier quoted context omitted.
> I think the spin that Rust is necessarily the way forward is what is wrong. I haven't seen this from Rust. Obviously lots of us think that Rust is the way forward for us but I think the problem you're talking about is that nobody offered any alternatives you liked better and that's not on Rust. If Bob is ordering pizza for everybody who wants one, it is not the case that "Pizza is necessarily the way forward", and…
[flagged]
The disagreement is the difference between "there's an group [the Rust community] going around pushing/bullying projects to use Rust" and "project maintainers want to start using Rust". Those two things get conflated a ton, particularly in this forum by people who have an axe to grind against Rust.