> it seems like the holy grail to the config files dilemma is to just hard-code desired settings in the source code

That is…not remotely the holy grail. You’re really throwing out the baby with the bathwater on that one. User-configurable settings are important for many, many applications.

In the narrow case that you’re working on, say, a monorepo for closed-source code that only runs on your own servers, maybe in source code is fine provided there’s no host-level differences that would require a config file.

But for any other circumstance…yeah you need some type of configurability.

Even with a single company closed source monorepo, sometimes it’s useful to change settings without a restart and redeploy. And sometimes one runs more than one instance of the same code.

Why not both? You can write config-looking Kotlin code so that user won't even realize it's Kotlin. But type-safe and with auto-completion.

Something like

    server {
      port = 8080
      addr = "127.0.0.1"
      development = true
    }
    
    db {
      url = $DB_URL
      user = "app"
      password = include(".secrets/dbpass.txt")
    }

[delayed]

Not sure if I would call hardcoded settings in the sourcecode configuration - they are just constants. The primary benefit of configuration is the ability of changing the behavior of software without having to rebuild, redeploy, redistribute or even restart. Either by the user or by the developer or sysadmin, depending on context.