Problem: Trailing commas, key-quoting-rules, etc are a problem when generating JSON from scripts/templates - which is a key practical necessity for a Configuration language. Of course, you may already disagree here and say you don't have this problem, but it's a sufficient problem for everyone that there are many attempts to solve it. If you don't have this problem, feel free to ignore.
MAML: Takes JSON, makes trailing commas & key-quoting optional. One may not like it, but it does indeed solve the scripting problem, and it's a nice and novel idea. Thereby it's a "Superset" of JSON. All JSON is valid MAML, but all MAML is not valid JSON.
JSONNet: Also a good attempt, directly solving the scripting problem with built-in functions and so on. But can be overwhelming.
What's not explored and I'd love to see: A strict "Subset" of JSON. Every value MUST end with a comma, whether it's first or last. Every key must be quoted. Comments MUST be a valid JSON key-value called ".comment" that will be ignored at parsing but otherwise part of the JSON.
I understand trying to improve popular technologies that have issues, but for a text format with mass ubiquity, JSON has very little wrong with it to the point where I believe that projects like this are a profound waste of everyone's time.
I am all for people experimenting and making things they like, but a domain was purchased so I can only assume a serious intent to make something of this and my only reaction is that I hope this is not taken seriously and disappears.
That's because MAML is a superset of JSON. It has some added features (comments, multiline strings, etc), but it will likely be confused for JSON upon first glance. MAML will also have to reference JSON implementations to resolve ambiguities, e.g. how to handle multiple identical array keys. So MAML can not live outside the JSON world.
No way to confuse with JSON, where you would instead expect // or /* */ for a comment facility which align with Javascript.
Also """ for multiline string, I only encountered that in Python. But apparently Java, Kotlin and Swift also do that now. In js, backquote already do the trick.
And the project is targeting more on configuration file, where TOML or YAML indeed are already competitors just as historically valid as JSON.
Douglas Crockford addressed this many years ago: write your human readable config with comments and run it through a pre-processor to strip them out before handing the config to a JSON parser. Seems like almost no one picked up on the idea.
Pardon my naming nitpick and lack of commentary on any technical aspect, but I don't think this is a markup language. What is being marked up? HTML is called that because it's marking up text with like bold and italics and font and color and paragraphs and stuff.
To be fair, YAML's creators had the same misunderstanding. Compare:
Also not abstract. To be ‘abstract’, a language must combine several objects ‘under one umbrella’. Depicting different things in the same notation is the opposite of abstract. YACCANL (Yet Another Cargo-Cult Abstraction Non-Markup Language).
Abstract is an abstract word. Your interpretation is just one of the possible meanings. You could argue that this language is abstract because the data has no intrinsic meaning.
Yeah but then the argument dissolves into the sea of absurdity. We can (and should) assume at some level there's another intelligent being on the other end that we're communicating to.
But XML was designed as a markup language. That is was often used for configuration is not its fault. (And it works much better for its original purpose, where the otherwise strange distinction between attributes and child nodes actually makes sense.)
MAML seems to be designed as a configuration language, but calls itself a markup language. (YAML did too, but they changed it at some point.)
> Yes, the hint is in the name:
> Extensible Markup Language
Thats not an helpful answer when the reason for this discussion is whether MAML, another document format with the term “Markup Language” in its name, is also a markup language. ;)
Your parent comment (hnlmorg) already knows that "ML" in MAML is a misnomer. They are explaining why your grandparent comment (AdieuToLogic) does not explain very well why XML is a markup language but MAML isn't.
Your GP comment says that XML has markup in the name so that's a hint that XML is a markup language. Well... so does MAML. But we all agree that MAML is not a markup language. So we can't just say that XML is a markup language because the hint is in the name. By that logic, MAML would be a markup language too but it isn't. We need a stronger argument to explain why XML is a markup language and MAML is not. Like XML can markup content but MAML cannot markup anything. That was your parent comment's point.
This whole subthread has become an example of arguing for the sake of arguing. The messages in this subthread are correct on their own but missing the point of the parent comments.
The author of this language seems to have responded with AI-generated arguments in response to all questions linked in the FAQ section. This does not inspire much confidence for the design of the language.
Really, I do not see the point of this. These configuration languages are just different syntaxes for expressing the same fundamental data, bearing the same semantics. It would be much more interesting to see a language which experiments with what is fundamentally representable, for example like how the Nix language supports functional programming and has functions as a first-class data type.
I started experimenting with Cue https://cuelang.org/ (for Kubernetes mostly, though I also used their tasks features) and it is wonderful!
If you squint it looks and works like a functional programming language, but instead of actually being one (like Dhall for example) it simply looks like configuration : keys and values.
The "types are values" and "values defined multiple times must unify" rules are really simple, and enable easy comprehension of what's happening and are powerful enough without it being a full blown programming language.
In a way it kinda reminds me of the TypeScript structural type system in the ways you manipulate types like values, which I like as well.
It is truly wonderful. I do think they are missing a clear winner use-case so currently at our company colleagues don't see a clear benefit yet. Though if you take all use-cases where we use yaml or json now, and you'd get a pretty coherent way of working with config. But it's hard to phantom for non-coders and hard to communicate for coders why it's worth the effort for the non-coders.
> These configuration languages are just different syntaxes for expressing the same fundamental data, bearing the same semantics.
This is my complaint too. However, they do add a proper integer type, which is the only thing that they do change with the data, as far as I can tell.
> It would be much more interesting to see a language which experiments with what is fundamentally representable
DER (and TER, which is a text format I made up to be compiled into DER (although TER is not really intended to be used directly in application programs); so TER does have comments, hexadecimal numeric literals, and other syntax features) does support many more data types, such as arbitrarily long integers, ASCII, ISO 2022, etc. My own extension to the format adds some additional types, such as a key/value list type and a TRON string type; the key/value list type is the only nonstandard ASN.1 type needed (together with a few of the standard ASN.1 types: sequence, real, UTF-8 string, null, boolean) to represent the same data as JSON does.
> for example like how the Nix language supports functional programming and has functions as a first-class data type.
For some applications this is useful and good but in others it is undesirable, I think.
> It would be much more interesting to see a language which experiments with what is fundamentally representable
You might checkout my project, Confetti [1]. I conceived of it as Unix configuration files with the flexibility of S-expressions. I think the examples page on the website shows interesting use cases. It doesn't have a formal execution model, however, for that you might checkout Tcl or Lua.
In practice, there are still types, they are just validated by your application. I didn’t want Confetti itself to make assumptions. I wanted to give you the freedom to define your own custom types and keywords, like “on” and “off”, or even tri-states like “yes”, “no”, “maybe”.
The problem with mandatory keywords, like “true” and “false”, is they box you into the English language. And which data types should be intrinsic is arbitrary, for example, TOML has data types for date and time, but JSON does not [1]. Where do you draw the line? Confetti let’s you decide.
You might enjoy reading this take on the subject [2].
> AI-generated arguments in response to all questions
There are currently two items in the FAQ. While the first one seems to be formatted with AI (I don't know if the arguments are AI generated though, how do you tell?), the other certainly doesn't look AI-generated: https://github.com/maml-dev/maml/issues/3#issuecomment-33559...
The person who opened the issue specifically complained about getting an AI-generated reply before closing it. If you view the edit history for the message, or the language author's second response, you will see that the reply was edited afterhand to not be transparently sloppy.
After the edit in the second question, it’s clear the author’s command of English is not that great, so they used AI as grammar correction.
Unfortunately this is becoming more and more common, even here in HN; I don’t think non-english speakers doing this realize how obviously ChatGPT-ish the results are, and how much of its own “thoughts” it injects into the text.
Yes! Everyone thinking of a new config language should look at jsonnet first. And there are much bigger reasons (than just syntactic stuff) hidden in the "interesting things" part.
The "interesting things" include being (or at least aiming to be) the solution to the following problem:
"I need to configure ~200 tasks for each of 7 services in 5 datacenters where some stuff is dependent on DC, some on (service+DC) combination and also some machines where the jobs run need per-machine config overrides.
I want to avoid manual copy-paste-modify and I want to avoid the hell of generating configs from a Turing-complete language"
Optional unquoted keys. Basically, a superset of JSON, fixing the most annoying warts of the format - most annoying, because most gratuitous, in that it would have cost nothing to have those obvious features and yet would have greatly increased usability. I like it a lot, it's just a very pragmatic approach to improving JSON compared to creating a brand-new language like YAML and a slew of other contenders seemingly vainly try. I wish the name and presentation would better reflect this. Something like FJSON (Fixed JSON) or JSONF (JSON Fixed) or some other name which makes it clear this is an extended JSON, not yet another language, to avoid the confusion which already has engulfed the comment section here.
Each time something is optional, by definition, there is more than one way to do it. I much more prefer opinionated way, so it is consistent.
It is precisely why I like linters, so instead of a few ways to go, I pick one and stick to it. More focus on the content and less on things that do not matter.
Hmm, that's just "another link from someone who uses HN as a bookmark service". User started this self-service at the end of last year. With now 60+ submissions in the last two weeks. We can expect more interesting topics.
This is basically JSON for humans. YAML is harder to use due to significant indentation (easy to mess up in editors, and hard to identify the context), and TOML isn't great for hierarchical data.
It addresses all my complaints about JSON:
> Comments
> Multiline strings
> Optional commas
> Optional key quotes
I wish it was a superset of JSON (so, a valid JSON would also be valid MAML), but it doesn't seem to be the case.
EDIT: As I understand, HCL is very similar in terms of goals, and has been around for a while. It looks great too. https://github.com/hashicorp/hcl/
My experience is different: TOML isn't obvious if there's an array that's far from the leaf data. Maybe that's what you experienced with the hierarchical data?
In my usage of it (where we use base and override config layers), arrays are the enemy. Overrides can only delete the array, not merge data in. TOML merely makes this code smell more smelly, so it's perfect for us.
I believe every ambitious programmer makes a configuration language at some point, but most either keep it to themselves.
When I was a teen I made something called Nabla:
* XML-like syntax
* Schema language
* Compact binary representation
* Trivial parser for binary representation
* Optionally, simple dynamic programming language on top
Initially made it for my 3d engine scene serialization format, but then used everywhere some non-trivial data format was needed (e.g. anything with nested data structures).
I see the negativity in some comments, but I have to say: just because we have a format that works we don't have to suffer it's slightly annoying problems for eternity.
This is a format that's very well defined, good decisions where to be flexible (quoted keys) and when to be strict (no leading zeroes, no leading plus sign, error when integer parsing can't be precise, defining all corner cases in strings).
For almost all of these, I remember cases when something went wrong (or was just annoying) in another format.
Yes but. How would you express NaN or infinities or even precise floating-point (the reason hex float exist) in this format? That breaks interchange if you cannot save/restore floating-point as in the save.
I admire the effort to fix things too. But this is exactly how we end up with 15 competing standards (https://xkcd.com/927/), each a little different, and no one can tell which library or package can parse which format any more.
I'm also not convinced that the small usability benefits of these alternative formats outweigh the burden of stumbling across them in different projects and then having to remember which parser works with which format.
If I had to choose between living with one canonical, well-established format like JSON and a jumble of 15 incompatible formats, I’d choose the single, well-established one every time.
Colons separating key and value pairs enhance readability in my book, so KDL goes too far for me. Other options are JSON5 (https://json5.org/) and CUE (https://cuelang.org/docs/introduction/). The latter is maximalist rather than minimalist, but very well thought out and worth checking out.
Really it's quite logical that the next iteration of these configuration languages be this style, remove superfluous and annoying quotes, handle comments and maybe allow trailing commas.
I love that in the end, everything still comes down to using bash (and env vars), because for all its footguns and strings, it's still the most reasonable choice when giving up on the zoo of newer formats. I expect it to outlive us all, like our unergonomic keyboards, and having to deal with null values.
Why are they optional? Why not just make them mandatory? So I don't need to guess which chars need quotes.
Edit:
What most languages also lack: semantics on de-serialization. In the best case, I want to preserve formatting and stuff when the config is changed/re-committed programmatically.
Thanks for reminding me that I always wanted to create an alternative to JSON/YAML, so after your post, I got down to work, and this is what came out: https://vzparse.xyz/
I like it a lot: a superset of JSON, fixing the most annoying warts of the format - most annoying, because most gratuitous, in that it would have cost nothing to have those obvious features and yet would have greatly increased usability. It's just a very pragmatic approach to improving JSON compared to creating a brand-new language like YAML and a slew of other contenders seemingly vainly try. I wish the name and presentation would better reflect this. Something like FJSON (Fixed JSON) or JSONF (JSON Fixed) or some other name which makes it clear this is an extended JSON, not yet another language, to avoid the confusion which already has engulfed the comment section here.
Because it IS json with some half-assed enhancements. I say half-assed, because it only seems to work one-way. Parsing this is OK, probably not the most efficient json-parser around, but writing back and preserving the enhancements seems not supported, at least not in the python-implementation.
I've never had a need for comments that `{ "comment": "Hello, world" }` couldn't solve. Dangling commas would be nice, but between my auto-formatting editor and `JSON.stringify()`, they're never an issue either.
The best multiline strings are those where you can have proper indentations without having to guess how indentation is handled. bonus points for making nesting easy and making copy-pasting work without breaking indentation.
To my knowledge only Zig's multiline strings work this way
okaay, I get that you want the indentation to work (ironically this is more important when you are multilining a Python code example), but having to manage all the \\ is a pain in the butt
> ironically this is more important when you are multilining a Python code example
And neither seems to be a great use case for configuration. A markup language, sure, but I'm not sure I see a significant need for multiline strings (even in general) in a config file.
Yes, the evolution of Raku multilines is from shell (heredoc) > perl > raku, and a LOT of experience went into the design. Not sure I understand why that's a bad thing?
Some benefits of the Raku solution are:
- multiline is just a superset of the standard quoting method (with the "to:/CLOSER/" adverb)
- indent level is set by the left edge of the closer, in the example 'END' ... so you can consistently indent / unindent your source and do not have to crowd all your heredoc to the left margin
- you can pick any delimiter or closer to avoid conflict with the text content
- there's a large selection of quoting adverbs - q (like single quotes), qq (like double quotes), qw (quote word), qx (shell quoting), etc.
This usually means that any text can be cut and pasted as is into the multiline and you can adjust the adverbs to match the original quoting pattern.
Even with perverse patterns (which you cannot guarantee against in variable text), there is a way to gracefully handle:
While JSON kind of sucks as a configuration language, it's already there and I don't think it sucks enough for me to care to use anything else. Not having trailing commas or comments is annoying, but unless you're the config file for a web server or something, I'm cool with JSON.
They fix some of the problems with syntax of JSON but do not fix most of the problems with the data model; the only thing they do fix is that now there is a integer type. It still has the other problems, e.g. it still uses Unicode and still requires keys to be strings. For a configuration language, it can also be useful to have a application-specific data.
When this was first posted a couple of weeks ago by the spec's author, I took it as an opportunity to see how quickly I could spin up an IntelliJ language plugin since the last time I worked on a language plugin was pre-GPT (Klotho Annotations - basically TOML inside of @annotations inside comments or string literals in a variety of host languages). Back then, it took a week for me to figure out the ins and outs of basic syntax highlighting with GrammarKit.
This time around, I worked with Claude Code and we basically filled in each other's knowledge gaps to finish implementing every feature I was looking for in about 3 days of work:
Day 1:
- Plugin initialization
- Syntax highlighting
- JSON Schema integration
- Error inspections
Day 2:
- Code formatter (the code style settings page probably took longer to get right than the formatter)
- Test suite for existing features
Day 3:
- Intentions, QuickFix actions, etc. to help quickly reformat or fix issues detected in the file
- More graceful parsing error recovery and reporting
- Contextual completions (e.g., relevant keys/values from a JSON schema, existing keys from elsewhere in the file, etc.)
- Color picker gutter icon from string values that represent colors (in various formats)
I'm sure there are a few other features that I'm forgetting, but at the end of the day, roughly 80-85% of the code was generated from the command line by conversing with Claude Code (Sonnet 4.5) to plan, implement, test, and revise individual features.
For IntelliJ plugins, the SDK docs tend to cover the bare minimum to get common functionality working, and beyond that, the way to learn is by reading the source of existing OSS plugins. Claude was shockingly good at finding extension points for features I'd never implemented before and figuring out how to wire them up (though not always 100% successfully). It turns out that Claude can be quite an accelerator for building plugins for the JetBrains ecosystem.
Bottom line, if you're sitting on an idea for a plugin because you thought it might to take too long to bootstrap and figure out all the IDE integration parts, there's never been a better time to just go for it.
I wouldn't say it's the most readable. Values can be ambiguous, YAML anchors are powerful but complicated, and using indentation to define structure means that you're never quite sure to which node something belongs to. And good luck hunting down weird errors if you mistakenly screw up the indentation.
YAML is also often abused as a DSL and for very large documents (Ansible, k8s, GH Actions, etc.), which makes it a pain to work with.
It's not so much that liking all of this is controversial. It's just a bad opinion. :p
Oh yay, just what we need, ANOTHER one of these. Did the YA in YAML not already give a clue? Now there are 15 competing standards. Please make it stop. S-expressions were all that we wanted in the first place.
According to wikipedia “There are many variants of the S-expression format, supporting a variety of different syntaxes for different datatypes.”
Using parentheses instead of curly braces is fine by me, but it doesnt seem to solve the issue of syntax bikeshedding.
The fundamental problem is “configuration” is a huge area, from simple key-value lists to complex declarative languages. And you want the format to be both easy to read and edit for humans and simple to parse and process for computers. No single format will be perfect for all use cases, but perhaps a compromise can be found which is good enough for most cases.
If you are writing a software system that needs potentially human edited config files, yaml is the best for human edited files if you, software architect, use a footgun less parser.
Yaml is popular like python because indentation as a scope depth indicator is far more visually intuitive for low skill programmers than braces (c,json) or counting/matching parents in lisp or begin end tags in xml.
Sorry your kubernetes ecosystem didn't do that. Why not get them to change parsers? A hell of a lot easier than changing k8s to toml or maml.
Because ultimately that's what the frustration of yaml comes from, right? Kubernetes config?
Working with Terraform, and needing to handle the complexity of our per-client deployments at work, I ended up creating a bash layer that takes N number of JSON files, performs a deep merge, and spits out a .tfvars file.
As you’ve said, all I did was fork a JSON.stringify function and swap colon for equals.
Anyone have a better solution they’ve worked with?
Edit: Why the downvotes? Terraform is using HCL? Are we talking a different HCL here?
You can directly pass JSON to Terraform by putting it in a `.tfvars.json` file [1], as far as I can tell this has been supported since v0.5.0 which released in May 2015.
Terraform doesn't have a built-in deep merge function, but it will merge `.tfvars.json` files in the order given on the CLI, if you specify multiple `-var-file` arguments. For what it's worth, as of Terraform 1.8, you can also use functions from third-party providers like isometry/deepmerge [2] to perform a deep merge.
This looks pretty good but also JSON5 is perfectly fine, it just needs more support from libraries and IDEs. Adding another format is just going to make that problem worse. And nobody is going to use this format either because it also has poor support from libraries and IDEs.
Am I missing something or is this literally just Ruby? Like - it doesn’t list Ruby as a supported language, but, it also looks like fully executable Ruby code?
Problem: Trailing commas, key-quoting-rules, etc are a problem when generating JSON from scripts/templates - which is a key practical necessity for a Configuration language. Of course, you may already disagree here and say you don't have this problem, but it's a sufficient problem for everyone that there are many attempts to solve it. If you don't have this problem, feel free to ignore.
MAML: Takes JSON, makes trailing commas & key-quoting optional. One may not like it, but it does indeed solve the scripting problem, and it's a nice and novel idea. Thereby it's a "Superset" of JSON. All JSON is valid MAML, but all MAML is not valid JSON.
JSONNet: Also a good attempt, directly solving the scripting problem with built-in functions and so on. But can be overwhelming.
What's not explored and I'd love to see: A strict "Subset" of JSON. Every value MUST end with a comma, whether it's first or last. Every key must be quoted. Comments MUST be a valid JSON key-value called ".comment" that will be ignored at parsing but otherwise part of the JSON.
I understand trying to improve popular technologies that have issues, but for a text format with mass ubiquity, JSON has very little wrong with it to the point where I believe that projects like this are a profound waste of everyone's time.
I am all for people experimenting and making things they like, but a domain was purchased so I can only assume a serious intent to make something of this and my only reaction is that I hope this is not taken seriously and disappears.
Plus it hyperfocuses and compares to JSON, but there's many popular configuration languages that should be compared with as well like YAML, TOML, etc.
That's because MAML is a superset of JSON. It has some added features (comments, multiline strings, etc), but it will likely be confused for JSON upon first glance. MAML will also have to reference JSON implementations to resolve ambiguities, e.g. how to handle multiple identical array keys. So MAML can not live outside the JSON world.
> MAML will also have to reference JSON implementations to resolve ambiguities, e.g. how to handle multiple identical array keys
Isn’t the spec (https://maml.dev/spec/v0.1), which says “Duplicate keys are not allowed within an object.” sufficient for that?
Or am I misunderstanding what you mean by “array keys”?
It seems the spec is silent on whether key order is significant in dictionaries, though.
> Ordered objects (keys have a defined order)
https://github.com/maml-dev/maml/issues/1
No way to confuse with JSON, where you would instead expect // or /* */ for a comment facility which align with Javascript.
Also """ for multiline string, I only encountered that in Python. But apparently Java, Kotlin and Swift also do that now. In js, backquote already do the trick.
And the project is targeting more on configuration file, where TOML or YAML indeed are already competitors just as historically valid as JSON.
JSON with comments would go a long way
Douglas Crockford addressed this many years ago: write your human readable config with comments and run it through a pre-processor to strip them out before handing the config to a JSON parser. Seems like almost no one picked up on the idea.
Use Lua tables. Lua's parser is smaller than many JSON parsers, the syntax is almost the same and you can use comments.
> Minimal Abstract Markup Language
Pardon my naming nitpick and lack of commentary on any technical aspect, but I don't think this is a markup language. What is being marked up? HTML is called that because it's marking up text with like bold and italics and font and color and paragraphs and stuff.
To be fair, YAML's creators had the same misunderstanding. Compare:
https://yaml.org/spec/history/2001-12-10.html
https://yaml.org/spec/history/2002-04-07.html
Also not abstract. To be ‘abstract’, a language must combine several objects ‘under one umbrella’. Depicting different things in the same notation is the opposite of abstract. YACCANL (Yet Another Cargo-Cult Abstraction Non-Markup Language).
Abstract is an abstract word. Your interpretation is just one of the possible meanings. You could argue that this language is abstract because the data has no intrinsic meaning.
Yeah but then the argument dissolves into the sea of absurdity. We can (and should) assume at some level there's another intelligent being on the other end that we're communicating to.
Wow, wasn't aware (or simply never noticed) the name change. I was still calling it yet another...
Is XML a markup language? Because it was often used for not that too.
Occasional misuse doesn't change its nature. It seems as if MAML cannot be used as a markup language.
But XML was designed as a markup language. That is was often used for configuration is not its fault. (And it works much better for its original purpose, where the otherwise strange distinction between attributes and child nodes actually makes sense.)
MAML seems to be designed as a configuration language, but calls itself a markup language. (YAML did too, but they changed it at some point.)
> Is XML a markup language?
Yes, the hint is in the name:
0 - https://en.wikipedia.org/wiki/XML> Yes, the hint is in the name: > Extensible Markup Language
Thats not an helpful answer when the reason for this discussion is whether MAML, another document format with the term “Markup Language” in its name, is also a markup language. ;)
MAML is configuration format, not a document format, which is why the “ML” in its name is a misnomer.
Your parent comment (hnlmorg) already knows that "ML" in MAML is a misnomer. They are explaining why your grandparent comment (AdieuToLogic) does not explain very well why XML is a markup language but MAML isn't.
Your GP comment says that XML has markup in the name so that's a hint that XML is a markup language. Well... so does MAML. But we all agree that MAML is not a markup language. So we can't just say that XML is a markup language because the hint is in the name. By that logic, MAML would be a markup language too but it isn't. We need a stronger argument to explain why XML is a markup language and MAML is not. Like XML can markup content but MAML cannot markup anything. That was your parent comment's point.
This whole subthread has become an example of arguing for the sake of arguing. The messages in this subthread are correct on their own but missing the point of the parent comments.
The "ML" in "XML" stands for Markup Language!
As it does in MAML.
The author of this language seems to have responded with AI-generated arguments in response to all questions linked in the FAQ section. This does not inspire much confidence for the design of the language.
Really, I do not see the point of this. These configuration languages are just different syntaxes for expressing the same fundamental data, bearing the same semantics. It would be much more interesting to see a language which experiments with what is fundamentally representable, for example like how the Nix language supports functional programming and has functions as a first-class data type.
I started experimenting with Cue https://cuelang.org/ (for Kubernetes mostly, though I also used their tasks features) and it is wonderful!
If you squint it looks and works like a functional programming language, but instead of actually being one (like Dhall for example) it simply looks like configuration : keys and values.
The "types are values" and "values defined multiple times must unify" rules are really simple, and enable easy comprehension of what's happening and are powerful enough without it being a full blown programming language.
In a way it kinda reminds me of the TypeScript structural type system in the ways you manipulate types like values, which I like as well.
It is truly wonderful. I do think they are missing a clear winner use-case so currently at our company colleagues don't see a clear benefit yet. Though if you take all use-cases where we use yaml or json now, and you'd get a pretty coherent way of working with config. But it's hard to phantom for non-coders and hard to communicate for coders why it's worth the effort for the non-coders.
> These configuration languages are just different syntaxes for expressing the same fundamental data, bearing the same semantics.
This is my complaint too. However, they do add a proper integer type, which is the only thing that they do change with the data, as far as I can tell.
> It would be much more interesting to see a language which experiments with what is fundamentally representable
DER (and TER, which is a text format I made up to be compiled into DER (although TER is not really intended to be used directly in application programs); so TER does have comments, hexadecimal numeric literals, and other syntax features) does support many more data types, such as arbitrarily long integers, ASCII, ISO 2022, etc. My own extension to the format adds some additional types, such as a key/value list type and a TRON string type; the key/value list type is the only nonstandard ASN.1 type needed (together with a few of the standard ASN.1 types: sequence, real, UTF-8 string, null, boolean) to represent the same data as JSON does.
> for example like how the Nix language supports functional programming and has functions as a first-class data type.
For some applications this is useful and good but in others it is undesirable, I think.
> It would be much more interesting to see a language which experiments with what is fundamentally representable
You might checkout my project, Confetti [1]. I conceived of it as Unix configuration files with the flexibility of S-expressions. I think the examples page on the website shows interesting use cases. It doesn't have a formal execution model, however, for that you might checkout Tcl or Lua.
[1] https://confetti.hgs3.me/
Why is typeless a positive trait? Just due to the simplicity of the matter? What are the sharp edges?
In practice, there are still types, they are just validated by your application. I didn’t want Confetti itself to make assumptions. I wanted to give you the freedom to define your own custom types and keywords, like “on” and “off”, or even tri-states like “yes”, “no”, “maybe”.
The problem with mandatory keywords, like “true” and “false”, is they box you into the English language. And which data types should be intrinsic is arbitrary, for example, TOML has data types for date and time, but JSON does not [1]. Where do you draw the line? Confetti let’s you decide.
You might enjoy reading this take on the subject [2].
[1] https://toml.io/en/v1.0.0#offset-date-time
[2] https://github.com/madmurphy/libconfini/wiki/An-INI-critique...
I don't see how predefined keywords are a bad thing. True/false is near universal
That makes a lot of sense to me. These files aren't just read by programmers either.
> AI-generated arguments in response to all questions
There are currently two items in the FAQ. While the first one seems to be formatted with AI (I don't know if the arguments are AI generated though, how do you tell?), the other certainly doesn't look AI-generated: https://github.com/maml-dev/maml/issues/3#issuecomment-33559...
The person who opened the issue specifically complained about getting an AI-generated reply before closing it. If you view the edit history for the message, or the language author's second response, you will see that the reply was edited afterhand to not be transparently sloppy.
After the edit in the second question, it’s clear the author’s command of English is not that great, so they used AI as grammar correction.
Unfortunately this is becoming more and more common, even here in HN; I don’t think non-english speakers doing this realize how obviously ChatGPT-ish the results are, and how much of its own “thoughts” it injects into the text.
But why, - jsonnet https://jsonnet.org/ resolves the annoying syntactic strictness of json + does some other interesting things.
Yes! Everyone thinking of a new config language should look at jsonnet first. And there are much bigger reasons (than just syntactic stuff) hidden in the "interesting things" part.
The "interesting things" include being (or at least aiming to be) the solution to the following problem:
"I need to configure ~200 tasks for each of 7 services in 5 datacenters where some stuff is dependent on DC, some on (service+DC) combination and also some machines where the jobs run need per-machine config overrides.
I want to avoid manual copy-paste-modify and I want to avoid the hell of generating configs from a Turing-complete language"
The other deserving a mention is Pkl. Common denominator of being backed by a FAANG and having a lot of real world use.
https://github.com/apple/pkl
My IT department blocks me from seeing this page. I suppose they wish to preserve my sanity, by shielding me from yet another config-language spec. =)
JSON, with comments, multiline stings, optional commas and unquoted keys.
Optional unquoted keys. Basically, a superset of JSON, fixing the most annoying warts of the format - most annoying, because most gratuitous, in that it would have cost nothing to have those obvious features and yet would have greatly increased usability. I like it a lot, it's just a very pragmatic approach to improving JSON compared to creating a brand-new language like YAML and a slew of other contenders seemingly vainly try. I wish the name and presentation would better reflect this. Something like FJSON (Fixed JSON) or JSONF (JSON Fixed) or some other name which makes it clear this is an extended JSON, not yet another language, to avoid the confusion which already has engulfed the comment section here.
JSON++
I thought this was going to be some joke about Middle Aged Men in Lycra - often referred to as MAMLs
> Optional commas
> Optional key quotes
For me, it is an anti-feature.
Each time something is optional, by definition, there is more than one way to do it. I much more prefer opinionated way, so it is consistent.
It is precisely why I like linters, so instead of a few ways to go, I pick one and stick to it. More focus on the content and less on things that do not matter.
Hmm, that's just "another link from someone who uses HN as a bookmark service". User started this self-service at the end of last year. With now 60+ submissions in the last two weeks. We can expect more interesting topics.
Site guidelines don’t seem to forbid this, but might be against the spirit of the guidelines? If so, could be worth a report to hn@ycombinator.com?
Yep, zero interactions, just dumpling links.
I love this. It reminds me of PowerShell configuration files: https://ssg.dev/powershell-accidentally-created-a-nice-confi...
This is basically JSON for humans. YAML is harder to use due to significant indentation (easy to mess up in editors, and hard to identify the context), and TOML isn't great for hierarchical data.
It addresses all my complaints about JSON:
> Comments
> Multiline strings
> Optional commas
> Optional key quotes
I wish it was a superset of JSON (so, a valid JSON would also be valid MAML), but it doesn't seem to be the case.
EDIT: As I understand, HCL is very similar in terms of goals, and has been around for a while. It looks great too. https://github.com/hashicorp/hcl/
> I wish it was a superset of JSON (so, a valid JSON would also be valid MAML), but it doesn't seem to be the case.
What valid JSON would be invalid MAML?
For example, Unicode escaping seems incompatible. JSON’s “\u1234” format isn’t in the spec. There is a different syntax: “\u{123456}”
You are right. And the initial question is also meaningless as there is no difference between these two:
A parser is not able to decide if '"project"' equals 'project'.and the latter is not valid JSON
> TOML isn't great for hierarchical data.
My experience is different: TOML isn't obvious if there's an array that's far from the leaf data. Maybe that's what you experienced with the hierarchical data?
In my usage of it (where we use base and override config layers), arrays are the enemy. Overrides can only delete the array, not merge data in. TOML merely makes this code smell more smelly, so it's perfect for us.
I meant that the constant repetition of the hierarchical information could be cumbersome.
This thing is what triggered me to write https://ruudvanasseldonk.com/2025/abstraction-not-syntax
I believe every ambitious programmer makes a configuration language at some point, but most either keep it to themselves.
When I was a teen I made something called Nabla:
Initially made it for my 3d engine scene serialization format, but then used everywhere some non-trivial data format was needed (e.g. anything with nested data structures).I guess I'm not an ambitious programmer.
I see the negativity in some comments, but I have to say: just because we have a format that works we don't have to suffer it's slightly annoying problems for eternity.
This is a format that's very well defined, good decisions where to be flexible (quoted keys) and when to be strict (no leading zeroes, no leading plus sign, error when integer parsing can't be precise, defining all corner cases in strings).
For almost all of these, I remember cases when something went wrong (or was just annoying) in another format.
I admire efforts to fix things.
Yes but. How would you express NaN or infinities or even precise floating-point (the reason hex float exist) in this format? That breaks interchange if you cannot save/restore floating-point as in the save.
I admire the effort to fix things too. But this is exactly how we end up with 15 competing standards (https://xkcd.com/927/), each a little different, and no one can tell which library or package can parse which format any more.
I'm also not convinced that the small usability benefits of these alternative formats outweigh the burden of stumbling across them in different projects and then having to remember which parser works with which format.
If I had to choose between living with one canonical, well-established format like JSON and a jumble of 15 incompatible formats, I’d choose the single, well-established one every time.
I wonder if the author has heard of KDL: https://kdl.dev/
Colons separating key and value pairs enhance readability in my book, so KDL goes too far for me. Other options are JSON5 (https://json5.org/) and CUE (https://cuelang.org/docs/introduction/). The latter is maximalist rather than minimalist, but very well thought out and worth checking out.
Really it's quite logical that the next iteration of these configuration languages be this style, remove superfluous and annoying quotes, handle comments and maybe allow trailing commas.
If anything it's a spec that writes itself.
Only thing I don't like in kdl is the redundancy between arguments, properties and child nodes
Looks sane.
I was going to mention KDL as well.
I've been using it for niri recently, and it's quite nice.
This looks like an anemic HOCON[0] clone.
0 - https://github.com/lightbend/config/blob/main/HOCON.md
I just can’t anymore with this stuff. TOML, JSON, YAML, JSONC, HJSON, MAML…
I’ll just stick to environment vars or something code
I love that in the end, everything still comes down to using bash (and env vars), because for all its footguns and strings, it's still the most reasonable choice when giving up on the zoo of newer formats. I expect it to outlive us all, like our unergonomic keyboards, and having to deal with null values.
I assume it will. Bash scripting has been around for a long time and isn’t going away anytime soon. It’s already outlived some folks.
There's also - https://huml.io
So a worse version of HJSON[1]. I'm good.
[1]: https://hjson.github.io/
Yes, it feels neglectful that the author has not mentioned this prior art, especially since they are near identical
Not sure that is "worse", it looked identical to me.
HJSON also has optional quoteless strings (with some caveats) and optional root braces.
> Optional key quotes
Why are they optional? Why not just make them mandatory? So I don't need to guess which chars need quotes.
Edit: What most languages also lack: semantics on de-serialization. In the best case, I want to preserve formatting and stuff when the config is changed/re-committed programmatically.
Because it's supposed to be pleasant for humans and quoting keys is the least pleasant part of jsom config files.
What's so unpleasant about quoting a key?
Thanks for reminding me that I always wanted to create an alternative to JSON/YAML, so after your post, I got down to work, and this is what came out: https://vzparse.xyz/
I like it a lot: a superset of JSON, fixing the most annoying warts of the format - most annoying, because most gratuitous, in that it would have cost nothing to have those obvious features and yet would have greatly increased usability. It's just a very pragmatic approach to improving JSON compared to creating a brand-new language like YAML and a slew of other contenders seemingly vainly try. I wish the name and presentation would better reflect this. Something like FJSON (Fixed JSON) or JSONF (JSON Fixed) or some other name which makes it clear this is an extended JSON, not yet another language, to avoid the confusion which already has engulfed the comment section here.
I like it, but it's too late.
It could also do with a datetime datatype, the one thing (apart from comments) that I constantly feel the need for in JSON.
I think json would be better off if it supported IEEE floats, too. Sometimes, you really have to serialize a NaN or infinity.
Why does this look pretty much like JSON with the only exception being no commas between elements in a list / array?
Because it IS json with some half-assed enhancements. I say half-assed, because it only seems to work one-way. Parsing this is OK, probably not the most efficient json-parser around, but writing back and preserving the enhancements seems not supported, at least not in the python-implementation.
If I actually require comments, dangling commas etc. I'm always using JSON5 instead [1].
[1] https://json5.org/
I've never had a need for comments that `{ "comment": "Hello, world" }` couldn't solve. Dangling commas would be nice, but between my auto-formatting editor and `JSON.stringify()`, they're never an issue either.
The Raku language (https://raku.org) nails multiline strings and avoids the triple quotes issues mentioned in the OP.
https://docs.raku.org/syntax/heredocs%20%3AtoThe best multiline strings are those where you can have proper indentations without having to guess how indentation is handled. bonus points for making nesting easy and making copy-pasting work without breaking indentation.
To my knowledge only Zig's multiline strings work this way
In C:
Granted, this is not a real multiline string, but you also have characters in your Zig example that are not part of string content (\\).okaay, I get that you want the indentation to work (ironically this is more important when you are multilining a Python code example), but having to manage all the \\ is a pain in the butt
> ironically this is more important when you are multilining a Python code example
And neither seems to be a great use case for configuration. A markup language, sure, but I'm not sure I see a significant need for multiline strings (even in general) in a config file.
fair point … although I can see a use case for eg multline multi languages contractual boilerplate that i don’t want in my main code
That's probably the worst multiline string option if you ask me. Looks like they copied Bash.
Yes, the evolution of Raku multilines is from shell (heredoc) > perl > raku, and a LOT of experience went into the design. Not sure I understand why that's a bad thing?
Some benefits of the Raku solution are:
This usually means that any text can be cut and pasted as is into the multiline and you can adjust the adverbs to match the original quoting pattern.Even with perverse patterns (which you cannot guarantee against in variable text), there is a way to gracefully handle:
https://docs.raku.org/language/quotingAn important detail not covered here, is dates.
Json doesn't support dates, so we use strings in whatever format.
A good new configuration language should have dates. IMO.
So far it seems like Json with comments =)
Looks infinitely much nicer than YAML, with explicit blocks and such.
That's not a high bar of course, even the apache httpd pseudo xml is nicer than yaml.
If I could change the world I'd remove all those formats and keep cuelang only.
Cuelang is so awesome that nobody uses it.
I think most people simply don't know it exists but it is used [0] and has high use satisfaction as far as I can see.
[0] https://github.com/search?q=lang%3Acue&type=repositories
While JSON kind of sucks as a configuration language, it's already there and I don't think it sucks enough for me to care to use anything else. Not having trailing commas or comments is annoying, but unless you're the config file for a web server or something, I'm cool with JSON.
Great name and a reasonable solution to the problems of JSON (can't speak for the implementation but the DX value of this is huge).
They fix some of the problems with syntax of JSON but do not fix most of the problems with the data model; the only thing they do fix is that now there is a integer type. It still has the other problems, e.g. it still uses Unicode and still requires keys to be strings. For a configuration language, it can also be useful to have a application-specific data.
There is also https://kdl.dev/
I've been using EDN for years without ever wishing for something different. It's unfortunate that it hasn’t caught on outside the Clojure world.
What is wrong with Dhall?
https://dhall-lang.org/
In most cases typescript will be better than this.
In some cases where keeping simple is a feature, it's good to know !
json without comments is one of the worst cancers in programming land. however replacing json5 // with # is NOT it!
Why?
Because // is already pretty well established as the comment format in JSONC and JSON5? Why do it differently?
It is fairly minor though I would say, and at least it makes it clear that block comments aren't supported (which is good).
When this was first posted a couple of weeks ago by the spec's author, I took it as an opportunity to see how quickly I could spin up an IntelliJ language plugin since the last time I worked on a language plugin was pre-GPT (Klotho Annotations - basically TOML inside of @annotations inside comments or string literals in a variety of host languages). Back then, it took a week for me to figure out the ins and outs of basic syntax highlighting with GrammarKit.
This time around, I worked with Claude Code and we basically filled in each other's knowledge gaps to finish implementing every feature I was looking for in about 3 days of work:
Day 1:
- Plugin initialization
- Syntax highlighting
- JSON Schema integration
- Error inspections
Day 2:
- Code formatter (the code style settings page probably took longer to get right than the formatter)
- Test suite for existing features
Day 3:
- Intentions, QuickFix actions, etc. to help quickly reformat or fix issues detected in the file
- More graceful parsing error recovery and reporting
- Contextual completions (e.g., relevant keys/values from a JSON schema, existing keys from elsewhere in the file, etc.)
- Color picker gutter icon from string values that represent colors (in various formats)
I'm sure there are a few other features that I'm forgetting, but at the end of the day, roughly 80-85% of the code was generated from the command line by conversing with Claude Code (Sonnet 4.5) to plan, implement, test, and revise individual features.
For IntelliJ plugins, the SDK docs tend to cover the bare minimum to get common functionality working, and beyond that, the way to learn is by reading the source of existing OSS plugins. Claude was shockingly good at finding extension points for features I'd never implemented before and figuring out how to wire them up (though not always 100% successfully). It turns out that Claude can be quite an accelerator for building plugins for the JetBrains ecosystem.
Bottom line, if you're sitting on an idea for a plugin because you thought it might to take too long to bootstrap and figure out all the IDE integration parts, there's never been a better time to just go for it.
EDIT: Repo link for anyone interested: https://github.com/DavidSeptimus/maml-intellij-plugin
I like it. It solves a few issues I have with JSON. The quotes on the keys, the commas, etc. nice work. Keep them coming
This is super controversial for HN but I really really like YAML. The best “human readable” config language.
YAML is as good as we will get.
I can't decide between yaml and json5/json
It seems like we will be forced to use both forever though
Practically nobody is using json5.
It's crazy complicated and full of uneccessary cruft. Hence stuff like strictyaml
I wouldn't say it's the most readable. Values can be ambiguous, YAML anchors are powerful but complicated, and using indentation to define structure means that you're never quite sure to which node something belongs to. And good luck hunting down weird errors if you mistakenly screw up the indentation.
YAML is also often abused as a DSL and for very large documents (Ansible, k8s, GH Actions, etc.), which makes it a pain to work with.
It's not so much that liking all of this is controversial. It's just a bad opinion. :p
Oh yay, just what we need, ANOTHER one of these. Did the YA in YAML not already give a clue? Now there are 15 competing standards. Please make it stop. S-expressions were all that we wanted in the first place.
According to wikipedia “There are many variants of the S-expression format, supporting a variety of different syntaxes for different datatypes.”
Using parentheses instead of curly braces is fine by me, but it doesnt seem to solve the issue of syntax bikeshedding.
The fundamental problem is “configuration” is a huge area, from simple key-value lists to complex declarative languages. And you want the format to be both easy to read and edit for humans and simple to parse and process for computers. No single format will be perfect for all use cases, but perhaps a compromise can be found which is good enough for most cases.
Yaml has terrible footguns. I'd rather we keep experimenting and find a new optimum.
Toml fixes some issues with shallow Yaml, but sucks at deeply nested data.
Maml looks nice at cursory glance. It seems to do nesting, numerics, comments, and strings right.
We're really close to having a great format. I'd like to see more attempts before accepting what we have as permanent.
You can find footgunless parsers
Very often (probably the vast majority) the people writing the YAML aren’t the ones choosing which parser is being used by the software consuming it.
If you are writing a software system that needs potentially human edited config files, yaml is the best for human edited files if you, software architect, use a footgun less parser.
Yaml is popular like python because indentation as a scope depth indicator is far more visually intuitive for low skill programmers than braces (c,json) or counting/matching parents in lisp or begin end tags in xml.
Sorry your kubernetes ecosystem didn't do that. Why not get them to change parsers? A hell of a lot easier than changing k8s to toml or maml.
Because ultimately that's what the frustration of yaml comes from, right? Kubernetes config?
> S-expressions were all that we wanted in the first place.
There are dozens of us!
Configuration is a spectrum and this is close to JSON.
Disclaimer: I'm a Cuelang[0] fanboy
Do yourself a favor and use Cuelang instead.
Word of warning though: documentation isn't the best and takes some time to get, but once it clicks...
[0]: https://cuelang.org
Practically HCL, switch colons for equals in the key/value map
I didn't know about HCL. It looks great too.
Working with Terraform, and needing to handle the complexity of our per-client deployments at work, I ended up creating a bash layer that takes N number of JSON files, performs a deep merge, and spits out a .tfvars file.
As you’ve said, all I did was fork a JSON.stringify function and swap colon for equals.
Anyone have a better solution they’ve worked with?
Edit: Why the downvotes? Terraform is using HCL? Are we talking a different HCL here?
You can directly pass JSON to Terraform by putting it in a `.tfvars.json` file [1], as far as I can tell this has been supported since v0.5.0 which released in May 2015.
Terraform doesn't have a built-in deep merge function, but it will merge `.tfvars.json` files in the order given on the CLI, if you specify multiple `-var-file` arguments. For what it's worth, as of Terraform 1.8, you can also use functions from third-party providers like isometry/deepmerge [2] to perform a deep merge.
[1] https://developer.hashicorp.com/terraform/language/parameter... [2] https://registry.terraform.io/providers/isometry/deepmerge/l...
This looks pretty good but also JSON5 is perfectly fine, it just needs more support from libraries and IDEs. Adding another format is just going to make that problem worse. And nobody is going to use this format either because it also has poor support from libraries and IDEs.
question: why not make all strings multi-line, and drop a syntax/concept?
Why?
Am I missing something or is this literally just Ruby? Like - it doesn’t list Ruby as a supported language, but, it also looks like fully executable Ruby code?
(To be fair, I’m in favor of that)
Edit: Oh, no commas.
Also Ruby doesn't have triple quotation marks (""") string literals.
Just what we needed, another JSON with comments! Can't wait for YAML (Yet Another MAML) next week.
Oh, joy
Why?
https://xkcd.com/927/ ?
Or is there any reason why to choose this over the others?
It's really risky to launch something by telling us three other more popular perfectly-serviceable alternatives in the headline.
Hard pass
Nope. Just nope. Use YAML.