There have been several languages claiming to fix SQL and none of them (to my knowledge, I'd love counter examples) have achieved widespread enough adoption to be named a proper successor.

Reasons I can guess:

- SQL's 50 years of entrenchment- all RDBMSs speak it! Most monitoring systems speak it! Any successor language needs a good interop story so people can use it with their existing systems.

- SQL is good enough for run of the mill day to day tasks- and these days by the time I'm lost in recursive queries or window functions, I can ask an LLM for help. Maybe a successor language can win on IDE support or other parts of the dev/agent experience

Successor languages also tend to only replace parts of SQL (usually the queries, not the insert/update stuff). I think PRQL does this (once again I'd love to be wrong). Now the dev has to learn two languages?

I guess my point is that a successor language, can't just fix the semantic issues with SQL, to be successful it also has to provide large ecosystem (and maybe political) steps up. I didn't see any of that in this abstract, which kills my excitement.

Iirc the reason is that the Dart team was willing to heavily modify the language and runtime to accommodate the needs of Flutter and the V8 team wasn't.

I think this is the video that talks about this: https://m.youtube.com/watch?v=xqGAC5QCYuQ

And of course once its set up for a project, adding more tests to it is pretty straightforward. It is slower for each test run, but I had hundreds of tests running serially erasing a MySQL DB before each one and it only took a minute or so, which was well within my tolerance.

So overall I'm a fan; I think there's more benefits than drawbacks. Especially if it's SQLite, where setup is even easier.

Could you go into a little more detail about how you decide to split what's in your Rust platform vs your Roc application?

It's supposed to be a scripting language right you embed into your C ABI right?

Do you see it competing with WASM for the plugin use case (i.e. a really large Roc platform)? Why would an app author prefer to expose a Roc layer to their app rather than a WASM layer? With a WASM layer, plugin devs can write in any language.

Another use case I've heard from it is as a more app-level language (i.e. a really small Roc platform). Do you see it competing with Gleam for server side http code? Do you see it competing with Elm for client side code?

They DO include a nice section at the bottom about why these limitations exist, but I wish they would make the process easier.

(please note that I personally strongly prefer static types, but I still found this an interesting read).

At least from the sidelines, it looks like they've built/forked most parts of the OCaml ecosystem to make it work (OxCaml, Dune was built by then, custom profilers, custom networking hardware, etc).

Of course a lot of their work is open source and can be used, but I wouldn't assume that it would be worth the effort to do something similar with OCaml yourself. Maybe it is! LLMs go brrr and all that.

In Python, a "class" is simply a dict under the covers and (by default at least) you can add attributes to it after definition (as well as things like properties). So it's difficult to reason about what the fields are at any given time. And that's assuming people USE classes! I've seen code where all the state is in one giant ever-changing dictionary and you have to pull out a debugger just to figure out what's IN the thing! God help you if you mispell a key!

Maybe you work with better quality code than I do, but I find Go's type system a lot easier to reason about than Python's.