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.
Maybe I'm not getting something here, but I find the pledge/unveil approach confusing.
Why should I expect a program to set allowed syscalls/filesystem paths? Why would I trust that it will set itself the right permissions? What is allowed should be set externally from the program, similarly how I can map filesystem volumes and add capabilities to a Docker container [1].
I'm not familiar with BSD and I only used it a couple times out of curiosity. What am I missing?
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.
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
After running NixOS for 6+ months on my homelab and also re-using part of the configuration on my work machine, I feel the same way as Xe each time I'm interacting with a non-declarative OS. There's just no simple way to share configuration between machines or to automagically clean things up after making changes.
Ansible feels like a thin layer of ice upon a deep ocean of the OS state, hiding in a multitude of non-tracked configuration files. It is simply not enough to build a layer of YAML around an OS which is imperative by nature.
Unfortunately, I can see the downsides of NixOS as well, being radically different from what we usually expect in a Linux distribution, adopting it in a already established environment will no doubt be hard. Steep learning curve, idiosyncracies of the Nix language (although after reading parts of the Nix thesis[1], I find it much more understandable and deeply thought out), just explaining Nix to people who don't have much experience with the functional way of doing things, let alone taking the functional approach all the way to defining an entire operating system - all of this sounds like a tough barrier to cross.
And yet, the desire to keep things reproducible and declarative (not to mention going back in time) persists once you've had the taste of NixOS.
I suggest you try something like LunarVim[1] or NvChad[2] for a ready-to use IDE-like neovim configuration.
I had the same problem with configuring (neo)vim, it's simply too much work to get a reasonable IDE experience.
Using an already well tested and documented configuration helped me to make the switch.
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.