You surely meant to write "a loong way", right?

I for one am glad there is a commercial angle to the project. Done right, it means more hours could go into making things better, in a sustainable way. Also, having paying users provides a strong incentive to keep the technology grounded / practical.

Without the commercial stuff, Unison would be just another esolang to me. Now I'm probably going to play with it in upcoming side projects.

I think the idea is to store-and-forward IP packets, then use QUIC on top of that

> by the time there are only a few relay satellites around a planet.

Based on the limited information I have, I think it will take decades (at least) to get there for most planets. Hopefully the results of this research will be useful for a long time.

OP here. I'm also looking forward to an ending! I'll definitely write more once our research has made more progress :)

Would you mind sharing a bit more? Have you used them? How did that go?

I use `jsonata` currently at work. I think it's excellent. There's even a limited-functionality rustlib (https://github.com/Stedi/jsonata-rs). What I particularly like about `jsonata` is its support for variables, they're super useful in a pinch when a pure expression becomes ugly or unwieldy or redundant. It also lets you "bring your own functions", which lets you do things like:

``` $sum($myArrayExtractor($.context)) ```

where `$myArrayExtractor` is your custom code.

---

Re: "how did it go"

We had a situation where we needed to generate EDI from json objects, which routinely required us to make small tweaks to data, combine data, loop over data, etc. JSONata provided a backend framework for data transformations that reduced the scope and complexity of the project drastically.

I think JSONata is an excellent fit for situations where companies need to do data transforms, for example when it's for the sake of integrations from 3rd-party sources; all the data is there, it just needs to be mapped. Instead of having potentially buggy code as integration, you can have a pseudo-declarative jsonata spec that describes the transform for each integration source, and then just keep a single unified "JSONata runner" as the integration handler.

We've had a great experience with JSONata too.

It's nice because we can just put the JSONata expression into a db field, and so you can have arbitrary data transforms for different customers for different data structures coming or going, and they can be set up just by editing the expression via the site, without having to worry about sandboxing it (other than resource exhaustion for recursive loops). It really sped up the iteration process for configuring transforms.

I confirm. At first I was trying to write that "buggy" code, until I got jsonata, and started working with the queries it supports.

It made my life a lot easier

Last time I had to create a C# desktop app, I went with Blazor Hybrid [1]. I'd say it's "Electron for C#". I don't want to use outdated stuff like WPF / WinForms, and I don't trust more recent frameworks, so for me building on top of the web platform felt safest.

[1]: https://learn.microsoft.com/en-us/aspnet/core/blazor/hybrid/...

Just tested this on the playground and observed that the following does work:

    "price_in_€": 42

Or were you already aware of that and lamenting that KSON requires quoting in this case, compared to YAML which doesn't?

Was lamenting the bare IDs' limitation, quoting is bad here since there is no ambiguity to resolve, no type to signal. All these new improved formats should strive to limit the bad parts of existing languages, not eliminate the goods ones

I think the current grammar should be precise enough for that, though it's embedded in the source code as a comment and not in its own file (see https://github.com/kson-org/kson/blob/857d585ef26d9f73e080b5...). It probably can't be fed verbatim into a parser generator, but anyone who reads the parser's source code should have an easy time writing a parser by hand for their programming language of choice (heck, they might even have an LLM translate the original parser into whatever language they want, once there is a comprehensive conformance test suite to validate the resulting code).

All in all, I'm confident that KSON can become ubiquitous despite the limitations of the current implementation (provided it catches on, of course).

I've often reached out to TOML for truly minimal configuration files, so I'd say TOML makes sense in a lot of scenarios. However, my point in the article is that simple stuff eventually stops being simple, so you need to be careful.

As an example, a friend of mine introduced TOML to a reasonably big open source project a while ago. Recently, he mentioned there were some unexpected downsides to TOML. I've asked him to chime in here, because I think he's more qualified to reply (instead of a best-effort attempt from my side to faithfully reproduce what he told me).