S_I
As for the rest, i agree.
Yeah, i remember using the Mac OS written in Pascal. Strangely enough, i remember it being buggy as hell and crashing pretty often (no memory protection at all).
Want all of that and a whole bag of inconsistent design choices? C++. Because, yes, one day you will meet a C++ codebase which is a mixture of "forbidden C++" and "modern C++".
Agreed, but when is Rust done? 1.0, 2.0, 3.0?
Why does the Rust community talk more about adding optional garbage collection than IEEE standardization and alternative implementations (for example for gcc)?
You see, there's always this "one more feature" before it is a "great language".
If you want to sell it as a C alternative/replacement and keep going this way, it will be neither a technical nor a spiritual successor.
> though I suspect multiple implementations will come from elsewhere since we already have a couple partial ones)
>Rust already has lots of folks from other industries trying to use it
I'm not up to date. Input would be appreciated here.
Yes, and that is why those industries will choose to ignore it for a while at least.
Chicken and egg.
Yes, for most developers this is true, but not all (see post above). Try looking at it from my perspective. If i suggest to my peers to give Rust a (serious) try and evaluate it for use in a project, this "hardly a priority" generates the impression of "we don't care right now, maybe someday". So they say "fine, i will give it a try in x years, when multiple implementations are available. It the meantime we will wait and C.".
So basically, chicken and egg. Again, the Rust community needs to understand what kind of impressions they generate vs. which impressions they want to they generate.
Update: Just to make that clear, i have to look at it from the perspective of an industry that produces infrastructure and complex, big machines.
Update 2: Fixed typo.
Yes, but my experience is that they don't seem to manage generating the kind of trust needed to get my peers to give it a serious go. It's a purely social and subjective problem.
>Just because multiple implementations of Rust don't exist (there are a couple but nothing 100% feature complete iirc) doesn't mean that the community doesn't understand the need for it.
As i said, it SEEMS to be so. That means that it is a subjective impression my colleagues and me get. It is the job of the community to generate trust, not the (potential) user's.
>Alternate implementations are hard to write and take time.
Yes, see my P.S. Time will tell if it's worth it to compiler vendors. C made it easy for them right from the start.
>Note that most languages have gone for years without getting a proper spec or alternate implementations. This is an advantage C has over Rust, agreed. It's usually not a dealbreaker, though.
Not a dealbreaker for whom? In the infrastructure and big machine business you will see C, some C++ and Ada. All standardized.
If the Rust community wants to offer an alternative for C, C++ and Ada, AND want Rust to succeed as an alternative, they need to understand that trust (in the toolchain) is generated in different ways in different industries.
Do you know which non technical advantage C has? Multiple implementations. Don't like gcc, use clang. The Keil compiler has a certain bug that screws your project? Use IAR. And so on.
That is one thing. Another thing (at least at the company i work for and the ones i know) is, companies that write code for infrastructure or machines that need to rung a looong time won't ever trust a language (and toolchain) that comes in versions and not in IEEE standards. That may or not be stupid, but it is the reality i've seen so far.
P.S.: Before someone says C only NOW has multiple implementations, yes, at some point in time that was true, but i was VERY easy for compiler vendors to implement a C compiler (speak ROI). Time will tell if this will be true for Rust as well.
Good to hear about the possibility of a LTS release! Any rough estimation about the timeframe?
Oh and by the way, the documentation is fantastic.Big thank you!
Before i reply, i would like to make two point clear.
First, i'm not going to argue about performance, because i've used Rust for personal projects, i can say that it is really (like REALLY) efficient. Performance is great, no discussion.
And two, as said, i've used it and like it. But honestly, the best thing about it (IMO) are the error messages. So...
1.Agreed. I'm just skeptical if i will see the day that those new processors will be as energy efficient as a 8051. Power consumption will always be an issue.
2.Well yes and no, at least that is my (maybe false) impression.As you say, if you want to be really efficient with Rust, you really should program functional as much as you possibly can. So is it functional or not? My impression is that it most of the time does not know what it wants to be.
3.Agreed and motivational to hear that it just takes some time (i'm still not that good with predicting the outcome).
4."Just like `Vec` does dynamic allocations, and you can just not use it." This, right there. The "and you can just not use it". This is what the C++ camp is saying, so the Rust community could end like the C++ community, where everyone is using another dialect.But that's just my personal grief.Anyhow, yes UB is maybe THE biggest problem. I've mentioned CompCert above, so if you are interested see http://compcert.inria.fr/man/manual004.html.
Regarding "A lot of human suffering had to been thrown at the problem to make C code do the job there", yes i agree. But now it (mostly) works, and nobody wants to risk anything and touch that code base, let alone rewrite.
5.Agreed.
6.My experience is not even that my peers have better things to do or do not want to try. I think it's matter of taste. People are different and prefer different things.
To seren: "Rust would not have been a silver bullet but there is a whole class of error that would not have happened, and would have been forbidden in the first place. The subcontractors were supposed to use a static analyzer but we got the code back we had to fix 5000 defects of the worst kinds (buffer overflows, dereferencing null pointer, memory leaks and so on) For me, the value proposition of Rust is that it is roughly equivalent to C + a good static analyzer, but it is for free, and you are sure the checks are in place and have been executed."
What makes you think that those people wouldn't have used "unsafe" everywhere, just because it makes their job easier?You would have ended up with the same mess.
Hmm, i don't think i understand that. Of course we do not disregard MISRA-C. I don't know where this impression came from. As i said, no dynamic allocation, no pointer arithmetic etc. Could you elaborate?
"What about bounds checking and making sure the pointers are always valid?"
Well, if your code is controlling big, possibly dangerous machines, you will/should be doing formal verification anyway (i use FRAMA-C). This will go a long way regarding said issues.
Furthermore you will not/should not create your complex state machines by hand. There are tools for that (and yes, formally verified as well).
P.S.: CompCert is a necessity as well.
But before i explain my reasoning, i will the define the term 'embedded development' for this comment as follows: - No gigahertz (not even close). - No multi core. - No giga- and no megabytes of RAM. - No OS. - Micro second respond time, but truck loads of computation. - No ARM processors.
So here goes.
1.In my world memory safety is simply not an issue, because we don't allocate dynamically. So neither the borrow checker nor lifetimes are an advantage.
2.The micro controllers are piloting a complex machine with all kinds of actuators and sensors. So the code is actually (and that is really a rough generalization) a big state machine. So the functional elements of Rust don't help that much because, although functional programming and state machines are doable, the code is IMO far from ..... let's say elegant.
3.If you do real time systems with micro second respond times (like i do), you really want to know what kind of code will be generated from a specific line of code just by looking at it. Maybe experienced Rust developers are able to do that, input would be appreciated here (looking at you Steve ;-).
4.I'v read about the guaranties the Rust developers give regarding stability of features, breaking changes etc. This combined with the (at least in this domain) neck breaking speed of development (i see the Rust community already talking about optional GC) is pretty much a show stopper in this domain. Why? Because (warning generalization coming) most embedded developers are already dealing with really hard problems, they simply don't have the time to keep up. Furthermore, if you have code that needs to be not only compilable, but also functionally working after twenty years (yes you read that right), you do not want things developing that fast. Remember, this kind of code is keeping all the infrastructure we all rely on working.
5.Rust is a complex language to build a compiler for. You will have to persuade Keil and friends to invest the time and money to do that. And no, LLVM is no option, because it does not target enough architectures.
6.Rust is perceived as too complex by my peers. Don't say it is easy. It is may be easy for you or me, but not for everyone. And you know, those people are valuable too and need a job too.
So there you have it. Rust just does not buy you enough in that kind of environment.
Personally i would have been happier if Rust had become "C with only the borrow checker and nothing else".But the community decided differently, and that's OK too.
I'm a low level guy (embedded and systems stuff) and what i would hate in our codebase is if look at line of code and find x numbers of concepts in it.
Nevertheless i applaud what you and the Rust community achieved, but my impression is that you'll be going the C++ way. Why? I follow the discussions of the Rust community about the future of the language, and there's always this "if we only add this one more feature" (for example see discussion about GC).
P.S.: For everyone saying "just use the features you need", no, this won't work. If they are available, people will (a)use them (see C++).
Edit: Typo.