That's hard to recollect off hand. But one thing I find easier with Arch (and Gentoo, which is my daily distro) is to create complex partitioning schemes (e.g encrypted swap and btrfs subvolume mounts) and boot loader configurations.
Another example is a window manager with a somewhat complex display manager setup and a ton of supporting services.
PS: I don't consider Arch to be the silver bullet. For example, I always prefer Debian for servers.
For anyone looking to learn git, the official book and site are thorough and exceptional. You can even download the eBook for free. While there's no harm in using other sources to learn git, don't use them as an alternative to the canonical source.
That works only if memory safety is optional. Additions of the language features needed for mandatory memory safety are backwards incompatible.
Git owes a lot of its popularity to github. Without it, there's a good chance that mercurial would have taken over. In addition, the centralized workflow was what made both git and github popular. It simplified git usage enough to let a lot of novices get started.
I'm in no way a fan of centralization that github represents. But I think a decentralized workflow using git was a lost opportunity. People complain a lot about the git-email workflow. But I see no reason why it couldn't have become as easy as using github if the effort spent on github was spent on git-email tools and user experience.
I always say this - you're underestimating the size of the Apple fanboi crowd. They're ready to defend any crap Apple pulls on them.
Do you know how crappy the discord client is? Even element with all its flaws behaves better.
Anything else that can:
Discourse is a great choice - it meets both criteria. Even phpbb meets the requirements.
Even Zulip is objectively better than Discord. It meets point 1 very well. I don't know how well it does in point 2.
There is one possible explanation for that conundrum. There are two types of people who are looking for solutions:
Those who want quick answers. They don't want to do the research - to see if the problem has been addressed before. They don't care about if the question has been asked before.
Those who prefer searching for solutions. They don't like joining any community just to search for those solutions.
Group 2 is going to be very invisible to you (maintainers), because they ask questions only if they can't solve the problem themselves and nobody has asked it before. (I know this because that's me). This group isn't a minority.
Group 1 is the vocal type that you are more likely to interact with, since their first instinct is to ask. If you provide them a choice between forums and chat rooms, they always choose chats because that's where they can get away with providing minimal background information on their questions and doing minimal to no research.
This doesn't mean that the majority of your users are happy with chatrooms. It's just that your observations are going to show this survivorship bias.
Why would they need another edition if Polonius covers all the cases from the current borrow checker?
You're right - though I don't know about the 'control memory' part. However, the other person is addressing the use-case of 'network automation', not of microcontrollers. There it really doesn't matter what the exact memory layout is, or if GC stops your job for a microsecond. Go is sufficient for that. Go is sufficient even for many web backends and network infrastructure. In fact, much of kubernetes is written in Go.
I use Rust for where one would normally use a shell script. But I have been using it for nearly a decade now (yes, I started before it reached 1.0). I have gotten used to the strict type system and even rely on it to write proper code. I also have a background in hardware - so much of it makes sense to me. Even so, I can't recommend Rust to a beginner who values productivity. Rust takes a lot of time getting used to. And no matter how you try, you will never be as fast as you are with python or go. It's not always bad considering what you get in return for the sacrifice. But it's better to set your expectations straight.
Sadly, it also suffers the same problems Nim suffers: dearth of libraries.
That might change once the language stabilizes. Imagine creating a library now and the language changes breaking it.
The problem is that all of those interdependent parts and software that are dependent on it become entrenched. There is no freedom to replace individual parts with an alternative because something else will break. That's what I call 'Modular in theory, monolithic in practice'.