4 ms·

I agree there's some risk involved here, but the kind of thinking that you should stick to what you know can lead to stagnation. I much prefer the mental model

I agree there's some risk involved here, but the kind of thinking that you should stick to what you know can lead to stagnation. I much prefer the mental model of "capable engineers can pick up any language". Sure, it'll take time to learn these things, but it should not be a blocker.

akazantsev 2mo ago
> capable engineers can pick up any language Sure, given that they are getting paid for it. How many people will be interested in learning a programming language with insignificant job availability, in addition to contributing for free?
- Insanity 2mo ago
  I find that many people contributing to OSS projects tend to be the ones passionate about programming and also pick up new languages "for fun". That could be my bubble though.
  - akazantsev 2mo ago
    Demanding others to pick up Rust "for fun" is not fun at all.
    - Insanity 2mo ago
      It's the beauty of the OSS community. Someone will think Rust is fun, pick it up, and contribute. No one is _demanding_ it per se. If you don't like it, you just don't contribute anymore. I'm brushing over it lightly, I do understand this will impact people who were passionate about the project and now feel like they can't contribute anymore. Definitely an impact on an individual level. But that is, for better or worse, part of open source.
      - modularitynew 2mo ago
        Aren't some people paid to do contributions? As in, it is their livelihoods? Of Rust developers, like you, there are also some that get paid to contribute to Rust open source projects, for instance regarding the language itself.
modularitynew 2mo ago
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 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.
- andsoitis 2mo ago
  Would you agree that one should optimize for the project / software, rather that optimize for any individual programmer on it?
  - modularitynew 2mo ago
    > 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.

akazantsev 2mo ago

> capable engineers can pick up any language Sure, given that they are getting paid for it. How many people will be interested in learning a programming language with insignificant job availability, in addition to contributing for free?

Insanity 2mo ago
I find that many people contributing to OSS projects tend to be the ones passionate about programming and also pick up new languages "for fun". That could be my bubble though.
- akazantsev 2mo ago
  Demanding others to pick up Rust "for fun" is not fun at all.
  - Insanity 2mo ago
    It's the beauty of the OSS community. Someone will think Rust is fun, pick it up, and contribute. No one is _demanding_ it per se. If you don't like it, you just don't contribute anymore. I'm brushing over it lightly, I do understand this will impact people who were passionate about the project and now feel like they can't contribute anymore. Definitely an impact on an individual level. But that is, for better or worse, part of open source.
    - modularitynew 2mo ago
      Aren't some people paid to do contributions? As in, it is their livelihoods? Of Rust developers, like you, there are also some that get paid to contribute to Rust open source projects, for instance regarding the language itself.

modularitynew 2mo ago

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

andsoitis 2mo ago
Would you agree that one should optimize for the project / software, rather that optimize for any individual programmer on it?
- modularitynew 2mo ago
  > 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.