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?
The threat vector is not that you don't trust the program, pledge/unveil is completely unsuitable for that. but that you worry the program will be compromised while it is running.
so the observation is that programs tend to have a startup state where they need access to files and a run state where they don't. so pledge/unveil is a mechanism for a program to inform the os that it no longer needs access to files/syscalls and any future access should be considered a hostile takeover. please kill me.
> Why should I expect a program to set allowed syscalls/filesystem paths? Why would I trust that it will set itself the right permissions?
Because the admin or owner will know FAR less about what a complex program needs at all times, and when it will be safe to drop privs. A database might be tested for a week and then it has a special snapshot thing done for the monthly backup and you did not foresee this, whereas the coders would know what perms are needed in order to do these dumps. Hence, you can't set perms just once before starting, and as a user of said software, you can't expect to just make a quick test and then design a fully working harness for it either.
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.
That would be nice, but my guess is that changing legacy applications would be too hard, and what we'll see is AI apps using vision models to interact with most other applications, like what Claude's computer use does. This would help accessibility, but indirectly.
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.
> “A build is reproducible if given the same source code, build environment and build instructions, any party can recreate bit-by-bit identical copies of all specified artifacts.”
> Neither Nix or NixOS gives you these guarantees.
This really makes me question whether all of the quirkiness of Nix is worth it if it can’t actually “pay off” with true reproducibility.
Nonetheless, Nix/NixOS is more reproducible than the majority of other build systems and distros out of the box. But yes, if this is a hard requirement, you’ll be better off with a different choice.
Keep in mind that this is but one of the features NixOS provides. I would say the config-driven approach to OS management is extremely powerful.
As an example, I could bring up my homelab’s external reverse proxy on a generic VPS in a few minutes over SSH using a single command. This includes SSH keys, Telegraf, Nginx with LetsEncrypt certs, and automatic OS upgrades. No Ansible needed :)
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.
I would recommend against heavy-handed plugins, it's the reason I burned out on nvim and fled to helix. The thing about a breaking change in a plugin (like, oh, I don't know nvim-treesitter - likely the most installed plugin) is that you find out when you are about to do work/be productive.
lazyvim is definitely the one I found easiest of a bunch of these. I've been using it for a while now, I haven't tried in neovide though, I just did and it ran but when I did an update there was a compilation error (on mac). So maybe avoid an update there? :) It was easy to fix in standard iterm2 though (just resync).
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.
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.