[jjav]

Very concisely and correctly put, agreed.

I sometimes work on the infosec side of the house. It's easy to point at vulnerabilities due to endless memory access problems in C code and fixate on that. And it's true, so it feels satisfying.

Just rewrite everything in not-C and this is fixed! And that's true as well. But remeber here the word "this" refers to the memory access bugs. It doesn't refer to vulnerabilities in that sentence.

Plenty of systems without a single line of C/C++ code and we have no shortage of ways to break in anyway. So in one sense, everything changed. But wearing the black hat, nothing really changed since I compromised the system anyway. A new language without all the engineering process parent post describes, won't magically get there.

For an existing system "just rewrite everything" will guarantee way more bugs for years to come simply because the old system has been battle-tested and reinforced for years. In the long haul the rewrite will converge to a better state but that haul is long (and assumes budget will remain in place long enough, which might not happen so you end up with a half-baked rewrite).

For new systems starting from scratch that may in any way ever be run in a security relevant context, sure, starting with not-C is a good idea today.

Unfortunately Rust seems to be the only alternative for use cases where C was actually needed (if it could be written in Java or Go or Python or ... then it didn't really need to be in C in the first place). And sadly rust is fairly user-hostile language so my guess is plenty of new projects will start with C for a long time due to lack of friendly alternatives. And tooling.

[MereInterest]

> And sadly rust is fairly user-hostile language

Could you elaborate on that? I started using Rust at the end of last year, and have found it to be one of the most user-friendly languages I've learned. There is clear documentation that is easy to generate with the standard toolchain, along with a very good language guide.

The compiler error messages are an absolute joy as somebody coming from C++. Pointing out exactly where the borrow checker found errors, or exactly what the type signature should be for a trait, is really useful.

[rob74]

Well, yes, coming from C++, Rust must seem like a breath of fresh air. Coming from almost any other language however, I can understand that it feels a little bit intimidating (and getting more so with every exotic feature added - "const generics" anyone?), no matter how friendly they try to make the documentation and the error messages...

[MereInterest]

I can see that a bit. I suppose for me, the biggest questions are (1) is there a way to unambiguously express my intent and (2) is there exactly one way to do so? I'm fine with more features so long as they match some specific problem that people have that isn't already solved in another way.

For example, in the case of const generics, I've used the equivalent in C++ to make a class for a geometric vector in N dimensions. The size varies depending on the number of elements, but is known and can be checked at compile time. The existence of const generics is very closely matched to this particular use case.

[dllthomas]

I don't think "there is exactly one way to do it" is actually a good guiding principle.

Forcing it down to an overly simplistic setting, if I need to add 5 to a number I can increment 5 times, or add 2 and then 3, or just add 5. Which of those options should we remove?

Perhaps we mean, instead, that there should be one best way, but (sliding into metaphor, I hope) what about when we have a language without 5 and we are considering adding it? Is the use case already handled by 2+3? How are we to decide?

[Ar-Curunir]

This is just false, Rust is much easier to use than Python (just the package management situation is so much better)

[fractalb]

Really? Then there is no point in starting new projects in Python. You can write everything in Rust. You’ll get performance as a bonus.

[rowanG077]

No python has way more packages like the op said. You can't start projects in rust where you need a significant amount of dependencies because rust is not there yet.

Language wise rust is better the python in every way except for compile times.

[MereInterest]

I imagine that in addition to having more packages, it is easier to hire developers who know Python than who know Rust. Current tiobe index puts Python at #3 (rating=10.86%) and Rust at #30 (rating=0.49%). If you already have a team experienced in Rust, then it may be a good choice, but if you are expecting to grow your team, you may want to pick a language based on popularity.

Language-wise, it feels like they are intended to solve different problems, so Python vs Rust is a weird comparison. Granted, that may because I started learning Rust as a replacement for C++, so that has been my point of comparison.

[dragonwriter]

> And sadly rust is fairly user-hostile language

Rust seems to me to be user-frienndly, though for the cases where it's safety features are critical and at the fore, it front-loads pain that would be dealt with eventually, which can make it feel intimidating. But its forcing you to confront things that are likely to cause subtle bugs if dealt with sloppy (or overlooked), not actually adding unnecessary complexity.

[bfrog]

User hostile? I've found it to be the exact opposite of you consider the user is me, the developer. If anything the language and tooling has gone to lengths to be user friendly.