Yes, 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.
Hard Rust requirements from May onward
261–270 of 797 posts
Re: Hard Rust requirements from May onward
#262It'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…
That's an apples to oranges comparison.
Most of the code in that module is dedicated to the gui maintenance. The parts that do deal with time are perfectly legible.
Re: Hard Rust requirements from May onward
#263It'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…
Memory safety is mostly a issue of the past. Clearly, there are new code bases with memory issue too. But we have tools to prevent that. The new security issues are supply chain attacks. And Cargo is the way to have exactly this.
What part of C package management defends against supply chain attacks?
Does it audit third-party code for you?
Re: Hard Rust requirements from May onward
#264Rust is a great language for devs. They love it and how developer centric everything about it is. But for end users on Debian trying to compile rust stuff is a nightmare. They do breaking changes in the compiler (rustc) every 3 months. This is not a joke or exaggeration. It's entirely inappropriate to use such a rapidly changing language in anything that matters because users on a non-rolling distro, LIKE DEBIAN, wil…
Rust has stability guarantees. As long as you don't update version of your binary/library new compiler versions can compile for that version and you can even interlink different editions so I really don't understand this argument. C++ modules had a proposal for something similar but it did not pass. It would also fix so many horrible backward compatible things haunts the language as a whole.
Re: Hard Rust requirements from May onward
#265The language is tough love, and I think it's important despite what the first respondent has said. Much of the language used seems to stem from nauseating interactions that have occured in kernel world around rust usage. I'm not a big fan of rust for reasons that were not brought up during the kernel discussions, but I'm also not an opponent of moving forward. I don't quite understand the pushback against memory safe…
The pushback comes from the idea to rewrite all old tools in another language just because you can. Instead of creating new projects and using the new language it feels like the most rust projects are rewrite from old projects.
And the most projects you have read about on hacker news in the last year 'I made xy, but in rust' are already abandoned. It's just a trend to write something already existing in Rust just to learn the language and then release it for productive use.
Re: Hard Rust requirements from May onward
#266[flagged]
Re: Hard Rust requirements from May onward
#267Earlier 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…
Nah, you’re just not good enough. I for example would have never made that mistake when calling hover(int32_t) in C. And on the off chance I did, my reviewers would have caught such a simple mistake because they too are excellent C developers.
/s
Re: Hard Rust requirements from May onward
#268Re: Hard Rust requirements from May onward
#269Earlier quoted context omitted.
> 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…
That's a style choice that I think comes from former C++ devs.
Java can potentially have the same problem. But because everyone uses an IDE and because it's rarely really an issue, everyone will simply import `Baz` rather than worry about the Foo::Baz and Bat::Baz collision. It does happen in java code, but I can't stress how infrequently it's actually a problem.