

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:
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++:
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.
Just a questions, are such thermal printers useful for home users? I find them quite interesting since they are fast. They could make sense if one just wants to print a tiny snippet of information like a shopping list, a street adress, or a password, and one does not want to fire up a laser printer and print a whole A4 page.
(Thinking about that, passwords are an interesting use case… often a paper copy makes sense and the copy needs to match exactly.)


I guess that still depends on the maintainer which is responsible. But since drivers often deal with untrusted data, which can lead to security exploits, this makes a lot of sense.


Great news! So, we can expect that European industrial companies will start to pick up Rust around 2035 and it will become kinda mainstream around 2045… shortly after the heat death of the universe Southern France. ;-)


Related: Robotics pioneer Rodney Brooks saw this coming: https://arstechnica.com/ai/2025/10/why-irobots-founder-wont-go-within-10-feet-of-todays-walking-robots/
I think this is a well-written and important article.
One more aspect: The article lines out that todays control algirithms for robots are not inherently stable and can’t guarantee safety.
I have seen some code that runs in some if such humanoid robots and would like to add the following warning: the control code for robots is typically written by researchers, not safety experts. While there might be some brilliant programmers among them, such code will be, in most of the cases, a hot mess which cannot guarantee any safety. It will certainly not meet requirements which are commonly mandated for things like complex medical devices, automobiles, or other dangerous work equipment - but due to the much larger complexity and dangerous mechanical forces in such robots, the requirements should be higher than in automobiles.


Well, what the world really needs are laptops with built-in HVAC support!


Would you go near an uncontrollable maniac swinging a ten-pound sledgehammer, or stand two meters below a larger-than life bronce sculpture of Neptun with a harpoon, weighting 150 kilograms, which is not fixed, unstable and could at any moment fall upon you?
No? Then you should not go near such a robot.


I use Zim Wiki + git. Or gollum wiki, which also uses git. Works both very well and can not only be synced but automatically merged.


Especially that diabolic number “zero”. It is a pure Arab invention. The Romans did fine without it. Then the Arabs introduced zero and we know what happened with the Roman Empire. Now, zeros can be found everywhere - they can even hide in computers. America should really exzerminate these zeros befote it is too late!!


The funny thing is that not C or Rust as languages “close to the hardware” have more specific bitwise operations - but Common Lisp has:
https://www.lispworks.com/documentation/HyperSpec/Body/f_logand.htm
https://www.lispworks.com/documentation/HyperSpec/Body/f_logcou.htm
https://www.lispworks.com/documentation/HyperSpec/Body/f_boole.htm#boole
(Though Rust has at least popcnt() and count_ones(), which are immensely useful e.g. when processing small sets.)
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.