wint3rmute

I've heard an interesting argument about this while going down the rabbit hole of the hard problem of conciousness. Unfortunately can't rember the source - if you can recognize it, do let me know!

Back in the XVII/XIX century, a similar problem existed regarding life - the problem of "what makes living things tick". The assumption at that time was that while we can understand the biological processes around life, we will never understand the so-called "vital force", which causes things to live - life itself. I know it sounds weird now, but back in the day the mental models were different. Phenomenas like "water boils" and "organisms self-replicate" were treated as completely different domains of reality, without an overarching uniform scientific model.

It turned out that after around 100 years, we can figure out the chemical/physical processes and the need for the term "vital force" became redundant.

While this is certainly not an argument proving that the Hard Problem is not in fact hard, it is an interesting idea to think about. Perhaps its all a matter of developing better, higher-resolution neurological models which will at some point give us the tools to decompose qualia.

Even a simple coding agent TUI should work instantenously, which I sadly cannot say is true about typescript-based applications like Claude Code or Gemini.

After switching away from GNOME Terminal + Zsh to Ghostty + Nushell, I started to appreciate how instant everything feels. Why not make everything just as fast?

This is especially true for newcomers, but async Rust has significant mental overhead. You quickly run into things like the Pin marker, Tokio runtime, complex compiler errors related to ownership, basically each "normal" component of the language get some additional complexity due to async.

If you're new to Rust and you want to "just make a web app", the view at the async Rust landscape could be a turnoff for novices. I speak from experience, having started a couple Rust projects in Python/C++ teams. After writing in Rust for 3+ years I can navigate async contepts without troubles, but for someone coming from the usual popular languages (Python/C#/Java/C++), there are simply too many new things to learn when jumping straight into an async Rust codebase.

IMO this framework is going in a good direction, assuming that it will only be used for small/educational projects.

For the async Rust landscape, things are improving every year, IMO we're around 5-10 years until we get tooling which will feel intuitive to complete newcomers.

That was my first thought as well, seems to fill a very similar niche, just for systemd instead of kubernetes

This, but also learn to configure other linters, not only things bound to a specific IDE. Learn from the errors that linters raise, their documentation usually has a "rationale" section for each rule.

Ideally you should also run those linters in CI/CD. When a new member joins the team, they will get CI/CD linting for free, which will save you a ton time for each new team member

> Enabling ChatGPT to work with most compatible apps requires the macOS Accessibility API to query content.

I wonder if the AI boom could have an unexpected effect of improving accessibility features across applications, as a byproduct of integrating various AI solutions.

Nope, didnt event knew such a thing existed :)

I'm doing PDF document generation in typst, the format I'm generating is similar to invoices (specific to how the law in my country is, but that's a longer story).

Typst code generation was easy to automate with trivial python templates (jinja2). The core part of my document are multi-page tables, and typst splits them nicely.

I had to google around a bit, as there are multiple settings on how large tables are handled, I suggest that you give Typst a try, you can build a working prototype in no time

You only have to set up CI/CD once for each package type, afterwards all the packaging work is done for you automatically.

Ripgrep is also quite a large project (judging on both star count and contribution cout), so people probably volunteer to support their platform/package manager of choice.