We at Cachix have also moved on from Haskell about two years ago and I'm sure someone is going to make a comeback with a language that takes the lessons from it but starts from skratch.
We need more general purpose Elm languages in the space.
Look at the problem statement, it's exactly the same. When I designed secretspec, I researched the space and no other tool approached secrets in such a way.
Syntax of toml is almost identical, the CLI as well.
It even has the same vocabulary.
I didn't dig deeper though, but I'd be surprised not to find more :)
I'll reply, even though I don't like the tone the first sentance sets :)
I'm not sure exactly what parts of the comment are about secrets rather than how infrastructure should be done, but I see that secrets and configuration have very different lifetimes so they should be provisioned separately. The config can for example be in the git if it's free of secrets.
Secrets are provisioned at runtime, while config is build time.
`secretspec.toml` is in the version control and it tells you all about what's going to happen at runtime.
I'm not advocating that different locations of secrets IS something we want, but rather it IS the sad state of reality.
By having a secrets specification we can start working towards a future that will consolidate these providers and allow teams to centralize it if needed, by having simple means of migrating from a mess into a central system.
- haskell exceptions and laziness are devastating for production
- too small ecosystem, had to write 10+ SDKs (now with AI that's less of an issue)
- haskell ecosystem is too fragmented due to prima donna prevalence