wofo

Sounds like babysitting an LLM, with the alarming difference that this AI can kill you if you are not paying enough attention

Out of curiosity, is there a build setup you have seen in the past that you think could be a good replacement for this complex GitHub CI setup? Asking for a friend ;)

Update: now I've finished reading the article, my impression is that complexity is mostly inherent to this problem space. I'd be glad to be proven wrong, though!

Does this mean we should be migrating our SSH keys to post-quantum crypto right now?

Thanks! It's always scary when container technology fiddles with your network... I wonder how they can be at peace with such defaults. Another reason to stick with good old containerd units, I guess.

Surprised Teeworlds hasn't been mentioned yet (https://teeworlds.com/)

It would be better not to post urls to the blog, to prevent it from getting links and get even higher in search results...

Could you share more details about this? Do you mean that e.g., if I run LXD/Incus on a machine with a public IP address, anyone on the internet could route traffic through it?

Many QUIC features get implemented while in draft stage as people iterate on the RFC's design (e.g., ACK Frequency[0] is currently on draft version 14 and I implemented support for it three years ago in quinn).

[0]: https://datatracker.ietf.org/doc/html/draft-ietf-quic-ack-fr...

Thanks for posting this! As a long-time Rust user (and contributor, in the good old days), the thing that has always fascinated me about Rust is the healthy balance it strikes between academic brilliance and industry pragmatism. Radical changes like the ones suggested by the OP risk damaging that balance IMO. I'd rather put up with some language quirks and see Rust achieve "boring technology" status...

But who knows, maybe the "academic brilliance" from the article is more pragmatic than I give it credit for. I sure hope for it if these changes ever go through.

That's what I actually used to fix this one! I'm not too deep into the JVM ecosystem, so I gave Claude a try just in case... and it fixed it :)

Btw I didn't mention it in the blog post, because I think that would have derailed the conversation (after all, the point of the article is not "use LLMs", but "fix your tools"). In any case, I agree that LLMs can make it easier to fix the tools without getting side-tracked.

Calling Kotlin from Rust (and other languages) is useful when you want access to an existing Kotlin codebase and would rather avoid creating a full-blown port. I guess most people don't do things like this because creating bindings for languages that are not C (or C-like) is usually cumbersome. Krossover is trying to fill that gap for Kotlin. Does that make sense?

I got a notification through F5 bot (https://f5bot.com/)

OP here, thanks for submitting!

Thanks for taking the time! I love being able to see through abstractions too, but for web applications I'm looking for a bit more "magic" (e.g., .NET's EF Core is the gold standard for what I'd look for in an ORM).

It's been a while since I last had a detailed look at web applications in Rust (i.e., stuff with databases, auth, etc). You could use axum for the web server, which is very mature, but I'd say it's too low-level (IIRC you cannot even generate an OpenAPI spec of your endpoints, which IMO is table-stakes). Have you found something more batteries-included, with a similar level of maturity, and actively maintained by a community you can trust? It's a very high bar.

Your reply made me curious about ORMs, btw. Which one would you recommend? Maybe things have improved since I last checked. Last time I didn't like any of them and ended up settling on `sqlx` + hand-written SQL (the code is open source, hosted at https://github.com/rustls/rustls-bench-app/tree/main/ci-benc...).

I'm a heavy Rust user and fan, but I'd never pick Rust for web. There are way more mature ecosystems out there to choose from. Why would you waste "innovation tokens" in a Rust-based web application?

Spelling mistake, I'd guess? The spanish word for it is inyección.

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?

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

> If your config format requires autoformatter and/or linter to detect trivial mistakes, it is junk.

IMO this way of thinking disqualifies lots of legitimate configuration formats, but to each their own I guess.

(Update: my article eventually made it to the frontpage and stayed there for a good time, so there's interesting discussion there that people here might want to check out. See https://news.ycombinator.com/item?id=45291858.)

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?

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

A friend of mine introduced TOML to a reasonably big open source project and he mentioned there were some unexpected downsides to it. I've asked him to chime in here, because I think he's more qualified to reply (note that I pointed him to a sibling comment that's also asking about TOML, here https://news.ycombinator.com/item?id=45295715).

As for Apple Pkl, I think we share the goal of robustness and "toolability", but pkl seems way more complex. I personally think it's more useful to keep things simple, to avoid advancing in the configuration complexity clock (for context, see https://mikehadlow.blogspot.com/2012/05/configuration-comple...).