> This is ironic since these two crowds are mostly solving the same type of problems. It's just democrats vs republicans type of split, some of it is just for show and philosophical.

This is a painfully shallow framing.

Yes, programming languages solve problems by emitting instructions that a programmable logic chip can use to preform calculations on input resulting in output. And the scaffolding you use to get there isn't just a matter of philosophical show. Rust as a first order decision will refuse to emit perfectly valid programs because it's unable to prove it's correctness. Zig will emit any program it has enough information to do so. People coding in rust off load much of the effort in understanding and proving that correctness to the compiler. In Zig that relationship is reversed, where the compiler offloads that responsibility to the programmer.

The person you responded to is correct. For some people. Rust solves the difficult and annoying problems, for others it creates difficult and annoying problems.

Some people like creating art, some people like creating software. I guess you could frame that as philosophical, but to call it a political show, belies ignorance to the interactions between systems and predispositions of individuals.

Rust is solving the memory safety problem, Zig is solving the 'idiomatic interop with existing C coding patterns' problem. These couldn't be more different - C-like idiomatic code is generally antithetical to 'safe' modularity since it often relies on tacit global invariants for correct behavior.

Interestingly, Carbon is kinda trying to tackle both at the same time (though starting from C++ in their case) which is a bit of a challenge.

No, it's not just a cultural thing. There are very real problems with standard Rust facilities not being accessible/usable from an unsafe context even though the C/C++/Zig idiomatic equivalent would be (i.e. would not invoke instant UB), and these problems are solvable. Sophisticated Rust developers are aware of the issue.

> If anything, the Rust language would benefit from adding as much friction to unsafe code as possible

The friction is there already. I'm not advocating for getting rid of explicit 'unsafe' markings, 'SAFETY' comments or even clunky boilerplate, just for closing a very real gap in capability.

Very much so once you compare it to how quickly C++ (and, in fact, any language that's ever been in the top 5 or so) achieved similar milestones. Rust's adoption is very impressive when you compare it to, say, Haskell or Clojure, but not when you compare it to languages that achieved significant and long-lasting popularity. It's roughly similar to Ada's adoption when it was of a similar age (Ada was more prevalent then than Rust is now in some areas and less so in others). When work on Rust started twenty years ago, Java was younger than Rust is now. It was almost as close in time to the early work on C++ as we are now to the early work on Rust. Larger portions of operating systems were being written in C++ when it was younger than Rust is now.

There's no denying Rust's popularity in open-source CLI dev tools for Python and JS/TS, but when you talk to C/C++ shops who've evaluated Rust and see how many of them end up using it (and to what extent) you see it's not like it's been with languages that ended up achieving real popularity (which includes not only super-popular languages like C, C++, and Java, but also mid-popular languages like Go).

I like that I can easily smell bad Zig by looking at it, but I'm notoriously bad at smelling bad C.

Using the same language for compile-time and run-time programming is compelling, but doing it properly requires using the same approaches that dependently typed languages use. Comptime is a bit half baked.