At work:

• geometric computations in a Performance-sensitive optimization algorithm that was drafted in Python. After confirmation, the whole algorithm was rewritten to C++, which was fine since it was part of a large science experiment
• rewriting / wrapping some middleware + APIs so that other people can transition new work to rust. The resulting interfaces turned out very pleasant to use!

At home:

• building command-line software for my Gemini PDA. This is an ARM device and Rust is far easier to cross-compile than C++.
• Implementing a larger optimization & solver algorithm (a few thousand lines) which I coded some time ago in Clojure. Very easy to parallize.

So, here are the key features and decisions of Guix:

1. Guix is a package manager that can (optionally) run on top of Linux distributions or other POSIX systems, like cargo, pip, conda or conan. In difference to the pip and cargo it is language-agnostic, supports many different build systems and languages, and features around 29000 packages now.
2. Guix allows to define a fully reoroducible system. This works by using a declarative language for immutable versiond package descriptions, and by deriving any software from package definitions and a fixed version of the source code. In that, it is similar but much stricter than Nix and NixOS. The key point is that any software built, and all its dependencies, go back to unambigously, immutable versions of source code - and all inputs to the system are open source and can be reviewed.
3. This allows it, and also makes it technically possible, that any software package can be re-built and run years later. To make this legally possible, the official distribution of Guix also demands all components to be open source (FOSS). This is also a key difference to NixOS and non-free variants of Guix, which allow non-free binary packages, but sacrifice reproducibility. (To illustrate: If you have a binary, proprietary scanner driver in NixOS, and the owning company practices planned obselescence and decides that you should buy their new hardware, and pulls that driver, you are out of luck. In Guix, this can’t happen.) (Note that as your own private conponents, you can define any package you like, you can also distribute your definitions. Non-free packages for Guix do exist, in the same way as you can buy and run Game software for Linux. Such nin-free software just can’t become part of the official Guix distribution, just like Amazon or Apple can’t sell their non-free software via Debian or the Linux kernel project).
4. All inputs being open source also means that any software component can be reviewed, that mis-features such as privacy-invasive behaviour can be removed, and that it is hardly possible to hide malware in the system. Because this also applies recursively to all compilers and build tools, this solves also Thompson’s “Trusting Trust” problem. In fact, the whole system can be build from a 512 byte binary root (called MER). (Interestingly, that level of user control gets a lot of hate online – certain companies don’t seem to like it).
5. Because it would take too long to build every user package from source every time, the produced packages are normally cached (while their correct binary content can be easily verified).
6. The declarative description language for the packages is a well-defined, established, minimalist language called Scheme. This is a member of the Lisp family of languages. That Lisp is very well suited for declaratively building and configuring large systems has been proven with GNU Emacs, whose software is written in Emacs Lisp.
7. The Scheme implementation used is called Guile. It has especially good support for the POSIX environment and has also much better-than-average interactive debugging capabilities compared to other Scheme implementations.
8. Also worth noting is that the Guix project has superb online documentation.

I don’t have time for a full reply now, but I leave you this link till tomorrow:

https://en.wikipedia.org/wiki/GNU_Guix

Feel free to ask more!

Ah, interesting! I was thinking that helix (which I have not tried) differs mainly by being a bit less modular, less minimalist, and much more “integrated” with things like LSPs. And, isn’t helix preparing an extension language which is a Scheme - one surely could says that Lisp as extension language is a key feature of Emacs? Could you elaborate a bit more?

Oh, and in case you are on Debian and quickly want to try a recent version (as both vis and kakoune are in ongoing development): They are available under the Guix package manager. Just

guix install vis
guix install kakoune

Real programmers use ed!

Varies a bit with job, but by far the most in the last 15 years:

Linux (Debian), Emacs, tiling window manager (i3/sway/stumpwm), also gollum wiki + org-mode for writing docs. For small quick edits, I use vim.

I use Arch in a VM, or (preferred) Guix package manager for tools that require newer versions of software.

On the job, I write mostly C++/Python/Go/Rust, at home more Rust, Python, and the Lisps.

Work (frequently some kind of embedded) uses also e.g. Ubuntu, OpenSuSE Leap, Gnome, eclipse, and so on.

Is there an equivalent for the software industry to indicate one wants to distance themself from a commit or a project they don’t approve?

Other strategies might be better suited. For example, say you work on automobile steering software and management is cutting so much corners that things become unsafe. In that case, it might be best to write a mail to the legal department and naively ask some questions about safety and technical concerns. Then print it and take it home.

In general, if you can’t ethically agree to a commit in open source software, it should be possible to withdraw that contribution.

There might be other cases where autorship or contribution to some software might expose you to discrimination. In that case, I think it is perfectly ok to work anonymously.

I think airlines do this since a while.

Done!

Everyone has an attention-hungry tamagotchi. They moan when they want more electricity, and giggle when you connect them to a charger.

They sigh when you switch them off.

They make you feel uncomfortable when you leave home without them.

They want you to constantly feed them with information.

They are called smartphones now.

I would doubt that the average self-updating Windows program has better security.

I like Python for quick and dirty stuff

There is one more little secret that not everyone knows:

You do not need lifetime annotations and full borrow checking if you do not care to press out the last drop of performance out of the CPU, or if you just draft experimental code.

In fact, you can very much program in a style that is similar to python:

• just pass function arguments as references, or make a copy (if you need to modify them)
• just return copies of values you want to return.

This makes your code less efficient, yes. But, it avoids to deal with the borrow checker before you really need it, because the copied values get an own life time. It will still be much faster than Python.

This approach would not work for heavily concurrent, multi-threaded code. But not everyone needs Rust for that. There are other quality-of-life factors which make Rust interesting to use.

… and of course it can’t beat Python for ease of use. But it is in a good place between Python and C++. A bit more difficult than Java, yes. But when you need to call into such code from Python, it is far easier than Java.

For software developers, it is better to have frequent tiny changes that can break things, than a big mess of breakage.

Do you hate distractions? Do you love steady improvements? This will affect your preference and judgement about rolling release.

The same can be true for desktop users. It also depends on how stable your software is. If you use mainly vim, dwm, and LaTeX, very few changes will break your flow.

EDIT: also, there are very few languages less productive and beginner-friendly than C++ in my opinion.

I am a professional C++ developer with 20 years of experience and have worked in about eight other languages professionally, while learning and using a dozen more in hobby projects.

I agree with you here. The only areas where specifics are worse are package management in Python, and maintainability of large SIMULINK models.

The function composition style comes from functional programming and Rust’s OCaml heritage. It can make it easier to reason about invriants and possible sets of values of the result of a computation step.

Rust transforms these to the same or a close equivalent of hand-written loops.

Similar methods are used in specialized, high-performance C++ libraries such as blitz++ and Eigen. But if you mess up bounds, you will get UB with them.

The one thing I really did not enjoy, subjectively, with Rust, is that writing “C-style loops” comes with a performance penalty because there are bound checks happening, so the idiomatic version of a loop in Rust usually involves iterators and function composition.

IIRC you can speed up such checks by putting an assertion in front that checks for the largest index - this will make repeated checks for smaller indices unnecessary. Also, bound checks are often not even visible on modern CPUs because speculative execution, branch prediction, and out-of-order execution. The CPU just assumes that the checks will succeed, and works on the next step.

Generally no. As soon as a class hierarchy becomes moderately complex, implementation inheritance makes code very hard to maintain, because you need to read the whole stack of classes to see what a single change will actually do.

Rust has another system, traits and trait implementations.

Enjoy! I don’t know what you used to seriously program on but I am willing to bet that the ownership paradigm that it enforces is going to feel at least moderately new to you, unless you forced yourself to code that way anyways.

Thinking about ownership is the right way e.g. for C++ as well, so if one has coded professionally in larger systems, it should not be too alien.

One still needs to learn life time annotations. So, assuming that you know, for example, C++, it is an a bit larger hurdle than picking up Java or Go, but it is worth the time.

In many aspects, Rust is far more productive and also more beginner-friendly than C++:

• far better compiler error messages
• a superb and easy-to-use packaging system
• Unicode support
• support for unit testing right in the language
• strong support for a side-effect-free or “functional programming” style which is great for testing and tasks like data analysis or parsing
• better modularization
• avoids implementation inheritance, and the trait system is a bit different but superb
• no undefined behavior (in safe Rust) which means nothing less than that the code does what it says - and this is extremely useful in larger projects
• great support for safe concurrency
• the language and library frees one to think about interfaces and algorithms which is where the big wins for performance are hidden (and IMO one of the key factors for the astounding success of Python).

I could go on… but I need to do other stuff

A nice editor for both Markdown and reStructuredText with minimal dependencies, which allows to change seamlessly editing between rendered text and source text. Like one has a tab for source text, and one for rendered text, and can change and edit both tabs.

Gollum wiki has something similar but it could be better. Maybe even having two panes side-by-side, left source, right rendering, and one can edit both and / or flip them.

Also, I think one could find a ton of small useful improvements in Zim Wiki. I use it all the time to gather and structure information on poorly documented stuff, which is very often needed when working with legacy software, and it is great and extremely useful but not perfect.