You’ll appreciate Rust the more you use it. Especially if you come from languages that do not have the same luxuries like Rust.
The type system and the safety guarantees that are enforced by the compiler are so pleasant to work with, I actually do not ever want to use any other language.
This is also one of the reasons why many companies are now choosing to use Rust. It is not just because it is new and “shiny”, but because it has real world benefits. Memory safety, for example. The tooling is also superb.
Yes, you will not be able to write at the speed a Python dev will write a project, but the rules and concepts Rust introduces are very worth it.
I think the importance table of Piefed demonstrates this pretty well:
These are good points. Memory safety for instance.
A lot of the priorities I presume are since PieFed has been new and it wanted to get out there and attract additional contributors. Once it approaches maturity, surely it could switch to e.g. moar reliability at the expense of agility?
(And I would sure hope that the 0 for testability has already been remedied, now that PieFed is no longer just running on a handful of test instances but is fully in production, deployed on many instances in many countries with thousands of accounts - very unlike when PieFed first got its start)
Lemmy already exists, and despite how many people talk trash about its being developed and run by tankies (e.g. on Reddit, where many refuse to join us here for that reason, although tbf that is only one of several, others being “it’s too complex” and “the user base is too toxic and/or focused on politics” and primarily “there’s too little content”), it does offer a fairly nice user experience. Therefore PieFed decided to be different, i.e. to occupy a different niche (with more features at the expense of less reliability). Ngl that can be quite frustrating at times, but also is quite neat to see as well.
Also the PieFed devs are super responsive to feedback - e.g. see this community https://piefed.social/c/piefed_2025 entirely dedicated to asking for populating the 2025 Roadmap (obviously at the end of last year:-). So if the user base wanted to see different prioritizations, I do believe that it would happen?
Once it approaches maturity, surely it could switch to e.g. moar reliability at the expense of agility?
Unfortunately, you can’t just “switch” to more reliability. That’s not how it works. Reliability is affected by the design and implementation of the software. If your software wasn’t reliable in the beginning, you’ll have lots of “fun time” rewriting and even more “fun time” debugging components to try and make it more reliable.
At some point, this is no longer practically viable and the unreliable parts stay as they are. Especially if the unreliability is a design flaw.
This is known as “technical debt”:
While an expedited solution can accelerate development in the short term, the resulting low quality may increase future costs if left unresolved.
However, failure to prioritize and address the debt can result in reduced maintainability, increased development costs, and risk to production systems.
Though I haven’t looked at how much the tests cover, there seems to be some sort of testing. So perhaps this importance table is a bit outdated indeed.
although tbf that is only one of several, others being “it’s too complex”
As I explained in my original comment, Rust has a few strict rules and concepts that force a particular discipline (I guess you could also call it style of code). And since it has those safety guarantees, you need to have things like lifetimes and trait bounds and such.
These things naturally make the code harder to read and/or complicated. But as I said, they are worth it and will save you many bugs that might occur at runtime (especially ones you do not want to debug at runtime. like concurrency bugs).
Unfortunately, you can’t just “switch” to more reliability.
For sure, I meant moving forward from that point on, but thanks for filling in the blanks.
At worst, if there was a large team of developers who had coded up the entire project in Python, but then certain sections needed to be re-written, let’s even stipulate that it would be in Rust, then it could still be a good thing to have gotten the project off the ground and made such progress, rather than have it be “perfect” but with barely anyone using it? “Don’t let perfect be the enemy of good” and all that? (Which could perhaps be used to justify some whoppers of bad decisions, so yeah, I’ll preemptively say when used judiciously, as in sometimes even if not always).
although tbf that is only one of several, others being “it’s too complex”
For clarity, when people on Reddit say this, I strongly believe that 99(.99?)% of the time they mean the entire concept of using a federated platform, even as an end-user. People, especially non-technical ones, can end up being remarkably… let’s just say “uncurious”, and highly resistant to change.
And yes, for many applications I agree that Rust is, if not fully superior to C++ then at least a better choice for an inexperienced programmer to choose to use. This article was enjoyable for me to read on that topic. But… that doesn’t make all other languages “wrong” choices, especially if dependent upon others for aid. And all the more so several years ago when that decision of language was made. Like, if the developer(s) simply enjoy using the language, then why not make the whole endeavor fun?
Also as others are pointing out, the existence of library support - notably Flask - is an even larger consideration than the language itself. That is, even if Rust were to be considered superior in virtually all other respects, having such a hard start could still be the deciding factor in favor of that vs. having to write everything from scratch?
You’ll appreciate Rust the more you use it. Especially if you come from languages that do not have the same luxuries like Rust.
The type system and the safety guarantees that are enforced by the compiler are so pleasant to work with, I actually do not ever want to use any other language.
This is also one of the reasons why many companies are now choosing to use Rust. It is not just because it is new and “shiny”, but because it has real world benefits. Memory safety, for example. The tooling is also superb.
Yes, you will not be able to write at the speed a Python dev will write a project, but the rules and concepts Rust introduces are very worth it.
I think the importance table of Piefed demonstrates this pretty well:
https://codeberg.org/rimu/pyfedi/src/branch/main/docs/ARCHITECTURE.md#desired-quality-attributes
You simply cannot have good reliability or security if you prioritize agility over everything. Same goes for scalability
Also why does testability have a priority of 0?
Lol it’s Java vs C++ all over again!
Guess every generation needs a bit of a fight or something?
These are good points. Memory safety for instance.
A lot of the priorities I presume are since PieFed has been new and it wanted to get out there and attract additional contributors. Once it approaches maturity, surely it could switch to e.g. moar reliability at the expense of agility?
(And I would sure hope that the 0 for testability has already been remedied, now that PieFed is no longer just running on a handful of test instances but is fully in production, deployed on many instances in many countries with thousands of accounts - very unlike when PieFed first got its start)
Lemmy already exists, and despite how many people talk trash about its being developed and run by tankies (e.g. on Reddit, where many refuse to join us here for that reason, although tbf that is only one of several, others being “it’s too complex” and “the user base is too toxic and/or focused on politics” and primarily “there’s too little content”), it does offer a fairly nice user experience. Therefore PieFed decided to be different, i.e. to occupy a different niche (with more features at the expense of less reliability). Ngl that can be quite frustrating at times, but also is quite neat to see as well.
Also the PieFed devs are super responsive to feedback - e.g. see this community https://piefed.social/c/piefed_2025 entirely dedicated to asking for populating the 2025 Roadmap (obviously at the end of last year:-). So if the user base wanted to see different prioritizations, I do believe that it would happen?
Unfortunately, you can’t just “switch” to more reliability. That’s not how it works. Reliability is affected by the design and implementation of the software. If your software wasn’t reliable in the beginning, you’ll have lots of “fun time” rewriting and even more “fun time” debugging components to try and make it more reliable.
At some point, this is no longer practically viable and the unreliable parts stay as they are. Especially if the unreliability is a design flaw. This is known as “technical debt”:
https://en.wikipedia.org/wiki/Technical_debt
As for the 0 priority of testability, I found a test directory in the repo: https://codeberg.org/rimu/pyfedi/src/branch/main/tests
Though I haven’t looked at how much the tests cover, there seems to be some sort of testing. So perhaps this importance table is a bit outdated indeed.
As I explained in my original comment, Rust has a few strict rules and concepts that force a particular discipline (I guess you could also call it style of code). And since it has those safety guarantees, you need to have things like lifetimes and trait bounds and such. These things naturally make the code harder to read and/or complicated. But as I said, they are worth it and will save you many bugs that might occur at runtime (especially ones you do not want to debug at runtime. like concurrency bugs).
For sure, I meant moving forward from that point on, but thanks for filling in the blanks.
At worst, if there was a large team of developers who had coded up the entire project in Python, but then certain sections needed to be re-written, let’s even stipulate that it would be in Rust, then it could still be a good thing to have gotten the project off the ground and made such progress, rather than have it be “perfect” but with barely anyone using it? “Don’t let perfect be the enemy of good” and all that? (Which could perhaps be used to justify some whoppers of bad decisions, so yeah, I’ll preemptively say when used judiciously, as in sometimes even if not always).
For clarity, when people on Reddit say this, I strongly believe that 99(.99?)% of the time they mean the entire concept of using a federated platform, even as an end-user. People, especially non-technical ones, can end up being remarkably… let’s just say “uncurious”, and highly resistant to change.
And yes, for many applications I agree that Rust is, if not fully superior to C++ then at least a better choice for an inexperienced programmer to choose to use. This article was enjoyable for me to read on that topic. But… that doesn’t make all other languages “wrong” choices, especially if dependent upon others for aid. And all the more so several years ago when that decision of language was made. Like, if the developer(s) simply enjoy using the language, then why not make the whole endeavor fun?
Also as others are pointing out, the existence of library support - notably Flask - is an even larger consideration than the language itself. That is, even if Rust were to be considered superior in virtually all other respects, having such a hard start could still be the deciding factor in favor of that vs. having to write everything from scratch?