Comment by K0nserv | Hacker News Reader

Comment by K0nserv | Hacker News Reader

The author makes the best argument for Rust in the linked post[0]

    Rust is great for teams because it removes many things that make working on team code dangerous. The items mentioned above are some.

    I work alone, however, because I like to keep my code in my head and working with people means parts of the code are only in their head.

    This also means that the bigger the language is, the less space I have in my head for the code.

    Rust is too big for my small brain, unfortunately.

Most code is written in teams and even software with a single author needs a plan for when the maintainer steps down. Besides this I disagree with the author's assertion that Rust is not well suited for them, in fact I think it's strictly better than C because it often obviates the need to keep stuff in your head. Take lifetimes, in C you have to keep track of pointers and their lifetime in your head, and by definition all other maintainers have to do the same, in Rust the compiler does that for you, less to keep in your head. In fact I think the ability offload things from your head to the compiler is one of Rust's great strength. This ties in with compile times too, yes Rust is very slow to compile, but the compiler also does a whole lot more work than the C compiler. Obviously we want rustc to be as fast as possible given the work it's doing, but it will never be as fast as a C or Go compiler.

0: https://gavinhoward.com/2023/02/why-i-use-c-when-i-believe-i...

"Most code is written in teams and even software with a single author needs a plan for when the maintainer steps down."

I strongly disagree! My experience is this:

1. Sole developer builds useful thing

2. Team takes over maintenance

3. Feature bloat, sluggishness, bugs ignored, Agile initiative, "Product owners"

4. Company goes bankrupt or gets acquired

I don't think you can have the clarity of vision that a single person will produce if you're working on it with a big team. That's why so many useful things start with a single person or a very small team, like Linux, Android, curl, ffmpeg, Quake engine, the 2 ppl Firefox "Phoenix" team, the original 3 ppl JetBrains team, the 2 original Photoshop devs.

> That's why so many useful things start with a single person or *a very small team*,

You subtly shifted the goal posts here. But even if you start out with a single person you eventually have to have new maintainers, if only because of human mortality. Software is a young field so we haven't had to contend much with this fact yet, but it's inevitable.

Personally I think something like Rust is helpful for large solo programs too, keeping everything in your head past 10kCLOC is hard so why not have a language and compiler that helps you?

My personal opinion is that Rust is a bit too lengthy to keep everything in your head. For a solo program, I'd probably go with Python first, just because it tends to produce very short and yet readable source code.

And yes, I shifted the goal post a bit by assuming the team to be medium to large in size. If I assume a very small team like the initial Photoshop release with 2 people closely working together every day, then I think their communication will be so good that there aren't "many things that make working on team code dangerous" left. So in that case, I wouldn't expect much benefit from using Rust.

> My personal opinion is that Rust is a bit too lengthy to keep everything in your head

I'm curious what you mean by "lengthy" here. The reason I say Rust lets me keep fewer things in my head is because something like this in C:

    struct Bar {};
    
    struct Foo {
        struct Bar *bar;
    };

where it's no clear if Foo owns Bar or merely outlives it, becomes

    struct Bar;
    struct Foo<'b> {
        bar: &'b Bar,
    }

in Rust and I no longer have to keep this information in my head.

Interesting, it's mostly concepts and architecture in my head, and less lines of code.

Ugh, seen this pattern happen many times at smallish companies. The O.G. codebase was written by a single person. It did one or two things very well, with few bugs, had consistent filenames, variable names, APIs, formatting, and so on, it had a single, pure vision throughout the code, and didn't have all those problems that happen when multiple people reason differently about the same code.

Then, eventually, the company gets bigger and the product needs to grow beyond the capability of one person, so a team starts developing on the codebase. That's where the bugs start pouring in, where everything becomes less consistent, where different design patterns are used all over the place, and where the "single clear vision" gets cast aside. A lot of problems that get blamed on "technical debt" and "brittle code" are often just plain coordination and consistency problems that are happening because multiple people can't share a single consciousness.

Reply on news.ycombinator.com