forgotpwd16

Tbh, thought this will be just another proto (where proto:=9p in this case) implementation without a use-case in mind. Pleasantly surprised this isn't the case.

As per #Reasoning section, author made this to provide* a procfs-like API for Erlang. If only think of Erlang as programming language, this may sound odd. What it means for a programming language to have procfs? Well, Erlang VM is more like a tiny operating system than a typical runtime. It has its own processes, scheduler, supervisor, and message parsing. Exposing these "system objects" via a fs API is just like /proc exposes kernel state on Linux.

*A similar FUSE-based NIF-implemented project is mentioned but author bring up cross-compilation as problem. Perhaps more important, libraries used through NIF may degrade performance or even crash the entire VM. So in Erlangland re-implementing protocols in pure-Erlang is quite common.

Unusual concept. Will split my thoughts on implementation and adoption (in regards to design).

Implementation-wise: Tried myself something similar. One language (same core & lib & built-ins) with 2 front-ends that had different syntax and, but similar, semantics. (Didn't go far though.) An issue is not favoring one over the other. Inevitably, in a meta way, you'll if decide to self-host since will've to pick one form to do it. Also, having multiple co-existing forms in same file may complicate tooling.

About the last part, most similar things I've seen are: (i) Perl Mojo's embedded templates which can be included in same file with source code, (ii) Racket's #lang multi-file which allows combining, well, multiple files (thus also use different #lang directives) in same file.

Adoption-wise: It's in a weird position for widespread adoption. There's strong preference towards using a single language which splits into 2 branches: (1) using single language across every layer (basically Rust/Zig), (2) using high-level language with native-competive performance (Python+numpy, jax, etc / JS+ultrafast JIT / Julia).

Currently you target both (one base language) and none (different syntax/semantics). Could move towards an hybrid approach instead by having one syntax and high-level / low-level forms (uncertain what distinguishes kernel/baremetal currently). So some functionality may end up showing differently in the 2 cases to be more acceptable by both camps. This will probably also simplify tooling creation/maintenance.

Of course, since the project is quite experimental in nature, keeping it current way is interesting and very acceptable.

TL;DR Yes (~templating) - Yes (complexity, lower potential adoption) - No (unusual, experimental)

Partially reminds me (due to _V,_f,_F,f,F) Whitney's ksimple implementation[1].

[1]: https://github.com/kparc/ksimple/tree/main/ref#ac

Crazy. But then again Unix-like kernels/systems have been implemented so many times as hobby or/and part of university courses, that models are probably overfit on them. Seeing Nano, a interesting twist (besides human-free) will've been to instead target Nano rather C.

This is nice writeup. Thanks. Another commenter said will've taken them 2h just to sketch out ideas; sans LLMs will've taken me more than 2h just to collect all this info let alone start optimizing it.

Instructions?! Just asked since GP already did it. No need to realize top comment's "DDOS attack on other AI companies" joke.

This tool seems agent-oriented for them to merge, rather merely check readiness. In that regard, the page doesn't mention anything about human reviewers, only AI reviewers. Honestly wouldn't be surprised if author, someone seemingly running fully agentic workflows, didn't even consider human reviewers. If it's AI start-to-end*, then yes, quite possibly could push directly to master without much difference.

Call me pessimistic, and considering [1][2][3] (and other similar articles/discussions), believe this tool will be most useful to AI PR spammers the moment is modified to also parse non-AI PR comments.

*Random question: is it start-to-end or end-to-end?

edit: P.S. Agree that it's useful, given its design goals, tool though.

[1]: https://old.reddit.com/r/opensource/comments/1q3f89b/ [2]: https://devansh.bearblog.dev/ai-slop/ [3]: https://etn.se/index.php/nyheter/72808-curl-removes-bug-boun... (currently trending first page)

That repo is quintessentially surreal. AI-written code, published in AI-made PRs, reviewed by multiple AI bots (one of which being same model that wrote code & made the PR, maybe others too just accessible via 3rd vendor), merged by AI (assuming dogfooding).

Unless misread, 2 hours isn't the time limit for the candidate to do this but the time Claude eventually needed to outperform best returned solution. Best candidate could've taken 6h~2d to achieve this result.

Could you make a repo with solutions given by each model inside a dir/branch for comparison?

Cool concept. (Legit project overall too.) Any chance it expands beyond Claude, e.g. Codex, OpenCode? Also, unless misunderstood those commits happen in currently working branch? If yes, an option to have the code/sessions mix in alternative (not working) branch will be nice too, as not every project would want to fill history with sessions.

>Managing agents, crafting skills, building docs, designing workflows

You're describing the modern edition of people obsessed with their "development" environments. The ones who treated their system (usually Linux) and text editor (usually Vim or Emacs) like a canvas, perfecting their configuration the way an artist refines a masterwork. Choosing packages and themes like a painter choosing brushes. Younger people of this mindset are now obsessed with multiple LLMs, multi-agent workflows, MCPs, and similar.

In contrast, there's the modern version of the people who used to just open an IDE and copy-paste snippets until they got the result they wanted. Now, those same people simply open Claude Code and prompt: "make me this app", "modify this", "do this more like that", and so on. Those are vibe coders. The only thing that's changed is a lower barrier, less effort, and faster development; yet somehow higher quality since SOTA LLMs output better code than most juniors used to.

And last there's the midway. People who set up their environment, without it becoming the main focus.

Just few extra dimensions and you can handle anything.

Cannot wait for my eyes to suffer when ludicrous mode becomes the next popular CAPTCHA method. Also, this was an interesting response: https://files.catbox.moe/jiw75z.png.

>The Hustle

This should've been the entire site's name, not just a project's.

Today in first page: https://blog.emilburzo.com/2026/01/running-claude-code-dange... (discussion: https://news.ycombinator.com/item?id=46690907).

This is awesome. Thanks for chatgpt-shell.el too. Could use authinfo for api-keys so don't have to put them inside config (saved in ~/.authinfo, format eqv. to ~/.netrc).

>Accuracy: 99.9997%

That's terrible. Currently α is measured to relative uncertainty 1e-10.

>What I'm claiming: Not numerology.

It's just numerology.

>The series structure maps to QED's perturbation series.

Don't see the map; see no attempt to show this in paper either.

Is this the correct link?

Rust Cookbook states it's a collection of examples to accomplish various tasks, some with brief explanation. But nothing that could be called article/talk/repo.

Should note, for anyone curious, that learning idiomatic Rust off those examples isn't straightforward.

E.g. https://rust-lang-nursery.github.io/rust-cookbook/file/dir.h...

The explanation simply states what the code is doing, the classic sin of code commenting. But no explanation given on why `anyhow::Result`, `main() -> Resut<()>`, `?` operator, `{:?}`, ... are used. If wanted to learn, those are what one would care about. But, if looking for a snippet to use for a task, what the cookbook is about, then is fine.

>It does lend itself better to "tokenization" of a sort - if you want to construct operations from lots of smaller operations [...]

That's an educated assumption to make. But therein lies the issue with every LLM "optimized" language, including those recent ones posted here oriented toward minimizing tokens. Assumptions, that are unvalidatable and unfalsifiable, about the kind of output LLMs synthesize/emit when that output is code (or any output to be real).

Seems like a simplified Rust with partial prefix notation (which the rationale that is better for LLMs is based on vibes really) that compiles to C. Similar language posted here not too long ago: Zen-C => more features, no prefix notation / Rue => no prefix notation, compiles directly to native code (no C target). Surprisingly compared to other LLM "optimized" languages, it isn't so much concerned about token efficiency.

There's a risk but imo think there's some overreaction. Plus should keep backups anyway. Have had few disks failing on me that fear to have any important data with single copy. If want to be on the safe side though: Create container/VM. Do agentic work inside. Git commit/push outside often/every-step.

The LLM output isn't an unfiltered result of an unbiased model. Rather, some texts may be classified high-quality (where the em-dash, curly quotes, a more sophisticated/less-everyday vocabulary are more expected to appear), some low-quality, and some choices are driven by human feedback (aka fine-tuning), either to improve quality (OpenAI employs Kenyans, Kenyan/Nigerian English considered more colonial) or engagement through affirmative/reinforcing responses ("You're absolutely right. Universe is indeed a donut. Want me to write down an abstract? Want me to write down the equations?"). Some nice relevant articles are [1],[2].

[1]: https://marcusolang.substack.com/p/im-kenyan-i-dont-write-li... [2]: https://www.nytimes.com/2025/12/03/magazine/chatbot-writing-...

If you want next, I can:

- Tell you what makes em dashes appealing.

- Help you use em dashes more.

- Give you other grammatical quirks smart people have.

Just tell me.

(If bots RP as humans, it’s only natural we start RP as bots. And yes, I did use a curly quote there.)

>That's not about AI replacing developers - it's about unlocking latent capability in people who already understand the problem space.

Feel like forums have turned into a grand Turing Test.

>many nontrivial and creative ways to do pdf processing

They're all wrapping PDFlib and provide the same functionality.

Not even couple of months. Just within last month.

All with similar design, similar implementation, similar HN post. Literally AI slop.

Also:

Show HN: BentoPDF is a privacy first PDF Toolkit

https://news.ycombinator.com/item?id=46657892 (this one just yesterday)

Show HN: NoUploadTools – Free Tools that don't upload your files

https://news.ycombinator.com/item?id=46516400

Show HN: TechRex – client-side PDF editor (no upload, no watermark)

https://news.ycombinator.com/item?id=45611498

Very cool. Realtime interactiveness without writing JS, capable enough for simple games. (Although had hard time playing it; damn snake moves too fast to control with clicking buttons.)

Unexpectedly wasn't asked: How it compares to Redox, another message passing microkernel system written in Rust? Also, what for embedded devices means? What specific features has that other microkernel systems don't, or just means is limited in scope*?

*Contrast to Redox that is meant to be general purpose but also offers an embedded-oriented minimal version.

>just goes to show the sort of shit research going on over the years.

Psychiatry borders pseudo-science afterall. And there's the more general replication crisis (with psychology at the focus) fuelled by the fact that positive results are more publishable and that publishing negative replications is hard (those affecting entirety of science).