I wanted to give a proper reply to the technical part of the question, but I find the rant part too long, off putting and condescending. So I'm not going to tell you that GDB implements the Debug Adapter Protocol (DAP), and therefore can be used with any GUI DAP client like VSCodium.

A random one every month.

Unsafe code, at least in Rust, is given special treatment and care. Such code is usually 5% or less of the total codebase. Such unsafe blocks are also commonly reused fundamental designs. This leads to them being designed as libraries that are shared.

You can of course give C++ the same consideration. But then 100% of that code base will have to be given special care. And the reusability of unsafe code goes out the window.

People who argue that Rust (not sure about GC languages) is equivalent to C and C++ because of escape hatches like unsafe, completely neglect the localization of unsafe code and the benefits it brings.

So are Haskell and Idris (well, if you consider a singing dragon as a person).

Wow! You are so deluded, thinking of yourself as a cool new kid with cool new tech (Discord) fighting against old people. What you don't get is that people are protesting the use of Discord for something it's not suited to. There's no generation gap in it. The best of the youngest developers I know have the same opinion. Perhaps it's time for you to reflect on your own standing.

There are a lot of instances where that may not be practical. The maintainer may be indisposed or may be even passed away. Perhaps we shouldn't attach too much significance to the name. Instead, make projects more discoverable and get creative with the names.

Others have linked it, so just the summary here. Tauri is an alternative to Electron. But unlike electron, Tauri doesn't bundle the web engine (blink) and uses the platform's webview instead. Tauri and Servo teams are working together on integrating the latter as the engine.

Git is a lot of things at once:

1. A tool to record development history - warts and all
2. A tool to create a logical sequence of changes
3. A tool to communicate intent and ideas to a maintainer

Meaningless messages like minor and . don't suit any of these roles - not even 1. Even when recording development history with all mistakes, you'd still need context when you look back at the history. Matklad is a well respected developer. I wonder why he's make such a bizarre claim.

I wonder what sort of problems they had with C++ that prompted them to port such an old codebase to Rust.

Somebody did that on HN. They seemed receptive to it.

Most of the “automation” work that I do involves parsing data with regex, restructuring the data, converting the data into a modeled format and transforming something with that data.

These are the highlights of rust - regexes (the regex library that powers ripgrep), serialization/deserialization (serde, nom, pest, capnproto, etc), data manipulation (too many. perhaps apache arrow deserves a mention), etc. The language is designed for this sort of stuff.

Has anyone used Rust for network automation tools?

I'm in the same boat as you. I use python to manage an LXD cluster. I didn't choose Rust because Python has an API binding, but Rust didn't. It wouldn't have been too hard, considering that the API is mostly just JSON.

With familiarity, can Rust’s intuitiveness match Python’s “from idea to deployment” speed?

Unfortunately no! (in my personal experience). I have been using Rust for a decade (since before 1.0) and am more or less comfortable with it. I no longer fight with the compiler as most beginners do. Still, the compiler complains a lot and you have to think about why. This is not bad, IMO - all that thinking make you design better programs. There is always a sweet satisfaction of writing excellent code when you finish a Rust program - probably the reason why Rust developers love it so much. But you have to sacrifice some speed for that.

Intuitiveness is also subjective. My introduction to programming and computers was from the hardware side - from ALUs, DRAM, hardware pipelining etc. Rust's rules are very well defined, but is obscurely related to real problems you encounter in the hardware. In other words, Rust rules look confusing at first, but it makes sense once you see the error messages. You know what problem could have happened on the hardware if Rust didn't stop you. It's as if Rust's simple rules magically cover the problems you dread on the hardware.

All this means that Rust is easy to grasp for people who are already using C - OS, game engine, web engine and embedded system developers. For others who are mostly used to GC languages, it's an uphill battle with the compiler, until some day it clicks somehow. With Rust, it's very important to start right away with the (c lang) memory model and Rust's aliasing rules.

Or should I only learn Rust if I intend to create applications that need tight performance?

I wouldn't say no to learning a new language. But I always recommend a few languages because they introduce a radically different idea. Rust is one of them. My rant above probably gave you an idea why I would recommend Rust. The first is that Rust forces you to design programs properly - even though the rules are meant only to enforce memory safety. Second is that Rust gets you very close to the soul of the hardware. Python and even Go has some opaque layers in between you and the hardware. With Rust, you'll get every opportunity to get the best the hardware can offer. You get the same in C and C++ - but they also allow you to screw up.

I use Rust for even trivial tasks where a shell script would suffice. Besides the language features, Rust has excellent tooling and a rapidly growing library ecosystem. In many ways, it's easier to package Rust programs than Python ones. So Rust will work for your use case. But if development speed is more important to you than performance, then Go (similar to Python), Nim (much more similar to Python) and Zig are probably better choices. Repeating something here - Go is designed for the web. Numerous web backends are already on Go. And almost the entirety of Kubernetes is written in Go.

Stay off Tmux for a couple of months and try again. I've been through that exact scenario. It doesn't feel intimidating, but you still need to brush up.

One thing that zellij does correctly is discoverability. You don't need to even read their documentation to become productive.

Zellij is also reaching feature parity with tmux. But its development seems to be accelerating. Zellij might become the dominant multiplexer soon.