Our great sponsors
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
Pulumi
Pulumi - Infrastructure as Code in any programming language. Build infrastructure intuitively on any cloud using familiar languages 🚀
-
nickel-nix
Discontinued An experimental Nix toolkit to use nickel as a language for writing nix packages, shells and more. [Moved to: https://github.com/nickel-lang/organist]
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
Then, I guess it's the same question as why you don't embed a DSL inside an existing, well-established language (which is the approach of Guix), and isn't really that specific to using Guile. It's a different trade-off: I made some similar points in this GH issue. In general, the counterpart of embedding a DSL is poor tooling support (the LSP doesn't necessarily understand your DSL, the type system doesn't necessarily fit your DSL, etc.)
There's a popular web framework called Nickel already: https://nickel-org.github.io/
What I'm missing in Nickel is schema validation. With JSON schemas, you can specify exactly what shape the configuration file should have, and provide autocompletion and error highlighting in an editor. JSON schemas can also be used for toml and yaml.
What I'm missing in Nickel is schema validation. With JSON schemas, you can specify exactly what shape the configuration file should have, and provide autocompletion and error highlighting in an editor. JSON schemas can also be used for toml and yaml.
This sounds/looks a lot like dhall. Would you mind contrasting dhall vs. nickel?
For example, Pulumi is an interface for tool orchestrators that can be used from general-purpose programming languages. So instead of using Nickel, you can just use JavaScript, Scala or whatnot, and corresponds to the first choice, like Guix.
One target-use case of Nickel is to be used as an alternative front-end for Nix (instead of Nix expressions). There is a draft RFC and a repository to use Nickel to write development shell (Nixel). The goal is that, one day, you can actually just transparently call to Nix code and into Nixpkgs. Until then, I totally understand that nothing can be the power of levering Nixpkgs... so your approach makes sense :)