wofo

That took some design work! In the end, KSON settled on something called the "end dot", which denotes the end of an object (more details in the docs, at https://kson.org/docs/syntax/#the-end-dot).

Didn't know about RCL! The project readme looks promising. I'll have to take it out for a spin. Thanks for creating it :)

Glad you liked the format. I hope we can close the implementation gaps as development advances, and I'd love to see native libraries sprout for all conceivable programming languages!

Edit: point taken about verifying checksums, just created an issue for it (https://github.com/kson-org/kson/issues/222)

Thanks for the kind words :)

This sounds like the kind of question for Daniel himself to chime in, since he has the best overview of the language's design and vision. He's not super active on HN, but I'll give him a heads up! Otherwise feel free to join our Zulip (https://kson-org.zulipchat.com) and we can chat over there.

This sounds like a stricter version of KSON's current warnings for misleading indentation... maybe KSON should have an opt-in feature for this. Thanks for the idea!

I like this take! Have you used Cue or RCL yourself? How was the experience?

Hmmm that's interesting. KSON actually shows a warning when there's misleading indentation, exactly to prevent this sort of thing! It seems like the detection logic only considers indents after a new line, so it doesn't complain in this case. I just opened an issue to see if things can be tightened up a bit (https://github.com/kson-org/kson/issues/221).

To see misleading indentation warnings in action, you can try the following snippet in the playground (https://kson.org/playground/) and will properly get a warning:

    ports:
       - 80
       - 8000
         - 10000
       - 12000
       - 14000

Next to that, note that KSON already has an autoformatter, which also helps prevent misleading indentation in files.

I met Daniel (creator of KSON) a while ago and have helped out with a few things, working towards this first beta release. I don't want to hijack the comments section, but there's an article I just finished writing that might shed a bit of context into why KSON exists. It's called "Configuration files are user interfaces" (see https://ochagavia.nl/blog/configuration-files-are-user-inter...). Hope it helps folks understand where KSON is coming from!

Having worked on a few Rust projects that interface with C libraries, I think your last question is a good summary: once you introduce a C API boundary it's back to tools like Valgrind.

Maybe you could even say Zig is at an advantage there, because tools like Valgrind are considered part of the game, whereas in Rust they are way less commonly used (pure-Rust codebases don't need anything of the sort, unless you are using `unsafe`).

As someone with the luck of having mentored many people, it makes me happy to see they are doing well and making an effort to share what they have received (e.g., through volunteering or mentoring others). That's all the gratitude I want.

Ludicity has blogged about his journey from having a shitty job to running his own company in the past. Writing played a big role there (see e.g. https://ludic.mataroa.blog/blog/merry-christmas-ya-filthy-an...).

Not really internet-related, but I prefer donating to local initiatives run by people I trust, usually directed to improving people's lives (health, education, etc). These projects are not "famous", but have a noticeable impact, and are IMO wiser in their spending than some huge non-profit organizations (e.g. they don't spend money in huge bonuses, or in advertising campaigns to get more money).

What the OP proposes is not exactly a bigger stdlib, because they mention it should have "relaxed stability guarantees". Or is python allowed to change their stdlib in backwards-incompatible ways?

I faced a related dilemma when I finished my CS degree: to work as a full-stack dev or to work on more foundational technology (and actually use what I learned in my degree). My experience is that the "foundational technology" area is more "research-oriented", which means you get to work on projects where LLM's don't help that much: writing code in languages that have little data in the LLM's training corpus, coming up with performance benchmarking approaches unique for your application, improving a workload's throughput with insights derived from your benchmarking results and your ingenuity, etc. Had I gone down the full-stack path, I think I'd be worried now.

I've thought about this (albeit not for that long) and it seems like you'd need a non-trivial revamp of how we communicate with the operating system. For instance, allowing a library to "read from a stream" sounds safe until you realize they might be using the same syscalls as reading from a file!

There are some voices trying to address this security risk (e.g. the proponents of this new RFC: https://github.com/rust-lang/rfcs/pull/3810). However, for some reason (probably culture) there isn't much momentum yet to change the status quo.

Some people _do_ care about this (e.g. the proponents of this new RFC: https://github.com/rust-lang/rfcs/pull/3810). However, for some reason (culture, I guess?) there isn't much momentum yet to change the status quo.

Actually, a proposal for exactly this was published yesterday: https://github.com/rust-lang/rfcs/pull/3810

It's unfortunate that the response so far hasn't been very positive

Good luck in your adventure! By the way, I think many people here on HN (myself included) would love to help you out if you get stuck / are struggling to get started / want a code review / want to chat about programming. Just shoot any of us an email ;)

Thanks for the example! It has helped me understand better the use case of AEAD for at-rest-encrypted-data.

I finally updated the example to a new one, though it's still message-based (it fits the rest of the article better). If I had come across your example earlier, I might have stayed away from a message-based formulation of the problem at all... Better luck next time I guess :)

Thanks for the kind words! I'm trying to balance pragmatism with depth. Glad it was useful to you ;)

It looks like I actually got the example wrong, sorry about that!

Somehow I assumed that the server was able to authenticate the receiver id, but as you correctly point out, that would require knowing the encryption key. I'll have to think about a fix for the example.

I've been pretty disappointed with eStargz performance, though... Do you have any numbers you can share? All over the internet people refer to numbers from 10 years ago, from workloads that don't seem realistic at all. In my experiments it didn't provide a significant enough speedup.

(I ended up developing an alternative pull mechanism, which is described in https://outerbounds.com/blog/faster-cloud-compute though note that the article is a bit light on the technical details)

FWIW, Fred Brooks has a quote that is similar in spirit to the one you mentioned. It's in Chapter 1, The Tar Pit (under the title The Joys of the Craft):

> Finally, there is the delight of working in such a tractable medium. The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by the exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures…

Oops, good catch! Thanks!

> It takes guts to defend non-extremist positions, because the extremists will always have more powerful one-liners.

Thanks for that quote :)

That's what I thought originally, but you can actually use `https://<your-bucket>.s3.amazonaws.com` without Cloudfront or other service on top (it wasn't easy to find in the AWS docs, but it works)

I tried using that API directly, but it unfortunately did require ordered uploads too :')

Yep, I originally thought that wouldn't work... But now I discovered (thanks to a comment here) that the registry is allowed to return an HTTP redirect instead of serving the layer blobs directly... Which opens new possibilities :)

To be clear, the 8x was comparing the slowest ECR throughput measurement against the fastest S3 one. In any case, the improvement is significant.