bbkane

As a desktop Linux enthusiast, I LOVE that I can paste error messages and descriptions of problems into a chat and get (usually) reasonable solutions for them.

As a recent example, my /boot partition kept filling up. ChatGPT walked me through the root cause (leftover kernels after updates), mitigations (deleting older kernels), and future prevention (installing unattended-updates and enabling its config file).

> For example, Moses is easy to recognize at lower right, because of the glowing horns

I'm sorry, what? Why is Moses depicted with glowing horns?

It's unfair, but my first thought after reading the abstract was "oh great, another one".

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.

I'm not sure why you're being downvoted, it's a super reasonable question.

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

Why macOS instead of Linux? For the extra challenge?

Once you've done it a time or two, setting up the "clone the db"/"erase the db for each test" pattern isn't that much work (plenty of libraries to help too).

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.

Thank you, will check this out

Any chance you could write a hello world repo of this stack and post a link here?

What countries do this?

Thanks, I've starred your repo and I'll come back to it once Roc is more mature!

Were you able to add the tests that stop regressions in the future?

Thank you grayrest- I didn't realize Roc had to be the one that produced the binary.

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

There's also Rhombus now: https://docs.racket-lang.org/rhombus-quick/index.html

Tangentially relates, but if any Roc devs are around I'm curious about the use cases for Roc.

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?

Is the final reveal a link to this comment?

Not an exact solution, but you can set it so it tells you upcoming turns and directions. With that I haven't needed to look at the screen much

I clicked the link to see this image and wasn't disappointed. It's fantastic!

Yes, the process at https://www.sqlite.org/lang_altertable.html is super risky - 12 steps and a giant CAUTION sidebar about the data loss possible if you do it incorrectly.

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

the SQLite team explains their preference for dynamic types here: https://sqlite.org/flextypegood.html

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

The Cargo folks actually have caching funded for a bit (though I'm not sure how well it interacts with worktrees)! See https://rust-commercial-network.github.io/rcn/funding-direct...

Jane Street has unlimited engineers and money to do this.

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.

At least in C and Go, you can get structs where it's easy to reason about the fields.

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.

Can they dig for exploitable CVEs if they're not on the Wireguard network? It is a clue to your infrastructure, but I personally think the simplicity is worth it.

You first!

I think of Elm more as an incredibly influential research language these days.

It's very focused, there's no public roadmap or official support and the leadership (which is far as I can tell is just Evan) is uninterested in most (any?) community building or core team building.

But MAN is it nice to work in. This has resulted in several forks/spin-offs. At the recent Gleam conference, Louis Pilfold joked that every Elm user maintains their own compiler :). There are at least 6 of them (two more got announced in the last month, even as the community keeps shrinking).

So I'm glad Evan is now working towards 1.0. Maybe folks can call Elm "finished" and one of the successors can do the hard work of unifying some of the forks and growing the community.

Personally, the next time I'm looking for an Elm-like thing, I'm going to check out Gleam + Lustre. Seems to have a nice mix of maintainers that care about community and design. And it works on frontend + backend!

I actually enjoyed the layout, even though I had to use landscape mode on my phone to comfortably read it. It's nice to see new formats

Hey can you do this high priority thing real fast? It shouldn't affect your timelines, just throw some AI at it

Can someone smarter than me explain why someone would choose this over the US dollar?

I love reading the little vignettes of history. Thanks for posting!

Thank you! I appreciate your taking the time to reply