Here's my 2¢. Debian is a reasonable OS to develop on, since it provides a super stable and reasonably secure base platform. I've used it quite extensively for the same purpose without any issues whatsoever.

However, it won't satisfy the needs of the modern style of development. For that, you need a reproducible development environment so that every developer gets the same results. (That means avoiding the 'it works for me' type of bugs). That means you need the same version of runtimes (python), same version of libraries/dependencies and same developer tools on every development system, irrespective of the distro it's running on.

The problem with Debian is that it often ships older versions of software to keep it stable. It will likely not match the version of python and tools you need. For that matter, no distributions including the frequently updated Arch Linux are likely to meet those requirements. (There are exceptions - NixOS and Guix.) So the widely adopted solution is to create a dev environment independent of your core system, from your regular non-root account. That means separately installing a python runtime that's different from your distro repo, etc. They don't touch your core system and keep it clean and pristine.

The way we achieve this is by using 4 tools:

1. Runtime version manager: Manages the version of runtimes.

• Eg: python: pyenv, node: nvm, rust toolchains: rustup

2. Environment manager: Creates and maintains isolated environments where the correct runtimes, project dependencies and tools are available.

• Eg: python: venv, node: node project, rust: rust project

3. Dependency manager: Resolves and installs the correct version of all project dependencies into the environment.

• Eg: python: pip, node: npm, pnpm, rust: cargo add

4. Tool manager: Installs additional development tools for the project, like formatter, linter, etc.

• Eg: python: pip, pipx, node: npx, rust: cargo install

Often, many of these are combined and you may get less than 4 different tools. The current situation is extremely complicated and there are many different tool combinations you can use. So let's address your specific requirements.

If your project uses only Python

In this case, the choice is pretty straightforward. Use uv.

The package management situation in the Python ecosystem was an absolute mess until UV appeared on the scene. UV combines all the 4 functions I mentioned above. It replaces venv, pyenv, pip and pipx in a single fast binary. You'll be surprised by its speed if you're used to the speed of pip. It's easy to use and very well integrated. It also integrates additional functionalities like:

• Formatter (replaces black)
• Project setup (helps with poetry, flit, hatch, etc)
• Project publishing (replaces twine)

If you will use more than Python

If you will use tools or languages other than Python in a single project or in other future projects, you might want to use a 'language-agnostic runtime and tool manager'. They can manage runtimes and tools of multiple languages. Dependencies have to be managed using language package managers (like UV, pip, cargo, npm, etc).

The most well known tool manager is asdf. Others include aqua, vfox, etc. But the upcoming star is mise. I use mise for multiple projects including for Python projects. Mise uses UV behind the scenes for Python. So, mise projects play well with UV projects and with others who use UV.

The only disadvantage with multitool managers like asdf and mise is that they tend to be more complex compared to single language tools like UV. They obviously handle more and provide more features. However, investing time in tools like mise pays in the long run when you're handling multiple languages.

Servers like databases

The tools I mentioned above don't handle daemons like postgresql, redis, etc. This is why your colleagues recommend VMs. I will talk about VMs in a while. But I want to show you some simpler solutions here.

Another commenter has already mentioned the use of docker-compose files to set up such servers. It's the easiest solution possible.

Another more refined solution specifically for development containers is testcontainers. It's essentially the same as the docker compose solution, but with more dials and switches to help with automated tests like unit tests during CI. You'll have to learn a bit more than docker compose, to use it. However, those test servers are also readily available online and require little configuration.

Do you need virtualbox?

The methods explained above don't ruin your base Debian install. So a dedicated VM is not really required. However, I'm leaving this information here for completeness.

Use of VMs was widespread in the past. But they didn't run virtualbox, VMware or Qemu directly. Instead, a CLI frontend tool was used to set up those VMs for development. The most common tool was Hashicorp's Vagrant. Another tool available today is Lima. These tools mount your project directory into the VM, set up its network, install required tools, start required services (like DBs), attach a shell for you to work on, etc. These VMs are complete development environments and you don't need to do anything on the host system other than starting them up.

Since the advent of containers, the same idea has been implemented using containers instead of VMs. These are obviously less resource intensive than VMs. Most of them follow the devcontainers standard. So a devcontainer configuration works on multiple platforms, including GitHub's famous codespaces. Local tools for it include devpod, ona, devbox and devenv.

Conclusion

There are a lot more solutions. But these are the ones you're most likely to settle on. So I leave it at that. Please let me know if you have any questions about this reply. Hope you find your favorite setup soon.

Python decided to use a single convention (semantic whitespace) instead of two separate ones for machine decodeable scoping and manual/visual scoping. That's part of Python's design principle. The program should behave exactly like what people expect it to (without strenuous reasoning exercises).

But some people treat it as the original sin. Not surprised though. I've seen developers and engineers nurture weird irrational hatred towards all sorts of conventions. It's like a phobia.

Similar views about yaml. It may not be the most elegant - it had to be the superset of JSON, after all. But Yaml is a semi-configuration language while JSON is a pure serialization language. Try writing a kubernetes manifest or a compose file in pure JSON without whitespace alignment or comments (which pure JSON doesn't support anyway). Let's see how pleasant you find it.

You can uninstall the sudo application and add sudo as an alias for run0 in your shell initialization script. That's better than them renaming run0 to sudo, because that will prevent people from running the real sudo if they want it.

Commonmark leaves some stuff like tables unspecified. That creates the need for another layer like GFM or mistletoe. Standardization is not a strong point for markdown.

The entire purpose of Microsoft standardizing OOXML and implementing it wrongly in Office was to make other office suites irrelevant. ODF was already standardized and countries would have adopted it if MS didn't do the same with OOXML. They stuffed the ISO with members supporting them to do it.

And now that OOXML is a viable standard, they implement it wrongly so that other office suites can't be compatible with MS Office without a lot of extra effort. Any incompatibilities with MS Office will be considered as the fault of other office suites by the general public and government officials.

Expecting MS to do what's right for the customers is putting too much faith in their nonexistent sense of ethics.

Those same companies tell you that their products that you paid for don't belong to you. You are just buying a license to use them. Sadly, this asinine concept is spreading even to hardware markets.

I think it's fair to ask them to take their own bitter pill. They should also invest without owning.

Have you really used Rust or are you spreading FUD? I have not managed to cause even a single segfault in my 8 years of writing Rust code. Nor have I heard anyone else complaining about it, other than deliberately as proof of concept.

That's misinformation. There's no overestimation. The problem is so bad that even the US government advocates the use of memory safe languages (including GC languages).

I have used C and C++. You need laser sharp focus to avoid memory safety errors even after you learn what causes them and how to avoid them. It's significantly easier to write programs in Rust because any lapse in care to avoid memory safety bugs are caught by the compiler.

More like a personal bias in the form of a distasteful snark that the author thinks is funny. Their demonstrated knowledge about Emacs in the article indicates the worth of such remarks.

Torvalds really worked on his attitude and it shows. It's pretty evident from his interviews that he doesn't want the attention due to brash behavior. Even this news article is hyperbolic. He is just trying to get a point across. He's pretty much self restrained otherwise.

They replaced all CPP code from the shell. But the rewrite isn't complete yet.

I don't think you mean 'merge' - that's a specific operation. I think you mean 'squash', which combines multiple commits into one. 'Fixup' is also something similar.

Git allows you to edit history in any way you like. The hardest is probably splitting a commit into multiple smaller ones. It requires you to edit a commit by resetting the HEAD and making multiple smaller commits before continuing with the rebase. Though it sounds complicated, it becomes easy enough after you try it a couple of times. You should check out git-rebase.io - a site dedicated to editing git history. You can learn to craft proper commits of high quality.

Once you get familiar with rebasing, you could try out stacked git. Interactive rebasing looks weak in comparison to what stgit can do. Stgit allows you to edit history like rebase. But that's the least of it. It allows you to create proper commits from the start, rather than by editing at the end. In some ways, stgit gives you multiple staging areas - giving you incredible flexibility.