Oh! I misunderstood. Sorry! Glad to meet a fellow Gentoo here!

I use Gentoo with OpenRC. So my position in this matter should be clear. Anyway, check the last paragraph again to see what I think about systemd's modularity.

Mir is not a good example of distro engineering, because it's an extreme case of NIH syndrome. Unlike what it is today, the original Mir was an alternative to Wayland.

The story started when Canonical decided that X isn't good enough and they needed an alternative. They chose Wayland first, exciting the entire Linux desktop community. But then they dropped Wayland in favor of the new in-house Mir project, citing several drawbacks to Wayland. The Wayland community responded with several articles explaining why Canonicals concerns were unwarranted. But in typical Canonical style, they simply neglected all the replies and stuck with Mir.

This irked the entire Linux community who promised to promote Wayland and not support Mir at all. This continued for a while until Canonical realized their mistake late, like always. Then they repurposed Mir as a Wayland compositor.

Now this is a repeating story. You see this with Flatpak vs Snap, Incus vs LXD, etc. The amount of high handedness we see from Canonical is incredible.

Nobody knows about unifiedpush. Last time I checked, their Linux dbus distributor also wasn't ready. There has to be a unified push to get it adopted.

They aren't talking about using recursion instead of loops. They are talking about the map method for iterators. For each element yielded by the iterator, map applies a specified function/closure and collects the results in a new iterator (usually a list). This is a functional programming pattern that's common in many languages including Python and Rust.

This pattern has no risk of stack overflow since each invocation of the function is completed before the next invocation. The construct does expand to some sort of loop during execution. The only possible overhead is a single function call within the loop (whereas you could have written it as the loop body). However, that won't be a problem if the compiler can inline the function.

The fact that this is functional programming creates additional avenues to optimize the program. For example, a chain of maps (or other iterator adaptors) can be intelligently combined into a single loop. In practice, this pattern is as fast as hand written loops.

I wonder if these trillion dollar companies offer support contracts for astroturfing on social media on their behalf. I can't think of any other way so many people are supporting their sociopathic attitude.

Interesting that they started dictating what you can and can't do with YOUR program! Consumer rights are a joke to these quasi-monopolies.

CUDA is an API to run high performance compute code on Nvidia GPUs. CUDA is proprietary. So CUDA programs run only on Nvidia GPUs. Open alternatives like vulkan compute and opencl aren't as popular as CUDA.

Translation layers are interface software that allow CUDA programs to run on non-Nvidia GPUs. But creating such layers require a bit of reverse engineering of CUDA programs. But they are prohibiting this now. They want to ensure that all the CUDA programs in the world are limited to using Nvidia GPUs alone - classic vendor lock-in by using EULA.

they don’t feel like your fighting the language

I really understand what you mean wrt Rust. I really do - I was there once. But it's a phase you grow out of. Not just that - the parts you fight now will eventually become your ally.

and let me feel sort of creative in the way I do things

I had the same experience with C/C++. But as the design grows, you start hitting memory-safety bugs that are difficult to avoid while coding - even after you learn how those bugs arise in the first place. Just a lapse of concentration is enough to introduce such a bug (leaks, use-after-free, deadlocks, races, etc). I've heard that C++ got a bit better after the introduction of smart pointers and other safety features. But, it comes nowhere near the peace of mind you get with garbage collected languages.

That's where Rust's borrow checker and other safety measures kick in. The friction disappears when you acquire system knowledge - concepts of stack, heap, data segment, aliasing, ownership, mutation, etc. These knowledge are essential for C/C++ too. But the difference here is that Rust will actually tell you if you made a mistake. You don't get that with C/C++. The ultimate result is that when a Rust program compiles successfully, it almost always works as you expect it to (barring logical errors). You spend significantly less time debugging or worrying about your program misbehaving at runtime.

The 'friction' in Rust also helps in another way. Sometimes, you genuinely need to find a way out when the compiler complains. That happens when the language is too restrictive and incapable of doing what you need. You use things like unsafe, Rc and Refcell for that. However, most of the time, you can work around the problem that the compiler is indicating. In my experience, such 'workarounds' are actually redesigns or refactors that improve the structure of your code. I find myself designing the code best when I'm using Rust.

Why no Ada or Janet? Or Haskell or Idris?

All the problems mentioned here are common to various tech jobs and possibly other fields as well. It's nothing specific to programming. All problems mentioned are societal issues and not inherent problems of any profession. Things like student loans, hustle culture that leads to burnout, over compartmentalization of work, clueless managers, etc. We need a social revolution, not a career change.

If any FOSS project maintainers see this, please stop using Discord for your community.