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.
The Rust team has a very high commitment to stability, and does way more to maintain stability than any other language/compiler I know of (by testing new versions and potentially-breaking-changes against the entire ecosystem)
> still don't (seem) to understand the non technical problems it has.
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. Alternate implementations are hard to write and take time. The language is still new, but work is being done towards speccing it (e.g. the unsafe code semantics work being done right now). 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.
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.
What are you talking about? There was a C standard because so many groups picked up C. The Ada mandate actually reduced its uptake with a bit of a rebound latter on when the tech itself was better (esp compilers). C++ got uptake before a standard plus fed into the C standard. So, no, the lack of a standard isn't stopping adoption by industry outside select firms that won't pick up tech unless it has a standards document which often isn't even accurate.
What industry does care about are compilers, IDE's, existing libraries, available talent, ecosystem, who they can pay for support. These things aren't at a level they like yet. Adoption stays low.
Note: Most infrastructure is written in C due to talent and compiler availability more than anything. That's what most embedded people tell me.
As for the rest, i agree.
Sure, there will be some cases where you absolutely need a standardized language. And Rust won't work there for a while at least. But that's a far cry from the picture painted in the original post.
Yes, and that is why those industries will choose to ignore it for a while at least.
Chicken and egg.
> 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.
As for specification, https://github.com/rust-lang/rfcs/pull/1643 is what's currently happening, i.e. specifying exactly how unsafe code behaves (this is more important than specifying the rest). But the rest will come.
As for the industry, https://www.rust-lang.org/friends.html
I'm all for this but I really don't see how Rust's stability can hold a candle to the international standards committees that govern C and C++ (not to mention the investment from the big tech companies in developing and implementing these standards)
That's an orthogonal issue; that's adoption. More adoption means more stability, regardless of whether or not the thing has a standards committee.
Of course Rust can't hold a candle to the level of adoption C has.
> as much they still don't (seem) to understand the non
> technical problems it has.
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.
Interesting, but if you try to see the perspective of the Rust developers, they're a relatively small group trying to first develop the strongest language possible, after which other implementations will rise in priority. The idea is, it's better to develop a great language first and focus on other priorities later, rather than having a mediocre language with many implementations. Nonetheless, they're taking the necessary steps.
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.
What? There is only one person talking about that, and that's me, and that's pretty low priority right now. There are three people total who are working on it (I worked on the higher level design, and felix/niko/I will implement bits of it at some point) and I don't think any one of us is currently doing anything here.
OTOH there is a whole group of people actively working on standardizing how unsafe code is supposed to behave. There are pushes for standardization elsewhere too, though unsafe code is the more pressing one since that's where actual UB can happen and that's where you need a standard the most. There's a group working on formal verification as well (which could produce a standard as a byproduct). Not sure if there are plans for making it an IEEE standard, but a standard it will be.
Standardization is a topic that crops up pretty regularly in discussions. Optional GC is not.
The type system is still in flux with specialization and a bunch of other type system changes on the horizon. These don't affect language stability, but they do affect how the standard would look since they may completely change how you describe the type system. Starting work on a complete standard right now doesn't make sense with these bits missing.
Edit: it's also not "optional garbage collection", really, it's just hooks so that it's easy to write your own GC, or, more importantly, integrate with another one. Rust is getting a lot of attention from folks wanting to speed up portions of their Python/Ruby/whatever codebase, so having these is important.
The syntax of the language is also designed to help the compiler writer and not the user – think of "declarations mirror use", the irrelevance of the order of type specifiers, etc.
Err, I would agree with the statement that the syntax of C (mostly) favors the compiler writer, but "declarations mirror use" is decidedly not a good example for a couple of reasons:
1. The grammar for type declarations is actually quite complicated[1]
2. Agol, which inspired C's type system, actually had a much more "compiler friendly" type syntax[2]. C's syntax is designed to be more programmer friendly.
3. Dennis Ritchie makes it pretty clear that "declarations mirror use" was intended to make use and declarations visually similar, which implies that it was done for the benefit for the programmer[3].
[2] http://www.csci.csusb.edu/dick/samples/algol60.syntax.html#5...
[3] "Analogical reasoning led to a declaration syntax for names mirroring that of the expression syntax in which the names typically appear...In all these cases the declaration of a variable resembles its usage in an expression whose type is the one named at the head of the declaration." from http://www.jslint.com/chistory.html
In my view, a "user-oriented" declaration of an array of pointers would look like `pointer[10] of int`, and not `int *arr[10]`.
This is pretty close to Pascal syntax already: `array[0..9] of ^Integer`, where ^ is pronounced 'pointer to'.
Pascal is a language that is genuinely easy to parse; it's designed to be LL(1). C is not; in particular, typedefs effectively introduce keywords, and the easiest way to parse C is to inform the tokenizer about typedefs as they're found so the parser can disambiguate things like `a (b);`; this looks simultaneously like declaring a variable and calling a function, depending on the type of 'a'.
(they don't look the same, but you can use either to define record/structure types or enums, for example)
int main()
{
foo(bar);
foo * bar;
}
The situation doesn't come up in Pascal because variables go in the var block (starting with the 'var' keyword) and functions and procedures both start with keywords ('function' and 'procedure').
It never occurred to me to put variables names inside parens in a declaration when I did C, though. But OF COURSE it's legal obfuscation.
As stated elsewhere, I don't know why C had to screw up Algol's syntax so badly. I guess K&R liked curly braces much more than BEGIN/END, and why stop there, once you get going. Maybe somebody had a love affair with APL???
Using the same precedence and associativity in declarations and normal expressions doesn't really help the compiler writer though, so I'm not sure how this supports your point. If anything, it complicates the parser by making it harder to decide if a given sequence of tokens is a declaration or an expression (e.g. the classic "a * b;" problem).
> In my view, a "user-oriented" declaration of an array of pointers would look like `pointer[10] of int`, and not `int *arr[10]`.
It sounds like you're saying that C's type syntax isn't easier to read than other, similar, possible syntaxes. On that, I completely agree (in fact, I think C's type syntax is horrendous). However, that's orthogonal to the issue of Dennis Ritchie's original intent when designing C. From his writings at least, it seems like he wanted to make it easy for the programmer to reason about the syntax and I'd even argue that he took steps to complicate the compiler to accommodate his chosen syntax. I'd also argue that he failed horribly in accomplishing his intention and the syntax you're describing would have been much easier to read.
Not rocket science, obviously, but the original statement was that C types were designed to be easy to parse, which clearly isn't true. If the types were prefix or postfix, it'd be trivial to build the trees in a recursive descent parser.
And remember declarations can be arbitrarily complex. How do you declare a pointer to arrays of pointers to pointers to arrays? In free prose.
If you look at another old language, Ada, you'll find much more precise control.
In theory that's important, in practice you rely on implementation-defined behavior and put it behind a layer of macros. It's not perfect but it works - low level capabilities are not the problem in C.
Lack of high level abstractions make scaling it up and maintaining a PITA.
https://commandcenter.blogspot.com/2012/04/byte-order-fallac...
Also, it can't be denied that there will always be areas where the exact control of memory layout that C gives you is not just nice-to-have for performance reasons, but a prerequisite for a good implementation or understanding of some algorithm.
Neither of those points, however, mean that C is the only suitable language imaginable for doing low-level work, or that the past forty years of programming language research are irrelevant to the spaces that C excels in. I think Rust shows quite succintly the immense value of the combination of an expressive type system and C-like zero-overhead abstractions.
Learning C, like learning some assembly languages, to some extent is probably necessary if you're serious about understanding computers, just to understand what's going on. But when it comes to actual use in production systems, I am glad that we are seeing serious alternatives to a language so prone to simple bugs as C. Think of all the time and money that have been lost to buffer overflows and segmentation faults.