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.
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.
I do not really see that.
The article is short, and myself I like to write longer, more detailed texts. But few people nowadays have the patience to read ten, five, or three pages of text.
Also, I am becoming wary about the trolling / disinformation tactic to qualify something as AI that you do not like. If a piece of text is wrong, it will have logic failures that you can address and point to.
And said that, burn-out is a real problem, I can confirm that. Not only in FOSS software but in other fields of software development, too - but the article also cites real factors which make it worse for open source development. And it is not only a threath for the mental health of individuals, but also for the community.
And the aspect of entitlement of some users is true, too.
I swear by mulinux with Emacs as textual WM.
I know gimp, git, borg, and mutt, but not the others :)
That’s good point.
Another thing that is dangerous are CLAs or “contributor license agreements”, like Google uses. Technically, it is GPL, but Google might demand to hold all the copyright, so as the copyright holder it can change the license at a whim.
It works well for me.
Actually, I am a long-term Debian user (for 15 years) and use it in parallel with Arch, since about ten years, and I had less trouble with Arch: When upgrading from Debian 10 to 12, GNOME broke for me so that I could not log in any more. I spent a day or so to search for the cause - it is related to the user configuration but I could not figure out what it was and I had to time-box the effort, and switched to StumpWM (a tiling window manager, which I had been using before). I had no such problem with Arch, and on top of that I could just install GNOME’s PaperWM extension just to give it a try.
You could argue that my failure to upgrade was GNOME’s fault, not Debians, and in a way this is true. Especially, GNOME should not hide configuration in inscrutinable unreadable files, and of course it should parse for errors coming from backwards-compatible breaking changes.
But the thing is, for software making many small changes is very often much easier than a few big changes. For example because it is far easier to narrow down the source of a problem. So, it is likely that GNOME on Arch had the same problem between minor upgrades, and fixed it without much fuss.
But you also need to see that Arch is primarily a Desktop/end user system, while Debian is, for example, also a server system. Debian is designed for a far larger range of applications and purposes, and having many small breaking upgrades would likely not work well for these.
Oh, it’s not that bad. I use UK international with AltGr to type English, program code, and German. I don’t use the Compose key so often. Just for some extra symbols like Greek alpha or ° C.
I use “PrintScreen” for that …
I use it as the prefix key for my tiling window manager (stumpwm), and have mapped it to the “Super” X11 modifier for Emacs.
(Also, I have mapped CapsLock to the Hyper modifier, which I mostly use for user-defined commands. Not as powerful as the original space cadet keyboard, but not bad!).
BTW, one thing that is great about StumpWM is that you can define commands to script actions on GUI applications. For Example, if you are in a Firefox window, you can script Ctrl-t-B (or perhaps Hyper-B) to go to the adress bar, copy the URL, then call xsel to append the content of the buffer to a file which is called ~/bookmarks.txt, and finally open your preferred editor to add a comment.
Just an example: Of course you can use a private email service. You don’t need to give a copy of all your communications to Google Mail or outlook. Or medical data.
But what helps that, if 97% of the people you communicate with (including your doctor) use outlook or gmail, and all messages you write them are kindly stored there “for them”?
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.