Our great sponsors
-
-
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.
-
-
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.
-
It's a mystery to me why people won't start using properly designed configuration languages, like Dhall (https://dhall-lang.org/) or Cue (https://cuelang.org/). Even using csexps (https://en.wikipedia.org/wiki/Canonical_S-expressions) would be progress.
It's a mystery to me why people won't start using properly designed configuration languages, like Dhall (https://dhall-lang.org/) or Cue (https://cuelang.org/). Even using csexps (https://en.wikipedia.org/wiki/Canonical_S-expressions) would be progress.
StrictYAML removes features that might be useful for some usecases, such as Node anchors+Refs and Flow Style.
I don't think the cost of an additional standard is worth it in this case.
While YAML has issues, they aren't much of problem if you use a linter, such as yamllint [1].
1. https://github.com/adrienverge/yamllint
this is a good idea, but difficult to nail in scope and multi-lang support. i’ve made similar attempts[1,2]. tbh if this had go support i’d probably try it today.
json, yaml et al are ways to declare literal data. this is good. they are fine.
the issues always come from what the data is used for. nailing your schema, making your data structures as simple as they can be and no simpler, this is where the engineering happens. this is the hard part. literally all that matters.
not validating arbitrary data inputs is obviously a bad idea. whether you validate them via a high level library or tediously by hand[3] isn’t very important.
what is important is that the data structures are sane, simple, and stable. if they are easy to describe, they might be a good idea. if the approach the complexity of general purpose pl, they probably aren’t.
most literal data schemas are too broadly scoped. too general. github actions, other ci, k8s, etc. they have too many knobs, too many permutations. this is not a feature, it is a failure of design.
1. https://github.com/nathants/py-schema
2. https://github.com/nathants/clj-schema
3. https://github.com/nathants/libaws/blob/ae48040911bf2c0554da...
this is a good idea, but difficult to nail in scope and multi-lang support. i’ve made similar attempts[1,2]. tbh if this had go support i’d probably try it today.
json, yaml et al are ways to declare literal data. this is good. they are fine.
the issues always come from what the data is used for. nailing your schema, making your data structures as simple as they can be and no simpler, this is where the engineering happens. this is the hard part. literally all that matters.
not validating arbitrary data inputs is obviously a bad idea. whether you validate them via a high level library or tediously by hand[3] isn’t very important.
what is important is that the data structures are sane, simple, and stable. if they are easy to describe, they might be a good idea. if the approach the complexity of general purpose pl, they probably aren’t.
most literal data schemas are too broadly scoped. too general. github actions, other ci, k8s, etc. they have too many knobs, too many permutations. this is not a feature, it is a failure of design.
1. https://github.com/nathants/py-schema
2. https://github.com/nathants/clj-schema
3. https://github.com/nathants/libaws/blob/ae48040911bf2c0554da...
this is a good idea, but difficult to nail in scope and multi-lang support. i’ve made similar attempts[1,2]. tbh if this had go support i’d probably try it today.
json, yaml et al are ways to declare literal data. this is good. they are fine.
the issues always come from what the data is used for. nailing your schema, making your data structures as simple as they can be and no simpler, this is where the engineering happens. this is the hard part. literally all that matters.
not validating arbitrary data inputs is obviously a bad idea. whether you validate them via a high level library or tediously by hand[3] isn’t very important.
what is important is that the data structures are sane, simple, and stable. if they are easy to describe, they might be a good idea. if the approach the complexity of general purpose pl, they probably aren’t.
most literal data schemas are too broadly scoped. too general. github actions, other ci, k8s, etc. they have too many knobs, too many permutations. this is not a feature, it is a failure of design.
1. https://github.com/nathants/py-schema
2. https://github.com/nathants/clj-schema
3. https://github.com/nathants/libaws/blob/ae48040911bf2c0554da...
That's fair. Please note:
> However, when you protect an import with a semantic integrity check the import is permanently locally cached after the first request, so subsequent imports will no longer make outbound HTTP requests.
Also this PR to nixpkgs from 2020: https://github.com/NixOS/nixpkgs/pull/79900
> Many users have requested Dhall support for "offline" packages ... The goal of this change is to document what is the idiomatic way to implement "offline" Dhall builds