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?

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.

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?

[1] https://docs.docker.com/engine/security/#linux-kernel-capabi...

https://ollama.com/

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

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.

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

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.

[1] https://edolstra.github.io/pubs/phd-thesis.pdf

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.

[1] https://www.lunarvim.org/

[2] https://nvchad.com/

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.

I also recommend a video by Yannic Kilcher [2], explaining the paper.

[1] https://arxiv.org/abs/2310.06816

[2] https://www.youtube.com/watch?v=FY5j3P9tCeA

1: https://100r.co/site/pino.html