Raft itself - rather than any framework in which you would actually want to use it - is quite simple to implement. A few classmates of mine and I implemented a barebones Raft instance in about a weekend.
You can build a toy implementation in a weekend if you have a cookbook. A production-ready implementation takes a bit more.
Maybe out of scope for an undergrad are things like testing high latency/unreliable/jittery connections.
I used to follow Jepsen https://jepsen.io/ closely. Those tests are quite comprehensive. But I think even those are not sufficient to quantify the quality of Paxos/Raft.
Tools like TLA+ probably require a few months to learn and become proficient.
This happens every once in a while on HN: some mentions having done one of these assignments, and immediately gets tackled for it.
Maybe professors aren’t doing a good job conveying the limitations. But also this community is gratuitously hostile to people who have no reason to doubt that the code they wrote from the Raft paper, which passed the test suite, was Raft.
I really hope you read this gently. (As the HN guidelines say, "Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.") I'm not trying to talk down to you or treat you with hostility (and I know that it's really hard to convey that via text). I would just ask that when someone who has professional, real-world experience in something says it is difficult and time-consuming to do it right, you'd avoid assuming they just don't know what they're doing, and that perhaps there are aspects that you haven't considered.
And hey, maybe you or some of the other commenters are just ridiculously smart and focused and can write it in a weekend. But if that's the case, it's pretty uncharitable to push a narrative that it's trivial. Not saying that's what's happening here, but that could be how it's coming off.
If you feel confident you've built a complex algorithm like this correctly on the first try you probably haven't. Hubris and distributed systems just don't mix.
Verifying correctness to back up our empirical claims is often the hardest and most overlooked part of software engineering.
This is a proportionate response to an undergraduate trying to sell you his new RDBMS. But most students really did write a b-tree. Academic programming elides the supporting infrastructure that bridges the gap between algorithm and software system. Textbooks aren't generally leaving out 100 pages of extra steps required for the list to actually be sorted or the path to actually be shortest. And so a student is not exactly out of line for thinking that the Raft he was taught is actually consistent in the presence of failure. I'll defer to the community's wisdom that he's wrong! But he's still not out of line.
If anything, I'm worried about these classes instilling false confidence. People who think they know these algorithms may go implement them professionally, and not have anyone around to tell them the full story. Cryptography education is careful to put asterisks around "Textbook RSA." Distributed systems education should probably be doing the same.
Part of why the Raft paper is so excellent is because is does leave you feeling like you could explain/implement the algorithm. I don't want to discourage people from being excited about these ideas, because I am too.
That being said, I am generally frustrated by the lack of humility that many software engineers exhibit. "Easy" is a trigger word for me, and I really think is something that should be expunged from most of our vocabulary when referencing software.
this is almost independent with how hard is to build a (good) pure implementation of raft that offers a simpler API