MAML – A new configuration language
145 comments
·October 12, 2025hresvelgr
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.
Cthulhu_
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.
dotancohen
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.
Someone
> 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.
psychoslave
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.
ithkuil
JSON with comments would go a long way
petersumskas
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.
krapp
Use Lua tables. Lua's parser is smaller than many JSON parsers, the syntax is almost the same and you can use comments.
Lammy
> 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:
HeavyStorm
Wow, wasn't aware (or simply never noticed) the name change. I was still calling it yet another...
qrios
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).
ctenb
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.
miningape
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.
odie5533
Is XML a markup language? Because it was often used for not that too.
oneeyedpigeon
Occasional misuse doesn't change its nature. It seems as if MAML cannot be used as a markup language.
Skeime
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.)
AdieuToLogic
> Is XML a markup language?
Yes, the hint is in the name:
Extensible Markup Language (XML)[0]
hnlmorg
> 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. ;)
poly2it
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.
LelouBil
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.
hbogert
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.
zzo38computer
> 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.
hgs3
> 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.
cdaringe
Why is typeless a positive trait? Just due to the simplicity of the matter? What are the sharp edges?
hgs3
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...
sedatk
> 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...
poly2it
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.
ricardobeat
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.
gzh18
But why, - jsonnet https://jsonnet.org/ resolves the annoying syntactic strictness of json + does some other interesting things.
praptak
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"
themgt
The other deserving a mention is Pkl. Common denominator of being backed by a FAANG and having a lot of real world use.
Pinus
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. =)
imron
JSON, with comments, multiline stings, optional commas and unquoted keys.
pegasus
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.
gerdesj
JSON++
qrios
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.
sevg
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?
glitchcrab
Yep, zero interactions, just dumpling links.
sedatk
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/
snarfy
> 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?
sedatk
For example, Unicode escaping seems incompatible. JSON’s “\u1234” format isn’t in the spec. There is a different syntax: “\u{123456}”
CBLT
> 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.
sedatk
I meant that the constant repetition of the hierarchical information could be cumbersome.
stared
> 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.
ruuda
This thing is what triggered me to write https://ruudvanasseldonk.com/2025/abstraction-not-syntax
killerstorm
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
spooneybarger
I guess I'm not an ambitious programmer.
nfrmatk
I wonder if the author has heard of KDL: https://kdl.dev/
pegasus
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.
keyle
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.
Bolwin
Only thing I don't like in kdl is the redundancy between arguments, properties and child nodes
childintime
Looks sane.
imiric
I was going to mention KDL as well.
I've been using it for niri recently, and it's quite nice.
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.
Other approach: 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. JSON5 seems to be more suitable for this.