Thread by @Nick_Craver

Maybe I'm a minority opinion the way things are going, but I absolutely hate environmental variables for configuration. They're brittle, they're ambient, they can be changed and FUBAR any known state underneath you, they're an attack vector, just...ugh. I do not care for them.

The most common answer I get on "why?" is "that's the cross-platform way, everyone supports it".

Okay, yeah sure...I agree that we're at the least common denominator. My issue is settling for that. I don't think most things should. We can do far better. Options already exist.

I love the way .NET Core does this - IOptions is very pluggable and one of my favorite API designs because it fits so many scenarios, including complex deployment and multi-tenant things we have here.

It's defaulting straight to "make it an environmental variable" that gets me.

I've seen so bugs where a thing works forever but stops because some sysadmin somewhere deployed a GPO that sets an environmental variable deployed to many machines that silently changed behavior of apps that haven't been deployed in years, just happens on restart and...ugh.

That's just one example, there are many.

"It works on my machine" is a problem. Environmental variables magnify that problem immensely. They're a maybe permanent, maybe ephemeral, maybe local, maybe global external state that adds more to control, break, reason about, and debug.

"Why does this app work, but this one doesn't?"

"After 2 days of debugging we found out this one runs as account X with variables Y and it has the SDK path correctly set, the other one didn't have that variable"

"...I quit."