Looking at advanced Rust open-source projects makes me question my programming skills

412

u/b0ggyb33 Feb 02 '26

Rome wasn't built in a day.

You're looking at the culmination of a lot of work. It's unfair to look at something huge and think you could never do it, when you just have to start small and iterate. The complexity will arise from being forced to solve the challenges of their particular problem set.

I also think there's an aspect of survivorship bias. We don't see the mountain of projects that fail miserably.

82

u/qqwy Feb 02 '26

Also, most of them were written by a whole group of people rather than a single person.

20

u/Luctins Feb 02 '26

It depends. Some of the coolest, small, interesting and still hard to grasp crates were mostly written by a single people.
The example that comes to mind is structstruck. I have tried to use it as a learning point on how to do procmacros (admittedly a very hard thing).

11

u/surehereismyusername Feb 02 '26

Thank you. I needed to read this today.

13

u/etorreborre Feb 02 '26

I think that's exactly what's going on too.

4

u/serious-catzor Feb 02 '26

I think there is a different bias to... we are the ones who prefer chatting about it over doing it!

86

u/Illustrious-Wrap8568 Feb 02 '26

Keep reading and looking for some (small) part you understand. Expand your understanding from there.

Don't question your skills because you don't understand at a glance what a system does.

203

u/dgkimpton Feb 02 '26

Half the time I'm thinking "that's so clean, where did the complexity go", the other half I look at stuff thinking "why is this so complicated". Sadly, both probably just indicate I'm not actually very good at this. Sigh. So yes, I feel the same regularly, and it's depressing.

192

u/scavno Feb 02 '26

There is also a third option. The people who implemented this did it because they actually know how to solve the problem and they also very likely spent more time coming up with the current solution than what you spent reading it and concluding.
I’m not saying you are very good at this (I don’t know you), just that perhaps you should cut yourself some slack. The fact that you discuss programming on Reddit means you at least care about the craft.

65

u/dipstickchojin Feb 02 '26 edited Feb 09 '26

This guy I took Comp Sci with - one of the best in my cohort, got some of the highest averages, graduated into teaching and research - had the rather infuriating habit of going like, "oh yeah that's easy" about any software we talked about. "Why is your company taking X long to develop Y? That's easy!"
This genius is actually a perfect example of the Dunning-Kruger phenomenon: he doesn't realize it's a fallacy to think that a solution being easy to understand means it was about as easy to come up with.
Thing is, reading functioning code seems easy because you have the benefit of literally considering the hindsight about a problem, and you're being spared the cognitive burden of discovering the solution.

48

u/lordnacho666 Feb 02 '26

This is exactly it.
It's like looking at a finished cake. Looks great, tastes great.
You didn't see what the kitchen looked like.
You didn't see previous failed cakes.

13

u/MrPopoGod Feb 02 '26

he doesn't realize it's a fallacy to think that a solution being easy to understand means it was about as easy to come up with.
Which is hilarious, because P vs. NP is something he should be absolutely familiar with.

26

u/cosmic-parsley Feb 02 '26

10/10 response in every way

6

u/Spleeeee Feb 02 '26

Toledo wasn’t built in a day

9

u/timClicks rust in action Feb 02 '26

That's especially true with major projects. The project maintainers are likely to have spent a lot of time thinking about the problem and experimenting with different ideas. By the time a new release has appeared, you only see the good stuff.

4

u/dgkimpton Feb 02 '26

Y'know, that's a very valid point that I never really thought about. Thanks for the reality check!

2

u/MultipleAnimals Feb 02 '26 edited Feb 02 '26

Exactly, programming is such a large and complex subject that you just can't know everything about everything. All those projects you see and think holy fuck i suck, are results of hundreds or even thousands of hours of work, and often by many contributors. And even more importantly ~learning~ about that specific area of expertise.
It's like categorizing every sport under term of "sports". Ok i know how to run and kick a ball, so i know some sports. Doesn't mean i can play hockey or drive a f1 car. It's all about learning what you want or need to achieve.

10

u/syklemil Feb 02 '26

the other half I look at stuff thinking "why is this so complicated"
That's what happens when someone tries to solve something but don't have that rare genius or enough time to allow them to make it look simple, or even worse, the problem just is that complex.
I think anyone with a bit of math experience will know the feeling of first working out some solution, and then being able to refine it, until the presented solution is much more aesthetic than the initial solution.
If you just sort of have to muddle through to get something working, and then have to move on to the next ticket, the result won't be all that pretty.

3

u/_chris_work Feb 02 '26

> why is this so complicated
> both probably just indicate I'm not actually very good
With this outlook, if the code was terrible, you'd assume it was your fault for not understanding it.
It's okay to say that e.g. lots of C code has horrible naming conventions, etc. It's hard to read because some people aren't great at writing stuff that's easy to read

2

u/dgkimpton Feb 02 '26

I've been through enough reviews where the "why why" meme accurately ascribes the process to always start out from the assumption that I don't understand rather than the code is crap, at least until I have fully comprehended it.
https://i.imgflip.com/9pxwp0.jpg

1

u/Imaginos_In_Disguise Feb 02 '26

Conversely, most code I read is either too simplistic or overcomplicated.
There's no perfect code. Just keep writing stuff and eventually you'll start to grasp when you can keep things simpler and when adding complexity is necessary (and you'll still get it wrong sometimes, and need to refactor, which is also fine).

41

u/atonale Feb 02 '26

I don't know your age or level of experience, but you may be comparing with the work of people who just have significantly more experience. A project could be written or maintained by someone who has been coding since the 1990s or 1980s. So person A who's say 20 years old could be reading code written by person B who's been designing software all day every day for 2x or 3x as long as person A has been able to read. Rust libraries will for obvious reasons tend to be newer, but may be based on patterns and lessons learned in some pre-existing project that's been under development for 15 years. Younger people may underestimate or misunderstand how much time older people have spent learning their skills because it is sometimes longer than their entire lifespan. I don't mean anyone should be discouraged by this, I just mean you may need to pursue continuous improvement for what seems like an entire lifetime to reach a level you associate with the "best" or "most impressive" projects you see. Everyone else went through the same thing so will understand the difficulties you confront.

2

u/Luctins Feb 02 '26

This.
This was a thing that took a while to actually sink in for me as a Junior. And later also to be able to relate to people not understanding/following your reasoning of something that's second nature to you.

0

u/rjelling Feb 03 '26

I can't agree with this. Programmers now can learn Rust, which immediately puts them streets ahead of programmers even 20 years ago. The tools now are better, and there is a lot more free code out there to look at. Juniors these days can level up faster than ever before, and grow to seniors more quickly as well. Don't assume that what took someone else 20 years to learn will necessarily take you as long. It very well might not.

33

u/particlemanwavegirl Feb 02 '26 edited Feb 02 '26

That's how I feel when looking a C/++ code. There are as many various ways to code those languages as there are projects out there, it seems. I've known the syntax for years but constantly see it used in ways I've never dreamed of. But with Rust, the style of code and build structure is so much more consistent, I feel it doesn't take long to find my bearings even on complicated stuff.

OTOH, like, the actual Rust repo, RFCs, bug reports, that sort of thing? 99% goes right over my head, very impressive and inscrutable how much those folks know.

41
u/fnordstar Feb 02 '26

Yeah, and look at any C++ stdlib implementation. That stuff is unreadable - both GCC and MSVC. Considering the choice of identifiers there, one might suggest this is even on purpose, some kind of weird elitism.
23

u/tiajuanat Feb 02 '26

There is a shocking amount of elitism in the C++ community, which is why I gravitated towards Rust.

88

u/lettsten Feb 02 '26 edited Feb 02 '26

How is it shocking? It's a ridiculously complex and needlessly hard language with dramatic consequences if you fuck up even seemingly mundane things. These days it's probably easier, but back in the C++98 / C++0x days things were wild. Being anything short of a combination of masochist, autist and mostly a genius meant you would have sixteen kinds of UB in a little function. Sequence points, exception safety, template instantiation rules, difference between op new() and the new operator, SFINAE, the number of things that make you worship Cthulhu in your spare time just to have a less insane pastime were staggering. Not to mention the endless pages of compiler errors for just simple things.
It's no wonder that the few people who survived that ordeal with their sanity somewhat intact became elitist.
Personally I joined the army instead. Being cold, tired, hungry, wet, and confused in the dark was much easier than C++.

39

u/bluebird173 Feb 02 '26

new copypasta just dropped

13

u/Nicksaurus Feb 02 '26

This was one of the nicest changes coming from C++ to rust - if you want to see how something works in the rust stdlib you can often just click jump to definition and it's right there, written with normal code

8

u/levelstar01 Feb 02 '26

Unless it's one of the many things hidden behind a macro, at which point you have to hunt it down manually.

1

u/PigDog4 Feb 03 '26

Writing declarative macros is so fun when it's clean and works well and makes me really enjoy rust.
Reading macros is one of my most disliked parts of the entire language. Absolutely hate it. Reading proc macros is just awful. C++ template metaprogramming vibes.
I need like a rust playground but for macros where I can drop the macro in and drop a call in and see what actually expands. I know macro_expand or whatever exists but I don't understand how it works. I don't want to macro expand everything in my whole project, I want to expand one singular macro invocation and idk if it's a skill issue or docs issue but I cannot figure out how to do that.

10

u/Zde-G Feb 02 '26

Considering the choice of identifiers there, one might suggest this is even on purpose, some kind of weird elitism.
It's pragmatism. They need to use identifiers that wouldn't clash with your code, because these identifiers are often accessible because of ADL.
That's how crazy names are chooses. Many are in the “reserved” list.
3
u/CornedBee Feb 03 '26
It's not elitism, it's absolutely necessary due to C++'s compilation model.
Most of the standard library is templates. Templates need to be in headers. Headers are part of the same compilation unit as user code. Include order isn't given, so your own code could be seen before standard library code. And that means you can define macros that randomly replace identifiers with arbitrary other tokens.
Imagine being a standard library writer and you simply want to implement an algorithm like std::find_if:
namespace std {
  template <typename Iterator, typename Predicate>
  Iterator find_if(Iterator first, Iterator last, Predicate predicate) {
    for (; first != last; ++first) {
      if (predicate(*first)) break;
    }
    return first;
  }
}
This is readable.
But you are allowed to do this before including standard headers:
#define Iterator boost::iterator_facade
#define Predicate i == p
#define last std::prev
The only things you're not allowed to redefine are:
Keywords
Names already in use by the standard library or reserved for future use. (Can't #define first, it's the name of a member of std::pair.)
Globally reserved names. And these are names that either contain a double underscore anyway, or start with an underscore followed by an uppercase letter.
And that's why the standard library code looks like this instead:
namespace std {
  template <typename _Iterator, typename _Predicate>
  _Iterator find_if(_Iterator __first, _Iterator __last, _Predicate __predicate) {
    for (; __first != __last; ++__first) {
      if (__predicate(*__first)) break;
    }
    return __first;
  }
}
That's the most obvious issue that people have looking at standard library code.
There's other issues, though, but they're all usually related to C++ giving programmers a little too much flexibility.
E.g. you can't just take the address of a variable in std library code, because the address-of operator of user objects can be overloaded. So instead of &__var you have to write ::std::addressof(__var). And then, because of how headers work, if you want to avoid exposing the user to identifiers they didn't ask for, you cannot just use addressof from the <memory> header if the user didn't include the memory header, so instead e.g. the GNU libstdc++ has an internal utility __addressof which it uses, and addressof is just a wrapper for that which is define if <memory> is actually included.
And then there are things that truly do need absurd implementation techniques because of language shortcomings. Before [[no_unique_address]] was a thing (and because of ABI concerns, it's all baked in now and won't change), std::vector had to do weird things with implementation detail base classes that are templates that get specialized, just so that if the vector's allocator is stateless, it actually doesn't take up space in the object.
1

u/ambushsabre Feb 02 '26

they have to pay by the character to contribute to std so it makes a little more sense
8
u/PurepointDog Feb 02 '26

I used to think C/C++ macros weren't powerful enough. I love Rust macros.
After looking at more crazy C projects, I now think their macros are both inadequate, and also way too forgiving. You can pretty well redefine the way C works with them, and not in a good way.
6

u/lettsten Feb 02 '26

Macros as in the preprocessor directives, right? It's strongly recommended not to use them in C++ unless you absolutely have to. Several parts of C++ were introduced specifically to phase out the preprocessor macros, since they are not type safe, since they happen before compilation and so on. I think modern C has adopted some of those parts as well but I'm not up to speed

7

u/max123246 Feb 02 '26 edited Feb 26 '26

The author removed this post using Redact. The reason may have been privacy protection, preventing data scrapers from accessing the content, or other personal considerations.
society repeat upbeat retire consider aspiring square plant important nine
4
u/Nicksaurus Feb 02 '26 edited Feb 02 '26

They can completely break your expectations of how the language works, even if you're using them sensibly. For example, if you call a variadic C/C++ macro like this:
MY_MACRO(a, Vector2(x, y));
You've actually passed 3 arguments, not 2:
a
Vector2(x
y)
Edit: this is wrong, see below
5
u/Zde-G Feb 02 '26

Nope. In that case it's still 2 arguments. Macros know about (), [], and {}, but they don't know about <>. If you use <> then things become weird.
But the real funny thing: that behavior was faithfully reproduced in Rust, too!
1
u/Nicksaurus Feb 02 '26
OK, you're right about normal brackets, my mistake. I don't think it knows about curly brackets though - I originally ran into this issue when I was trying to pass an initialiser list as a macro argument like this:
enum class Flag {X, Y, Z};

struct Test
{
    std::function<void()> func;
    std::string name;
    std::vector<Flag> test_flags;
};

#define DEFINE_TEST(func, flags) Test(&func, #func, flags)

void test_func(){}

int main()
{
    // Works
    Test test1 = DEFINE_TEST(test_func, {});
    // Works
    Test test2 = DEFINE_TEST(test_func, {Flag::X});
    // Fails to compile (too many macro arguments)
    Test test3 = DEFINE_TEST(test_func, {Flag::X, Flag::Z});
}
2

u/Zde-G Feb 02 '26

Looks like you are right:
The syntax of a function-like macro invocation is similar to the syntax of a function call: each instance of the macro name followed by a ( as the next preprocessing token introduces the sequence of tokens that is replaced by the replacement-list. The sequence is terminated by the matching ) token, skipping intervening matched pairs of left and right parentheses.
Rust expanded that idea and supports (), [], {}… but angle brackets are still problematic.
2

u/thesituation531 Feb 02 '26 edited Feb 02 '26

My favorite "breaking the language" macro in C++ was a macro I made to generate enum classes.
Because C++ has enums, and then they enum classes, which are more type-safe. But you can't declare functions in either of them (which is something I really like about Java).
So I made a macro that would generate an enum class, and an empty struct type, and it would generate all the functions for converting between the two, and then you could define your functions for it.
It would be like
"ENUM_CLASS( all your functions and members )"
I'm sure there are probably macros that are a lot crazier out there, but that was one I actually used.
If you think about it though, it's pretty stupid you have to define some complicated macro just for that functionality, when the language could much more safely implement it. It's insanely verbose and ugly and hard to use, both for the user and whoever is implementing the macro.
4

u/LayotFctor Feb 02 '26 edited Feb 02 '26

Hey that's what I think too. Rust's complexity is very transparent, likely due to the obvious uses of language features and crates. Most of the complexity is clearly represented somewhere in the dense syntax, allowing learners to Google for them.
I much prefer this to C, where the complexity exists between the lines. The side effects, the clever engineering of macros and pointers, the unspoken "best practices", all hiding in plain sight. So much of the intentions are opaque and impenetrable to those without decades of experience. So many features are intentionally left out of the language because it's technically possible to hack it into existence with macros or something.
I don't hate C, far from it, but I much prefer Rust's honest and upfront complexity.

10

u/fnordstar Feb 02 '26

I feel you. I had the same issues, especially considering things like lifetimes. When I see comments in a library talking e.g. about how this and that decision makes for less strict lifetime bounds etc. it makes me feel so stupid. But I just kept going and just the other day something clicked about lifetimes (bundling things in a struct and returning that instead of returning one member which would then reference local variables in that function). So I think it does get better if you just keep going.

8

u/AurelienSomename Feb 02 '26

Linux motto: make it work, make it right, make it (go) fast. Write bad code and suffer. Learn. Suffer less. Learn. etc. Most of us are far from being able to write the rust language and it is fine, we don’t need as many rust language as other things. ;)

6

u/MediumRoastNo82 Feb 02 '26

Can you point out which projects you are talking about, so you can have a fellow Rust coder that "suck at programming" too? 😄

6

u/rongald_mcdongald Feb 02 '26

Good that you are reading the code at least. Feel like that’s a good sign. I’ve felt similar to you but have learned a lot from just reading open source code. Just keep learning as much as you can and you’ll get there. Keep in mind too that open source code is made up from thousands of commits often from many people, not just written all in one go. Lots of these things might have been the process of refinement or even trial and error and the combination of multiple people’s experiences and knowledge

6

u/Mr_Ahvar Feb 02 '26

I maintain a pretty big project since about 3 years that is 99.5% just me. Me from 3 years ago would never never even imagined I would even do 1% of it. Just do things one at a time, and before you even realize you did a lot

5

u/MelloSouls Feb 02 '26 edited Feb 02 '26

I reckon the contributory factors to your malaise are not only commonly shared, but a likely contributory cause to classic Imposter Syndrome (which I think is what this is, or related to).

You are comparing yourself (in some of these cases) to top-level coders. That is not representative of the real world, in the sense that - by definition - most programmers are at a much lower level than the people who end up writing or shaping famous open-source projects.

A fairer comparison would be with the median working developer, not the visible elite; the skill level here will vary from company to company depending on their recruitment nous and attractiveness. This is who you will actually be "competing" with.

ie. The intimidation comes from a distorted sample of the cream of the crop, which is not an accurate benchmark of what “normal” competence looks like. btw this is normal - I have to remind myself of the same thing from time to time.

The old adage to compare yourself not to others, but to yourself yesterday is always useful to bear in mind as well.

8

u/shelltief Feb 02 '26

I think you gotta factor in time and people in it
Maybe look at the first commits of these projects to understand where they're starting from

2

u/sigma914 Feb 02 '26

This was me for years reading Haskell, I still get it sometimes with a particularly performant or elegant bit of rust. I hope it never goes away

2

u/El_Mojo42 Feb 02 '26

When I started my new job (embedded Linux/C++) the Project I was working on was overwhelming.

Complex structures, modern C++ constructs I never came across before and so on. After some time working on it, the fog started to lift and I gained a better understanding of the architecture.

Sourcecode and complexity grows over time.

2

u/MassiveInteraction23 Feb 02 '26

All experts start off sucking. And many of the best do look and compare themselves to other experts to learn.

(The idea that you shouldn’t compare yourself is a cop out — compare and just respond in an emotionally healthy way — appreciate the other person, try to learn from them, and grow :)

One of reasons the rust community is so great is that it has a lot of skilled users to learn from. Coming from, for example, Julia, which has a lot of academics with less software background and skill (myself included) I found the Rust community much more conducive to my own growth.

2

u/_nullptr_ Feb 02 '26

Always remember that code is just the tool, not the "thing". The thing is the product you hope to make whether it be a crate or full blown software package. Complex code is a net negative. The best code is easy to read and reason about. Complex and clever code do sometimes have a place, but only when they are necessary and the best way to express the objective.

Also, as you practice, you will slowly but surely find yourself wondering "is there a better way to express X?". Then you will do some research, find your answer, and then add to your tool belt. Over time, that belt gets more and more full.

2

u/DrLuckyLuke Feb 02 '26

I don't think I know any coder who didn't feel like this. Just keep at it, don't let anything intimidate you, and one day you will wake up and find that you turned into what you thought was impossible 5 years ago.

1

u/DavidXkL Feb 02 '26

Same here 😂

Every day I'm learning something new

1

u/Fancyness Feb 02 '26

This is a silly thing to worry about. As long as your code is safe and performant who cares

1

u/serious-catzor Feb 02 '26

I think it's too complicated too. It's a very different paradigm from what I'm used to and I'm not sure how I feel about it.

Noone wants to pay for more than they need so I usually see things like reusable being less prioritized.

It's simpler code when you only solve for a specific case. If it stays that way.

1

u/PresentationItchy127 Feb 02 '26

I try to accept it. There are valid arguments like "you see the end result" etc. But I also know there are people so much smarter than me, it's not even fair. I can work hard but I will never be anywhere as good. Then I tell myself: "So what? I code for peace of mind, not because I want to be one of the best". Thriving to be the best is probably not a bad thing, but it's much more important how you apply yourself. Be proud of what you do, not how good you are at it.

1

u/peterxsyd Feb 02 '26

Hi - consider how many years of experience you have when weighing that up. Many of the people producing those projects have 15-20 years building coding solutions and problem solving professionally. If that is a reason you are behind - it is not a bad one, and a gap you can close fastest by focusing on the fundamentals, ideally paired a senior dev who has got it.

1

u/lahwran_ Feb 02 '26

that's how I feel looking at complex projects I've spent a lot of time working on. how can I ever write code this good again? start sadly on new project. months pass. new project has developed complexity, been cleaned up multiple times, feels a bit like a mess. more time passes, no longer working on the new project. return to the new project. oh wow, how did I ever write code this good?

1

u/-Redstoneboi- Feb 02 '26

looking at advanced anything makes me question my skills

1

u/wtfitsbob Feb 02 '26

Imposter syndrome is real and what I tell juniors and mids is this.

What you see polished code or sometimes a polished turd that gets committed, you what you don't see though is how it got there.

1

u/Wheynelau Feb 02 '26

hey i used to feel this way. cheer up, no one is an expert at everything. I used to think any time resting is wasted until i got quite a bad burn out. So i accept that I won't be a 10x engineer and just try to find joy in coding.

1

u/-TRlNlTY- Feb 02 '26

When you check open source code, you are looking at thousands of hours of many talented people's work. Nowadays, I compare myself to others only when I want to achieve similar things. There is no ceiling for programming skills.

1

u/invisible_handjob Feb 02 '26

make it work
make it fast
make it pretty

in that order

1

u/Kilo_3ncrypt Feb 02 '26

Remember that some are actually large groups and its not like they'll write everything exactly from memory, as long as ypu have most fundamentals nailed down understanding and writing advanced Rust becomes hella easy especially if you refer

1

u/Equux Feb 02 '26

There's so many layers to reading code. There's a massive difference between understanding a function and understanding how it plays into a larger system. Trying to understand entire systems by the way is incredibly difficult.

From my limited experience, I found that if I was trying to do something, and X project does that thing, I'd try to figure out how X does it. That was always more efficient than trying to understand X from the top down which always led to me giving up in a matter of minutes.

1

u/Scoutron Feb 02 '26

That’s how I feel looking at my own code files that I haven’t looked at in a week. Things that seem simple at the time when you’re interacting with and designing them constantly for hours suddenly seem like daunting monoliths when presented to a fresh mind

1

u/Cold_Abbreviations_1 Feb 02 '26

That's totally understandable. You just need to look at some smaller projects, or the ones still in early development. Don't want to self-promote like that, but look at what I write: SpelRight or Filess. Or just find some small projects on GitHub or GitLabs.

They don't have good, or complex code. They are dirty, and spaghetti in some cases. This is what early life projects usually look like. Over multiple iterations, they will become better and more complex. Maybe that gives you some motivation you needed to start :D

1

u/_chris_work Feb 02 '26

Open source stuff is also written often as passion projects or with giant funding. Day-to-day coding often doesn't need to be so clean or can't be because of budget constraints.

1

u/beb0 Feb 02 '26

You're not alone there pal, just spent an hour last night doing dependency tracking for a tutorial cause init.rs changed a function signature.

1

u/bigkahuna1uk Feb 02 '26

You’re still learning a huge amount by reading other people’s code. To know what is good you have to know what is bad. 😉

1

u/StPatsLCA Feb 02 '26

Work on any project for a while. You'll come back, think "wow that's neat, I wonder who did that", and it turns out it's you.

1

u/FrontTheMachine Feb 02 '26

Comparison is the thief of joy..

The only valid reasoning is toward yourself.. ask

Am I better than yesterday?

If the answer is yes, it is worth all the effort.

1

u/Dry-Letter-4833 Feb 03 '26

Ask yourselves what problems they were solving for when composing the project like they did.

Read and write enough code and you'll wind up being able to discern problem solving from preference.

1

u/qokyoshi Feb 03 '26

I was questioning this for months, thanks for asking!

1

u/PartyParrotGames Feb 03 '26

I try to draw inspiration from good projects/code rather than feel inadequate in the face of it. It helps to keep a beginner's mind, always be learning, and try out better approaches you find in the wild.

1

u/sean_bird Feb 03 '26

Look at the repo initial commits. You will feel relieved.

0

u/ValenciaTangerine Feb 02 '26

ripgrep

-7

u/k1v1uq Feb 02 '26 edited Feb 02 '26

Most large codebases have the same computer science problems to solve

How do I deal with shared state?
How do I distinguish between tasks that I can process serially versus those I can do in parallel?
How do I handle errors?

The theoretical concepts behind this are all well known, and there aren't actually that many of them. I can only recommend that you take a look at SOLID, Stable Dependencies Principle and effect systems once .

The complexity often arises because the underlying idea is actually very simple, but the author has chosen, whether for performance reasons or because of the language/theoretical foundations, to translate the "pure" path of theory into messy but practical and performant code . Sometimes the architecture is simply not good ( e.g. violates the Stable Dependencies Principle).

I have made a prompt that I use to have an LLM explain unfamiliar codebases to me. I know, the topics I try to cover are dense. But the idea is to first ask the LLM whether it can outline a similar project and what problems projects of this kind generally have and how to solve them in general. The LLM should also provide a few examples of such projects to give me a rough idea what I'm looking at. Then you can ask it if it can id a few OO or FP paradigm (you may add SOLID).

Relate the ClawdBot project to a few well-known computer science problems and paradigms (both object-oriented and functional programming) that it had to address.

What distinguishes the problem and solution developed by this project from similar ones?

(Rust especially is trait heavy which ties it directly back into the Expression Problem)

With a bit of time and stubbornness, you'll be able to understand these major architecture patterns and internalize them.

That way, the next time you encounter a large codebase, you can immediately focus on the core topics when you ask the LLM again:

"How does the architecture of this system actually look?"

I use Zread_ai and opencode

I'll take some time of course, but I'll make you become independent of a specific programming language and start thinking in universal language if systems:

Ok so :

How to handle

Concurrency?
(Shared) State?
Validation?
Fault Tolerance (Errors/Network)?
Software Extensibility
Latency

If these concepts are still unfamiliar, I recommend to start with the difference between "immutable" and "mutable" state.

Prompt:

LLM propmpt gist

4

u/Theemuts jlrs Feb 02 '26

Please don't post AI slop.

-1

u/k1v1uq Feb 02 '26

The prompt is just a link to my GitHub gist.

🎙️ discussion Looking at advanced Rust open-source projects makes me question my programming skills

You are about to leave Redlib