Hacker News Reader

Comment by modularitynew | Hacker News Reader

Your argument about stagnation is good, but "capable engineers can pick up any language" is not without costs for the involved developers in terms of time spent learning paradigms, features, bugs, gotchas (like temporary lifetime gotchas in Rust encouraged by the constraints of the borrow checker, still a widespread issue in 2026 https://fasterthanli.me/articles/a-rust-match-made-in-hell ), APIs, libraries, ecosystem, build systems, etc.

They would also have to figure out how to approach distribution, organization, linking, etc.

View on HN

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.

> 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.

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.

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.

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.

> still a widespread issue in 2026

Is it "widespread"? The article you link is from 2022 and none of the discussion I saw on said article gave me the impression that it was particularly common issue back then, let alone now.

Indeed it is, read this:

https://old.reddit.com/r/rust/comments/1v54et2/what_are_the_...

Links for anyone without a Reddit account:

https://redlib.catsarch.com/r/rust/comments/1v54et2/what_are...

It is a mess, temporary lifetime extension is a mess in both Rust, C++ and Zig (despite Zig not having RAII unlike Rust and C++). Interestingly, Mojo might avoid some or all of that, by having some destructors be implicit, and some destructors be explicit, https://mojolang.org/docs/manual/lifecycle/death/ , requiring users to write the destructors manually. Thus, a lock in Mojo can be forced by the compiler to be explicit, and that prevents the Rust problem of https://fasterthanli.me/articles/a-rust-match-made-in-hell , since developers will have to explicitly destroy the lock in Mojo. C also does not have that temporary lifetime extension issue, since there is barely any temporary lifetime extension in C, apart possibly from compound literals, but compound literals might also have some issues and involved rules.

The edition system in Rust tripping LLMs up is not great either. That can happen because the same code in one edition of Rust can have very different behavior in another edition of Rust, like the same piece of Rust code having a deadlock in one edition and not in another.

Interesting, thanks for the links! I'm curious as to how many of the apparent issues are attributable to lifetime extension specifically as opposed to something else like async-related deadlocks as mentioned in the parent to the first linked comment (which I feel I've heard much more about), especially after the Rust 2024 changes.

That being said, after a bit more searching I found this 2023 blog from one of the Rust devs [0] which supports the "widespread" description at the time:

> One very common problem is deadlocks (or panics, for ref-cell) when mutex locks occur in a match scrutinee

so I think we can chalk this up to me being insufficiently well-read. I think it would be interesting to see to what extent the Rust 2024 changes alleviated the problem since it only changed if let, but I haven't found that information (yet).

There's also this related work [1], but I think the scope of that is rather larger.

> Interestingly, Mojo might avoid some or all of that, by having some destructors be implicit, and some destructors be explicit, [] , requiring users to write the destructors manually.

There's some relevant exploration being done in Rust that in principle could enable linear types [2], though obviously it remains to be seen to what extent this work will pan out.

[0]: https://smallcultfollowing.com/babysteps/blog/2023/03/15/tem...

[1]: https://blog.m-ou.se/super-let/

[2]: https://github.com/rust-lang/goals/blob/main/src/2026/move-t...

> I think it would be interesting to see to what extent the Rust 2024 changes alleviated the problem since it only changed if let, but I haven't found that information (yet).

The second link from Reddit, https://redlib.catsarch.com/r/rust/comments/1v54et2/what_are... , claims that some issues were made worse in practice in his experience by Rust edition 2024.

Regarding "super let", it looks interesting, but I am not sure about the details of it. This is the tracking GitHub issue https://github.com/rust-lang/rust/issues/139076 . There is also the challenge of backwards compatibility, which makes the feature harder to make good, I suspect.

> claims that some issues were made worse in practice in his experience by Rust edition 2024.

That begs the question of exactly what "some issues" encompasses. To me, the poster was clearly complaining about the increased use of a particular code pattern post-Rust-2024, but it's not clear to me that they were also claiming that there is a proportional increase in deadlocks post-Rust-2024. For instance, perhaps it's the case that people use that code pattern more because it doesn't deadlock; this may not be desirable from the commenter's perspective due to the multiple locks/unlocks, but that's a distinct issue from lifetime extension causing deadlocks.

> Regarding "super let", it looks interesting, but I am not sure about the details of it.

At least from a cursory skim it looks like the specifics are still being worked on, so it's hard to fault you for being unsure about the details. It is an experiment after all :P

Not sure about that.

Would you agree that one should optimize for the project / software, rather that optimize for any individual programmer on it?

> that

should be

> than

in your comment.

Aside that, I did not make any arguments either way regarding your question. But, I am not sure that your question makes sense in this context, for the developers that are available to a given project are generally part of the considerations for that project. For instance, if a company has a number of existing employees and are not in a position to attract new ones, the existing employees absolutely have to be considered, even ignoring any negotiation kind of stuff. Conversely, if a company has no current employees (like a newly minted startup) or is in a great position to attract lots of new employees, then the company at least has the option of selecting new employees to fit the rest of their goals and constraints. Though even in the latter case, considering existing employees can often make a lot of sense or be necessary.

For Canonical as well as the Linux kernel, I think I have heard arguments about attracting new developers by switching to Rust, and there has on the other hand been concerns regarding existing developers, not all of whom might be interested or experienced in Rust, some existing developers have complained in public. But there is a lot of know-how, expertise and domain knowledge independent of the language in both the Linux kernel and the software that Canonical handles or uses, and that knowledge and expertise are not necessarily easy to acquire quickly. And then there are all the borrow checker problems and other kinds of problems with Rust, making Rust, even for greenfield projects, less attractive. Rust does have nice pattern matching, though.

I believe that one should optimize for the needs of the business that uses the project/software. SaaS, Open Source and internally used proprietary software have different optimization parameters.

Reply on news.ycombinator.com