[ajuc]

Static-everything is such a gimmick in my opinion. It sounds great until you try to do something useful with your code. It's almost never the case that people actually want to hard-code stuff in the source code.

Almost always you read configuration files at run-time (like sudo does) and change your behavior depending on run-time information - so you will have run-time errors.

[kstrauser]

“Static” here means that variables are const by default, and you can’t modify one without explicitly marking it as mutable.

In your case, a config object would be mutable inside the function that loads it from disk into memory, then read-only everywhere else by default.

[ajuc]

I use rust, and it does have static by default in many places (for example it's hard to do the traditional OOP virtual polymorphism or to keep objects of various types in one container) and it makes it pretty hard for me to write "nice" looking code.

It usually devolves into a lot of nested if-else and switch (match) instructions.

[kstrauser]

I haven't run into that so much myself. What I have run into is trying to write C-but-in-Rust, for which the compiler yells at me to please knock it off. It got way easier when I gave up and committed to doing things the Rust way.

Not saying you haven't done that, just sharing my personal experience with it.

[mtlmtlmtlmtl]

One of the habits I struggled to get rid of at first was the habit of making lots of things in structs refs for no reason, where it would be typical kn C for C reasons.

This led to a lot of unnecessary friction with the borrow checker while I was still getting to understand it.

Once I started always asking myself "does this really need to be a ref?", things became much easier. And this in turn revealed itself as a useful rule of thumb for keeping coupling between subsystem in check.

Then I was doing some C work and I realised I was asking the same question to myself about pointers too. And I found it could often reduce cognitive load down the line, because I'd end up in much fewer situations where I'd have to figure out "who should free this, and when?".

That's when I realised this cognitive load of keeping the borrow-checker happy was always there in C too. It was just more diffuse, and invisible until it blew up in my face. And when it did it was in the form in nasty runtime problems, not a helpful compiler error that happened before the code was even checked in.

[GTP]

If your program doesn't have a way of reloading its configuration at runtime, then even that first object created by reading the configuration from file can be immutable.

[kstrauser]

Yep! What I mean, though, is that the loading function itself will need to mutate the object as it reads settings from disk and updates the in-memory data structure. Once that's done, you can pass that around as a read-only object.