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.

> 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

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.

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.

But why, - jsonnet https://jsonnet.org/ resolves the annoying syntactic strictness of json + does some other interesting things.

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. =)

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/

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.

> 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.

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:

  * XML-like syntax

  * Schema language
  * Compact binary representation
  * Trivial parser for binary representation 
  * Optionally, simple dynamic programming language on top

I wonder if the author has heard of KDL: https://kdl.dev/

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.

I just can’t anymore with this stuff. TOML, JSON, YAML, JSONC, HJSON, MAML…

I’ll just stick to environment vars or something code

This looks like an anemic HOCON[0] clone.

0 - https://github.com/lightbend/config/blob/main/HOCON.md

So a worse version of HJSON[1]. I'm good.

[1]: https://hjson.github.io/

There's also - https://huml.io

> 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.

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.

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/

If I actually require comments, dangling commas etc. I'm always using JSON5 instead [1].

[1] https://json5.org/

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.

Why does this look pretty much like JSON with the only exception being no commas between elements in a list / array?

I thought this was going to be some joke about Middle Aged Men in Lycra - often referred to as MAMLs

The Raku language (https://raku.org) nails multiline strings and avoids the triple quotes issues mentioned in the OP.

  say q:to/END/;
    Here is
    some multi line
        string
    END

An 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.

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.

If I could change the world I'd remove all those formats and keep cuelang only.

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!

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.

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.

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

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.

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?

Hard pass

Nope. Just nope. Use YAML.