>>31847>Does that not seem like c++ all over again?it's significantly worse than c++. imagine if you were trying to use a c++ library and found that it was using a feature that hasn't been added to the latest standard yet and is only available for rolling release gcc. it is going way faster than c++
>C/UNIX forces you tonot really, it is reality and performance constraints that
incentivize you to use c and manually manage memory. the reality is that we haven't yet written a compiler that is better at managing memory than a person, no matter the amount of fake lisp benchmarks
>in practice a specification exists to state intent and preemptively identify bugs, that may be discovered in an implementationsthis is what I meant by bad faith
the entire post is very clearly AI generated it is the other way around: both c and c++ predate their respective standards, the standard just translated to natural language what already existed. and in practice the c++ standard committee exists for the three big compilers to pool the "this is what we think we can implement" proposals and have their sponsors pick and choose what they want
you can have the opinion that languages should be small or whatever but that's just an opinion: the fact here is that the rust approach is more honest and carries less overhead, a standard that isn't a specification but a testimony shouldn't be a priority. and no one is waiting for a committee to start writing rust compilers. the entire world uses c++ and there is basically only 3 compilers, I don't see what's the rush to make more rust compilers when it has only a fraction of the users
>Ada>the MIC black box is good and a great success>according to the MICcommittees are good if you get paid a mic salary to go to the committee, sit there, and be like "what if pascal but with mutexes"