Hacker News: reallyreason

New comment by reallyreason in "Cloudflare OS: an open platform for agents, apps, and work"

reallyreason — Wed, 05 Aug 2026 15:20:14 +0000

Indeed, at this point it's one of the most devalued terms in software. Every week I'm reading about some product calling itself "the Operating System for XYZ." It seems like it's what you do when "platform" just feels too modest. To me, if it's not bootable, calling your product an OS just reeks of marketing sleight of hand.

New comment by reallyreason in "[dead]"

reallyreason — Sun, 12 Jul 2026 17:49:58 +0000

Clicked through to the custom language it's implemented in ("Freedomlang") and was met with a bunch of really confusing AI-authored stuff.

> macOS emits x86-64 AT&T assembly

Seems like an obvious issue given that Apple makes no x86 machines, hasn't for three years, and plans to sunset Rosetta 2 in one year. The whole conceit of this "Freelang" project is that it has no "magic", and then incredibly just a bit further down the README states it has a stop-the-world mark/sweep garbage collector. That is quite magical, no? After reading the GitHub I confess I don't even understand what "magic" the authors are even complaining about. Honestly it seems like it's basically the same concept as Go, vibe-coded, with more pretense, worse syntax, and without the benefit of Google engineering.

You could implement the same functionality in Rust, using a custom target JSON without any libstd/libc. I've done so. It just requires that you accept some limitations and build your own abstractions around unsafe syscalls.

New comment by reallyreason in "Async Rust never left the MVP state"

reallyreason — Tue, 05 May 2026 15:16:54 +0000

It could also be argued that putting a specific executor model into the standard library will make the problem worse because it will give library crates license to use it without considering alternatives because it is standard. At least today taking a dependency on a specific runtime is a well-known boondoggle .

New comment by reallyreason in "Async Rust never left the MVP state"

reallyreason — Tue, 05 May 2026 15:13:49 +0000

It really depends on the abstraction model of the library. If the library needs to actually read/write a file, it either needs to depend on a runtime or provide some horrific abstraction over the process it will use to do that. This doesn't apply to sync IO libraries which can just use the Standard Library.

Web/server frameworks have to bind to a runtime because they have to make decisions about how to connect to a socket. Hyper is sufficiently abstract that it doesn't require any runtime, but using hyper directly provides no framework-like benefits and requires that you make those decisions and provide a compatible socket-like implementation for sending requests.

New comment by reallyreason in "Async Rust never left the MVP state"

reallyreason — Tue, 05 May 2026 15:03:33 +0000

I think that's the problem in essence, yes. Different executors built on top of different primitives and having different executions strategies will have mutually incompatible constraints.

To spawn a future on tokio, it has to implement `Send`, because tokio is a work-stealing executor. That isn't the case for monoio or other non-work-stealing async executors, where tasks are pinned to the thread they are spawned on and so do not require `Send` or `Sync`, so you can use Rc/RefCell.

Moreover, the way that async executors schedule execution can be _different_. I have a small executor I made that is based on the runtime model of the JS event loop. It's single-threaded async, with explicit creation of new worker threads. That isn't a model that can "slot in" to a suite of traits that adequately represents the abstraction provided by tokio, because the abstraction of my executor and the way it schedules tasks are fundamentally different.

Any reasonably-usable abstraction for the concept of an async runtime would impose too many constraints on the implementation in the name of ensuring runtime-generic code can execute on any standard runtime. A Future, for better or worse, is a sufficiently minimal abstraction of async executability without assuming anything about how the polling/waking behavior is implemented.