Honorable mention for Cue[0].

[0] https://cuelang.org/

CUE does look simple enough to be implemented in every language. I wonder if there's anything preventing that. Perhaps there's space for a CUE-like language with an even simpler spec.

TypeScript has at least 2 implementations: tsc and Deno, but I take your point and agree. That said, most languages probably have a JS runtime, so a basic implementation would be ts->js->interpreter. The ts->js is presumably pretty easy.

I'm pretty sure Deno just uses the open source TypeScript compiler: https://github.com/denoland/deno/tree/main/cli/tsc

They use swc for transpilation and bundling but, yes, for checking the only solution available now is tsc

I don't think Deno actually re-implements typescript, does it? Seems like a lot of wasted effort. They don't even use Typescript internally.

Reimplement in the way that they change certain rules to accommodate a more "modern JS" feel

And they absolutely use TS for the std library, just not in the runtime itself

> Reimplement in the way that they change certain rules to accommodate a more "modern JS" feel

What exactly do you mean by this?

> And they absolutely use TS for the std library, just not in the runtime itself

Yes, internally. The code that actually makes up deno itself is just plain Javascript.

Geniuenly curious, what downsides do you see with a single, reference implementation? I come from C++ world where we have several competing compilers, each slightly different from the other, and all this incurs a non-negligible maintenance cost while providing very little benefit in my eyes.

The problem is not a single, reference implementation, the problem is how hard it is to implement another one. "Implementing" JSON is relatively easy, most languages have a JSON library. Most people could probably write a JSON library, not a perfect one, but that would mostly work. And probably do it in a reasonable amount of time. All of that isn't true for Typescript.

Ignoring S-expr based configs for a moment, of the configuration languages, JSON parsing is probably the most straightforward. YAML is a superset of JSON, TOML is probably on par, TS and JS are obviously more complex than JSON, and XML is...XML. All of that is to say, I'd rather write a JSON parser than any of the above.

And JSON parsing is a minefield. http://seriot.ch/projects/parsing_json.html

I don't know of any notable S-expr based config languages, probably because they are so easy to parse, people just roll their own, leading to balkanization.

Windows INI format is going to be easier than any of those. You can parse it in a couple lines in a bash script.

I personally find it silly to need more than that. YAML, JSON, etc. What are we even doing here, besides trying to make life more difficult? Are we doing configuration or are we doing plugins and calling it configuration?

We'd all be better off if we just admitted we really want an extension language and went with embedded Lua or Scheme. With Dockerfile and others you have to run a separate lint program, assuming anyone even bothers doing that. At least with a proper language you would have built-in robustness. Most of these configuration formats/DSLs are half-assed and unnecessary anyway.

As Zababa said, it is more about how easy it is to write another implementation, because config files need to be read in another language than (Typescript in this case).

The easier a config language (syntactically, but also in terms of capabilities), the easier it is to write a parser in Go, and Rust and Java etc. All of this particularly matters for libraries or in larger codebases that are multi-lingual.

Using starlark here because I'm most familiar with it.

Starlark's `load()` statement is "find the file at this exact literal path from the workspace root" (no relative paths allowed either). Typescript/Javascript's import is much more complicated. If you encounter an error in Starlark, you fail right there, no exception handling to implement.

Starlark doesn't allow recursion, has an extremely limited set of built-in types and functions, and that means it is very easy to reason about, and even a naive interpreter is pretty fast at evaluating it. I'm also reasonably certain about writing a simple interpreter for it in a week if I had to port it to a new language.

Of course, I view configuration languages on a continuum.

I'd definitely want a pomodoro timer to just use a .ini file. TOML/YAML is great for where you are just going to have a bunch of plain type assignments. No JSON, because comments.

Once you want to write larger configurations, and you need to provide APIs to the user in the language, I'd pick Starlark/Pystachio because they are still intentionally restrictive and Python is one of the most popular languages out there. At this point, you are probably trying to configure something like a large build system (Bazel) or some kind of deployment cluster (say Kubernetes) and you can start providing all sorts of utility libraries (either via bindings to your programming language, or as Starlark libraries). But due to their restricted nature you can still do all sorts of bounded analysis of the evaluation. You can remove things like random() because it's a bad idea.

Yes there are use cases where you want a full blown language to configure something, but those are extremely rare and at that point I think you are no longer "configuring" but just "programming". I very much prefer to keep these 2 things separate.

If you can afford to wear only one hat, then sure, use one special language for configuration. But I can't, I am the entire infra department and I still need to do product and framework work. Not having to switch context, language wise, is a very nice thing to have.

Why use language designed for configuration? Is it the size concern or something else, cuz I think small langs like Lua make great config language.