> C has a spec. No spec means there’s nothing keeping rustc honest.
Agreed, language specification is critical. The language reference [1] is very detailed, though. I'm not sure what it would take to promote this to a "specification."
> That really cool feature $other_language has? Not interested. It’ll be more trouble than it’s worth
Binding to "editions" is a reasonable way to get stability, IMO. It's a shame that this wasn't adopted earlier.
> Concurrency is generally a bad thing.
So don't leverage it. Don't use fork() or clone() either and we'll all agree to ignore this point.
> Safety. Yes, Rust is more safe. I don’t really care. In light of all of these problems, I’ll take my segfaults and buffer overflows.
Here underlies the crux, you should have led with this. This is a sizable portion of rust's value proposition. If you don't value it then it's likely not to measure up well.
> Rust will eventually fail to the “jack of all trades, master of none” problem that C++ has.
We have to take the good with the bad in everything, right? If Rust's future is "spectacular failure like C++" then it's probably going to be a wild success.
> > C has a spec. No spec means there’s nothing keeping rustc honest.
>Agreed, language specification is critical. The language reference [1] is very detailed, though. I'm not sure what it would take to promote this to a "specification."
But even the C specifications is mostly informal, there are some parts of C that has formal specification but to my knowledge not everything is. Where as something like SML has a full formal specification. Which mean that you do not have any undefined behaviour.
Correct, both of which you have to take into account when picking a programming language today.
>We have to take the good with the bad in everything, right? If Rust's future is "spectacular failure like C++" then it's probably going to be a wild success.
I wouldn't call C++ a wild success. It's failed to supplant C for its entire life, and thrives only in a few niches.
> Correct, both of which you have to take into account when picking a programming language today.
Shrug, you're not really wrong. Early adopters of Rust will suffer (have suffered) some issues. Maybe you can try it out in 2060, when Rust will be around the age C is now. To Rust's credit, for this metric it's around ten years further along than any other language that we could propose to supersede C today.
> I wouldn't call C++ a wild success. It's failed to supplant C for its entire life, and thrives only in a few niches.
I disagree, but I'll admit my bias here having spent very nearly all of my career working on C++.
i disagree with the main article, but he is right. C++ was supposed to be more than just browsers, GUI and video games: it shuold have been a better C. It failed. It was supposed to be more secure than C. It failed.
Mostly the OOP failed part, because it wasn't that good of an idea (usefull in some case, to do geometry and grapic stuff, and for other, specific cases). And Java's "everything is an object" did not help C++, with countless students trained on Java then writing software with C++ and doing awfull things everywhere. C++15 is really fun to work with in new, clean projects, with either new or very ancient C++ devs, but i would get away from any proposition including a pre-2013 C++ codebase and any "rockstar"/"genius" C++ dev with 2-10 years of C++ experience as a lead.
And by the way, nowadays python and Js replaced C++ in the GUI usecase (yes, electron is written with C++, this is not my point).
The standard of success is not "we don't use C anymore", that's an insane definition of success. By that definition C didn't succeed in knocking off Fortran.
This is a function of popularity and time.
> C has a spec. No spec means there’s nothing keeping rustc honest.
Agreed, language specification is critical. The language reference [1] is very detailed, though. I'm not sure what it would take to promote this to a "specification."
> That really cool feature $other_language has? Not interested. It’ll be more trouble than it’s worth
Binding to "editions" is a reasonable way to get stability, IMO. It's a shame that this wasn't adopted earlier.
> Concurrency is generally a bad thing.
So don't leverage it. Don't use fork() or clone() either and we'll all agree to ignore this point.
> Safety. Yes, Rust is more safe. I don’t really care. In light of all of these problems, I’ll take my segfaults and buffer overflows.
Here underlies the crux, you should have led with this. This is a sizable portion of rust's value proposition. If you don't value it then it's likely not to measure up well.
> Rust will eventually fail to the “jack of all trades, master of none” problem that C++ has.
We have to take the good with the bad in everything, right? If Rust's future is "spectacular failure like C++" then it's probably going to be a wild success.
[1] https://doc.rust-lang.org/1.0.0/reference.html