Yup it's not without cost. But paying the cost short-term can yield benefits for the long-term.

I'm not defending Rust as the specific here though, I'm discussing it a bit more abstractly in regards to "moving from tech A to tech B". I've only dabbled with Rust, but from what I can tell it _should_ improve overall quality of codebases over time by reducing some of the more painful footguns of C.

▲

modularitynew 9 hours ago | parent [-]

> Yup it's not without cost. But paying the cost short-term can yield benefits for the long-term.

That was not really the vibe I got from your (Insanity) other comment regarding your mental model that you mentioned. "Not a blocker" is somewhat dismissive of costs, since there are cases where the costs can be so high that they are a blocker.

It is also worsened by the risk that it might cost more long-term than it yields, given the issues of Rust, both generally, and specifically to Canonical's needs. Though, C is indeed an ancient and minimalistic language that also has issues.

And then there is the whole aspect of license changes from GPL to MIT through rewriting to Rust.

For the Linux kernel, arguably a somewhat different domain, there are still a lot of features for Rust on the official wishlist that seem far away. Like the minor feature of bitfields, where it is not a core part of the Rust language. And there is the lack of an international standard, or even a regular standard, the document derived from Ferrocene had severe shortcomings and holes last I checked. And then there is the hostility among some in the Rust community towards gccrs, despite gcc possibly being more popular than LLVM in the software projects that Canonical uses or handles.

▲

Insanity 7 hours ago | parent [-]

Definitely case-by-case basis. I'm really not trying to defend Rust or the specifics of this project. But generally learning a new language being a blocker for capable engineering teams is a questionable statement. It definitely can be in practice, because maybe your company has 0 tolerance / budget for learning something new.

But without getting bogged down in specifics, I do stand by the fact that I don't think learning a new language should be a blocker for many in practice.

▲

modularitynew 6 hours ago | parent [-]

But "learning a new language" can mean multiple different things. It can mean learning a language at a superficial level, but it can also mean learning the depths of the language, or the depths of the ecosystem, or both. For instance, for Java, how many professional Java developers understand and know about memory consistency and the Java concurrency model? Or some other niche topics that might be important in some contexts? How much time would it take for someone to learn the ins and outs of unsafe Rust or pinning in Rust, or other involved topics? Or Rust's gotchas?

There are different depth levels of learning a language. And there are lots and lots of topics besides the specifics of various programming languages or their ecosystems.

I barely knew Rust, yet I was able to rather easily dive into and fix significant bugs in a Rust project that the experienced Rust developers on it had struggled with, possibly struggled for months. But the cross-discipline set that was relevant for solving those specific bugs was also a good fit for my competencies as well, and I have lots of experience with OOP, FP, systems programming, etc. FP is not necessarily learned in a day.

	▲	Insanity 6 hours ago \| parent [-]
		So what it sounds like is that you're assuming that the current C-developers are the top 1% of C developers and therefore need to be in the top 1% of Rust developers, familiar with all niches. I don't think that's a reasonable assumption either which way. So it sounds like you're arguing against people learning a new language and using it in a professional or open source context because learning takes time and they're not instantly experts. But.. never getting started is a surefire way to lose the race. Everyone needs to start somewhere. Plus, look at it from the inverse perspective. The newer generation(s) of programmers today are more likely to learn Rust to a deep level than C. And those up-and-coming developers are the maintainers of the codebase in the future. Again, this all ties into thinking long-term vs short-term.