8 ms·

MAML – A new configuration language

127 points by birdculture 1y ago

sjdrc 1y ago
Why?
ghthor 1y ago
Practically HCL, switch colons for equals in the key/value map
- sedatk 1y ago
  I didn't know about HCL. It looks great too.
- antonymoose 1y ago
  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?
  - zanecodes 1y ago
    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/parameterize#variable-definition-files https://developer.hashicorp.com/terraform/language/parameter... [2] https://registry.terraform.io/providers/isometry/deepmerge/latest/docs/functions/mergo https://registry.terraform.io/providers/isometry/deepmerge/l...
sorrythanks 1y ago
question: why not make all strings multi-line, and drop a syntax/concept?
poly2it 1y ago
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.
- sedatk 1y ago
  > 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-3355987345 https://github.com/maml-dev/maml/issues/3#issuecomment-33559...
  - poly2it 1y ago
    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 1y ago
      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.
- zzo38computer 1y ago
  > 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.
ajsnigrutin 1y ago
Why? https://xkcd.com/927/ https://xkcd.com/927/ ? Or is there any reason why to choose this over the others?
- ocdtrekkie 1y ago
  It's really risky to launch something by telling us three other more popular perfectly-serviceable alternatives in the headline.
sedatk 1y ago
I love this. It reminds me of PowerShell configuration files: https://ssg.dev/powershell-accidentally-created-a-nice-configuration-format-3efde5448090/ 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/ https://github.com/hashicorp/hcl/
- CBLT 1y ago
  > 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 1y ago
    I meant that the constant repetition of the hierarchical information could be cumbersome.
- snarfy 1y ago
  > 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?
  - qrios 1y ago
    You are right. And the initial question is also meaningless as there is no difference between these two: {"project": "MAML"} {project: "MAML"} A parser is not able to decide if '"project"' equals 'project'.
zzo38computer 1y ago
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.
rglover 1y ago
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).
nikeee 1y ago
> 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.
- sixo 1y ago
  Because it's supposed to be pleasant for humans and quoting keys is the least pleasant part of jsom config files.
  - oneeyedpigeon 1y ago
    What's so unpleasant about quoting a key?
    - sixo 1y ago
      Two extra characters per rep, each involving a "shift", and it's furthermore an eyesore to read How is it that the comments on this post seem to consist 100% of people who think JSON is the perfect language and that any deviation from it is an unnecessary complexity? Use JSON for configuration for literally 5 minutes and you will get annoyed at quoting keys, lacking comments, escaping long strings, and juggling commas. MAML is almost exactly what I'd come up with (although I wouldn't have made commas optional, that feels weird.)
      - oneeyedpigeon 1y ago
        > Two extra characters per rep, each involving a "shift" You'd expect text editors to do this automatically; I'll admit, I don't think mine does. > and it's furthermore an eyesore to read We'll have to disagree on that one because I think it looks a lot nicer. I always preferred quoted attributes in html too. > How is it that the comments on this post seem to consist 100% of people who think JSON is the perfect language I'm sure you intended that as hyperbole. JSON isn't perfect, but it's got a lot going for it, not least ubiquity. > Use JSON for configuration for literally 5 minutes and you will get annoyed at quoting keys, lacking comments, escaping long strings, and juggling commas. I've used JSON for configuration loads and haven't faced these issues. I'm not denying your experience, I just want to understand it.
kennethallen 1y ago
Oh, joy
throwaway81523 1y ago
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.
- threatofrain 1y ago
  > S-expressions were all that we wanted in the first place. There are dozens of us!
- echelon 1y ago
  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.
  - AtlasBarfed 1y ago
    You can find footgunless parsers
    - orev 1y ago
      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.
      - AtlasBarfed 1y ago
        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?
deleted 1y ago
[deleted]
nfrmatk 1y ago
I wonder if the author has heard of KDL: https://kdl.dev/ https://kdl.dev/
- imiric 1y ago
  I was going to mention KDL as well. I've been using it for niri recently, and it's quite nice.
- childintime 1y ago
  Looks sane.
- Bolwin 1y ago
  Only thing I don't like in kdl is the redundancy between arguments, properties and child nodes
- keyle 1y ago
  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.
- pegasus 1y ago
  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/ https://json5.org/) and CUE (https://cuelang.org/docs/introduction/ https://cuelang.org/docs/introduction/). The latter is maximalist rather than minimalist, but very well thought out and worth checking out.
didip 1y ago
This is super controversial for HN but I really really like YAML. The best “human readable” config language.
- andrepd 1y ago
  It's crazy complicated and full of uneccessary cruft. Hence stuff like strictyaml
- typpilol 1y ago
  I can't decide between yaml and json5/json It seems like we will be forced to use both forever though
  - flanked-evergl 1y ago
    Practically nobody is using json5.
- imiric 1y ago
  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
- flanked-evergl 1y ago
  YAML is as good as we will get.
emocin 1y ago
[dead]
moogly 1y ago
So a worse version of HJSON[1]. I'm good. [1]: https://hjson.github.io/ https://hjson.github.io/
- keyle 1y ago
  Not sure that is "worse", it looked identical to me.
  - moogly 1y ago
    HJSON also has optional quoteless strings (with some caveats) and optional root braces.
- ctenb 1y ago
  Yes, it feels neglectful that the author has not mentioned this prior art, especially since they are near identical
killerstorm 1y ago
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).
- spooneybarger 1y ago
  I guess I'm not an ambitious programmer.
- zzo38computer 1y ago
  Do you have a document describing it?
RangerScience 1y ago
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.
- pilaf 1y ago
  Also Ruby doesn't have triple quotation marks (""") string literals.
reactordev 1y ago
I just can’t anymore with this stuff. TOML, JSON, YAML, JSONC, HJSON, MAML… I’ll just stick to environment vars or something code
- quchen 1y ago
  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.
  - reactordev 1y ago
    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.
rvitorper 1y ago
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
quintu5 1y ago
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 https://github.com/DavidSeptimus/maml-intellij-plugin
Lammy 1y ago
> 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/2001-12-10.html https://yaml.org/spec/history/2002-04-07.html https://yaml.org/spec/history/2002-04-07.html
- odie5533 1y ago
  Is XML a markup language? Because it was often used for not that too.
  - AdieuToLogic 1y ago
    > Is XML a markup language? Yes, the hint is in the name: Extensible Markup Language (XML)[0] 0 - https://en.wikipedia.org/wiki/XML https://en.wikipedia.org/wiki/XML
    - hnlmorg 1y ago
      > 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. ;)
      - xigoi 1y ago
        MAML is configuration format, not a document format, which is why the “ML” in its name is a misnomer.
        throwaway150 1y ago
        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.
AdieuToLogic 1y ago
This looks like an anemic HOCON[0] clone. 0 - https://github.com/lightbend/config/blob/main/HOCON.md https://github.com/lightbend/config/blob/main/HOCON.md
- syhol 1y ago
  HOCON is so overlooked but an almost ideal config language in my eyes. The only element I'm not 100% on is unquoted string values (the norway problem but not quite as bad since there isn't no/yes booleans), but even thats not too bad.
  - deleted 1y ago
    [deleted]
qrios 1y ago
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.
- glitchcrab 1y ago
  Yep, zero interactions, just dumpling links.
- sevg 1y ago
  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?
Pinus 1y ago
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 1y ago
  JSON, with comments, multiline stings, optional commas and unquoted keys.
  - pegasus 1y ago
    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 1y ago
      JSON++
bradhe 1y ago
Configuration is a spectrum and this is close to JSON.
procaryote 1y ago
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.
singularity2001 1y ago
json without comments is one of the worst cancers in programming land. however replacing json5 // with # is NOT it!
- kitd 1y ago
  Why?
  - IshKebab 1y ago
    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).
xlii 1y ago
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 https://cuelang.org
librasteve 1y ago
The Raku language (https://raku.org 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 https://docs.raku.org/syntax/heredocs%20%3Ato https://docs.raku.org/syntax/heredocs%20%3Ato
- IshKebab 1y ago
  That's probably the worst multiline string option if you ask me. Looks like they copied Bash.
  - librasteve 1y ago
    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: q«say '''hi"""» #say '''hi""" https://docs.raku.org/language/quoting https://docs.raku.org/language/quoting
- afiori 1y ago
  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 const hello_world_in_c = \\#include <stdio.h> \\ \\int main(int argc, char **argv) { \\ printf("hello world\n"); \\ return 0; \\} ;
vim-guru 1y ago
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.
IshKebab 1y ago
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.
jjice 1y ago
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.
maelito 1y ago
In most cases typescript will be better than this. In some cases where keeping simple is a feature, it's good to know !
pegasus 1y ago
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.
LauraMedia 1y ago
If I actually require comments, dangling commas etc. I'm always using JSON5 instead [1]. [1] https://json5.org/ https://json5.org/
- oneeyedpigeon 1y ago
  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.
  - moogly 1y ago
    Doesn't work with strict schema validators that disallow unknown keys. I'm looking at you, tauri.conf.json.
    - oneeyedpigeon 1y ago
      Interesting; I haven't come across this before. I wonder why they don't just ignore unrecognised keys. Or, at least, give a warning, but continue to work otherwise.
  - LauraMedia 1y ago
    It certainly is more for the usecases where you don't use JSON in the intended way (communication between two machines) but as a config, explaining possible values or at least give a URL for a documentation of the config file format.
dev_l1x_be 1y ago
What is wrong with Dhall? https://dhall-lang.org/ https://dhall-lang.org/
hresvelgr 1y ago
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_ 1y ago
  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 1y ago
    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.
    - psychoslave 1y ago
      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.
    - Someone 1y ago
      > 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 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.
avr5500 1y ago
There's also - https://huml.io https://huml.io
novalumina84 1y ago
Just what we needed, another JSON with comments! Can't wait for YAML (Yet Another MAML) next week.
gzh18 1y ago
But why, - jsonnet https://jsonnet.org/ https://jsonnet.org/ resolves the annoying syntactic strictness of json + does some other interesting things.
- themgt 1y ago
  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 https://github.com/apple/pkl
- praptak 1y ago
  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"
mirekrusin 1y ago
If I could change the world I'd remove all those formats and keep cuelang only.
- flanked-evergl 1y ago
  Cuelang is so awesome that nobody uses it.
  - mirekrusin 1y ago
    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 https://github.com/search?q=lang%3Acue&type=repositories
    - flanked-evergl 1y ago
      Top result: examples repo.
      - mirekrusin 1y ago
        It's unusual to have repository that is close to 100% cuelang, as a config language you'll have very little of it in repository but github doesn't have a good way of finding those.
flanked-evergl 1y ago
Nope. Just nope. Use YAML.
aljgz 1y ago
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.
- throwaway150 1y ago
  I admire the effort to fix things too. But this is exactly how we end up with 15 competing standards (https://xkcd.com/927/ 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.
- p0nce 1y ago
  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.
jmloop 1y ago
There is also https://kdl.dev/ https://kdl.dev/
- pancsta 1y ago
  KDL supports multiline indents properly, unlike this one. No need for MAML, someone simply didnt do his research (outside of JSON).
Shorel 1y ago
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 =)
stared 1y ago
> 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.
modinfo 1y ago
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/ https://vzparse.xyz/
sambeau 1y ago
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.
- Someone 1y ago
  I think json would be better off if it supported IEEE floats, too. Sometimes, you really have to serialize a NaN or infinity.
  - zzo38computer 1y ago
    I think that DER (which is a binary format, although there are ways to make it from text formats) is better, which does have NaN and infinity and other stuff.
pkphilip 1y ago
Why does this look pretty much like JSON with the only exception being no commas between elements in a list / array?
- slightwinder 1y ago
  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.
ruuda 1y ago
This thing is what triggered me to write https://ruudvanasseldonk.com/2025/abstraction-not-syntax https://ruudvanasseldonk.com/2025/abstraction-not-syntax
rdsubhas 1y ago
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.
- deleted 1y ago
  [deleted]
ndsipa_pomu 1y ago
I thought this was going to be some joke about Middle Aged Men in Lycra - often referred to as MAMLs
dominicrose 1y ago
MAML sounds like mammelle in French, but besides that I think that making things optional adds complexity. JSON is simple because it's strict and the syntax parts are not optional. As much as I like writing javascript objects without quotes, it's javascript, not JSON. I don't mind putting quotes in JSON. Plus, it helps distinguishing it from javascript. People don't always agree wether there should be a trailing comma or not. At least with JSON there's no choice. Making a trailing comma mandatory would be weird. Because mandatory is different than "automatically added by Prettier". What I like about JSON is that people can't use it to make weird things like HTMLX on top of it. Even plain HTML is no longer XML. At least JSON is JSON. I don't mind VS Code using JSONC for it's config though.

127 points by birdculture 1y ago

sjdrc 1y ago

Why?

ghthor 1y ago

Practically HCL, switch colons for equals in the key/value map

sedatk 1y ago
I didn't know about HCL. It looks great too.
antonymoose 1y ago
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?
- zanecodes 1y ago
  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/parameterize#variable-definition-files https://developer.hashicorp.com/terraform/language/parameter... [2] https://registry.terraform.io/providers/isometry/deepmerge/latest/docs/functions/mergo https://registry.terraform.io/providers/isometry/deepmerge/l...

sorrythanks 1y ago

question: why not make all strings multi-line, and drop a syntax/concept?

poly2it 1y ago

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.

sedatk 1y ago
> 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-3355987345 https://github.com/maml-dev/maml/issues/3#issuecomment-33559...
- poly2it 1y ago
  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 1y ago
    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.
zzo38computer 1y ago
> 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.

ajsnigrutin 1y ago

Why? https://xkcd.com/927/ https://xkcd.com/927/ ? Or is there any reason why to choose this over the others?

ocdtrekkie 1y ago
It's really risky to launch something by telling us three other more popular perfectly-serviceable alternatives in the headline.

sedatk 1y ago

I love this. It reminds me of PowerShell configuration files: https://ssg.dev/powershell-accidentally-created-a-nice-configuration-format-3efde5448090/ 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/ https://github.com/hashicorp/hcl/

CBLT 1y ago
> 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 1y ago
  I meant that the constant repetition of the hierarchical information could be cumbersome.
snarfy 1y ago
> 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?
- qrios 1y ago
  You are right. And the initial question is also meaningless as there is no difference between these two: {"project": "MAML"} {project: "MAML"} A parser is not able to decide if '"project"' equals 'project'.

zzo38computer 1y ago

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.

rglover 1y ago

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

nikeee 1y ago

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

sixo 1y ago
Because it's supposed to be pleasant for humans and quoting keys is the least pleasant part of jsom config files.
- oneeyedpigeon 1y ago
  What's so unpleasant about quoting a key?
  - sixo 1y ago
    Two extra characters per rep, each involving a "shift", and it's furthermore an eyesore to read How is it that the comments on this post seem to consist 100% of people who think JSON is the perfect language and that any deviation from it is an unnecessary complexity? Use JSON for configuration for literally 5 minutes and you will get annoyed at quoting keys, lacking comments, escaping long strings, and juggling commas. MAML is almost exactly what I'd come up with (although I wouldn't have made commas optional, that feels weird.)
    - oneeyedpigeon 1y ago
      > Two extra characters per rep, each involving a "shift" You'd expect text editors to do this automatically; I'll admit, I don't think mine does. > and it's furthermore an eyesore to read We'll have to disagree on that one because I think it looks a lot nicer. I always preferred quoted attributes in html too. > How is it that the comments on this post seem to consist 100% of people who think JSON is the perfect language I'm sure you intended that as hyperbole. JSON isn't perfect, but it's got a lot going for it, not least ubiquity. > Use JSON for configuration for literally 5 minutes and you will get annoyed at quoting keys, lacking comments, escaping long strings, and juggling commas. I've used JSON for configuration loads and haven't faced these issues. I'm not denying your experience, I just want to understand it.

kennethallen 1y ago

Oh, joy

throwaway81523 1y ago

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.

threatofrain 1y ago
> S-expressions were all that we wanted in the first place. There are dozens of us!
echelon 1y ago
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.
- AtlasBarfed 1y ago
  You can find footgunless parsers
  - orev 1y ago
    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.
    - AtlasBarfed 1y ago
      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?

deleted 1y ago

[deleted]

nfrmatk 1y ago

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

imiric 1y ago
I was going to mention KDL as well. I've been using it for niri recently, and it's quite nice.
childintime 1y ago
Looks sane.
Bolwin 1y ago
Only thing I don't like in kdl is the redundancy between arguments, properties and child nodes
keyle 1y ago
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.
pegasus 1y ago
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/ https://json5.org/) and CUE (https://cuelang.org/docs/introduction/ https://cuelang.org/docs/introduction/). The latter is maximalist rather than minimalist, but very well thought out and worth checking out.

didip 1y ago

This is super controversial for HN but I really really like YAML. The best “human readable” config language.

andrepd 1y ago
It's crazy complicated and full of uneccessary cruft. Hence stuff like strictyaml
typpilol 1y ago
I can't decide between yaml and json5/json It seems like we will be forced to use both forever though
- flanked-evergl 1y ago
  Practically nobody is using json5.
imiric 1y ago
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
flanked-evergl 1y ago
YAML is as good as we will get.

emocin 1y ago

[dead]

moogly 1y ago

So a worse version of HJSON[1]. I'm good. [1]: https://hjson.github.io/ https://hjson.github.io/

keyle 1y ago
Not sure that is "worse", it looked identical to me.
- moogly 1y ago
  HJSON also has optional quoteless strings (with some caveats) and optional root braces.
ctenb 1y ago
Yes, it feels neglectful that the author has not mentioned this prior art, especially since they are near identical

killerstorm 1y ago

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

spooneybarger 1y ago
I guess I'm not an ambitious programmer.
zzo38computer 1y ago
Do you have a document describing it?

RangerScience 1y ago

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.

pilaf 1y ago
Also Ruby doesn't have triple quotation marks (""") string literals.

reactordev 1y ago

I just can’t anymore with this stuff. TOML, JSON, YAML, JSONC, HJSON, MAML… I’ll just stick to environment vars or something code

quchen 1y ago
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.
- reactordev 1y ago
  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.

rvitorper 1y ago

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

quintu5 1y ago

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 https://github.com/DavidSeptimus/maml-intellij-plugin

Lammy 1y ago

> 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/2001-12-10.html https://yaml.org/spec/history/2002-04-07.html https://yaml.org/spec/history/2002-04-07.html

odie5533 1y ago
Is XML a markup language? Because it was often used for not that too.
- AdieuToLogic 1y ago
  > Is XML a markup language? Yes, the hint is in the name: Extensible Markup Language (XML)[0] 0 - https://en.wikipedia.org/wiki/XML https://en.wikipedia.org/wiki/XML
  - hnlmorg 1y ago
    > 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. ;)
    - xigoi 1y ago
      MAML is configuration format, not a document format, which is why the “ML” in its name is a misnomer.
      - throwaway150 1y ago
        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.

AdieuToLogic 1y ago

This looks like an anemic HOCON[0] clone. 0 - https://github.com/lightbend/config/blob/main/HOCON.md https://github.com/lightbend/config/blob/main/HOCON.md

syhol 1y ago
HOCON is so overlooked but an almost ideal config language in my eyes. The only element I'm not 100% on is unquoted string values (the norway problem but not quite as bad since there isn't no/yes booleans), but even thats not too bad.
- deleted 1y ago
  [deleted]

qrios 1y ago

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.

glitchcrab 1y ago
Yep, zero interactions, just dumpling links.
sevg 1y ago
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?

Pinus 1y ago

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 1y ago
JSON, with comments, multiline stings, optional commas and unquoted keys.
- pegasus 1y ago
  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 1y ago
    JSON++

bradhe 1y ago

Configuration is a spectrum and this is close to JSON.

procaryote 1y ago

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.

singularity2001 1y ago

json without comments is one of the worst cancers in programming land. however replacing json5 // with # is NOT it!

kitd 1y ago
Why?
- IshKebab 1y ago
  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).

xlii 1y ago

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 https://cuelang.org

librasteve 1y ago

The Raku language (https://raku.org 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 https://docs.raku.org/syntax/heredocs%20%3Ato https://docs.raku.org/syntax/heredocs%20%3Ato

IshKebab 1y ago
That's probably the worst multiline string option if you ask me. Looks like they copied Bash.
- librasteve 1y ago
  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: q«say '''hi"""» #say '''hi""" https://docs.raku.org/language/quoting https://docs.raku.org/language/quoting
afiori 1y ago
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 const hello_world_in_c = \\#include <stdio.h> \\ \\int main(int argc, char **argv) { \\ printf("hello world\n"); \\ return 0; \\} ;

vim-guru 1y ago

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.

IshKebab 1y ago

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.

jjice 1y ago

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.

maelito 1y ago

In most cases typescript will be better than this. In some cases where keeping simple is a feature, it's good to know !

pegasus 1y ago

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.

LauraMedia 1y ago

If I actually require comments, dangling commas etc. I'm always using JSON5 instead [1]. [1] https://json5.org/ https://json5.org/

oneeyedpigeon 1y ago
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.
- moogly 1y ago
  Doesn't work with strict schema validators that disallow unknown keys. I'm looking at you, tauri.conf.json.
  - oneeyedpigeon 1y ago
    Interesting; I haven't come across this before. I wonder why they don't just ignore unrecognised keys. Or, at least, give a warning, but continue to work otherwise.
- LauraMedia 1y ago
  It certainly is more for the usecases where you don't use JSON in the intended way (communication between two machines) but as a config, explaining possible values or at least give a URL for a documentation of the config file format.

dev_l1x_be 1y ago

What is wrong with Dhall? https://dhall-lang.org/ https://dhall-lang.org/

hresvelgr 1y ago

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_ 1y ago
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 1y ago
  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.
  - psychoslave 1y ago
    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.
  - Someone 1y ago
    > 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 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.

avr5500 1y ago

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

novalumina84 1y ago

Just what we needed, another JSON with comments! Can't wait for YAML (Yet Another MAML) next week.

gzh18 1y ago

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

themgt 1y ago
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 https://github.com/apple/pkl
praptak 1y ago
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"

mirekrusin 1y ago

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

flanked-evergl 1y ago
Cuelang is so awesome that nobody uses it.
- mirekrusin 1y ago
  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 https://github.com/search?q=lang%3Acue&type=repositories
  - flanked-evergl 1y ago
    Top result: examples repo.
    - mirekrusin 1y ago
      It's unusual to have repository that is close to 100% cuelang, as a config language you'll have very little of it in repository but github doesn't have a good way of finding those.

flanked-evergl 1y ago

Nope. Just nope. Use YAML.

aljgz 1y ago

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.

throwaway150 1y ago
I admire the effort to fix things too. But this is exactly how we end up with 15 competing standards (https://xkcd.com/927/ 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.
p0nce 1y ago
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.

jmloop 1y ago

There is also https://kdl.dev/ https://kdl.dev/

pancsta 1y ago
KDL supports multiline indents properly, unlike this one. No need for MAML, someone simply didnt do his research (outside of JSON).

Shorel 1y ago

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

stared 1y ago

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

modinfo 1y ago

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/ https://vzparse.xyz/

sambeau 1y ago

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.

Someone 1y ago
I think json would be better off if it supported IEEE floats, too. Sometimes, you really have to serialize a NaN or infinity.
- zzo38computer 1y ago
  I think that DER (which is a binary format, although there are ways to make it from text formats) is better, which does have NaN and infinity and other stuff.

pkphilip 1y ago

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

slightwinder 1y ago
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.

ruuda 1y ago

This thing is what triggered me to write https://ruudvanasseldonk.com/2025/abstraction-not-syntax https://ruudvanasseldonk.com/2025/abstraction-not-syntax

rdsubhas 1y ago

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.

deleted 1y ago
[deleted]

ndsipa_pomu 1y ago

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

dominicrose 1y ago

MAML sounds like mammelle in French, but besides that I think that making things optional adds complexity. JSON is simple because it's strict and the syntax parts are not optional. As much as I like writing javascript objects without quotes, it's javascript, not JSON. I don't mind putting quotes in JSON. Plus, it helps distinguishing it from javascript. People don't always agree wether there should be a trailing comma or not. At least with JSON there's no choice. Making a trailing comma mandatory would be weird. Because mandatory is different than "automatically added by Prettier". What I like about JSON is that people can't use it to make weird things like HTMLX on top of it. Even plain HTML is no longer XML. At least JSON is JSON. I don't mind VS Code using JSONC for it's config though.