Which language - D, Go or Rust has better prospects to replace C and why?

Despite my status and obvious bias as one of the creators of D, I will try to answer frankly; I followed the paths of Go and Rust, and I absolutely know where the dirty laundry is washed in D. I encourage people in similar positions in the Rust and Go communities to share their opinions. So here.

For starters, somewhere in the question should appear C ++. Whether it should be replaced with C, or whether it is one of the candidates for replacing C, but in any case, C ++ is a key element of the equation. This is the closest language to C and an obvious step forward. Given the age of C ++, I further assume in this matter that C ++, together with C, is the goal for replacement.

Each language has a number of fundamental advantages (I call them "an order of magnitude advantage", hereinafter referred to as the "10x bonus", since they qualify for the major league with respect to typical approaches), and a number of problems. The future of these languages ​​and their success in crowding out C depends on how they strategically deploy their 10x bonuses and how to overcome their problems.

Let me get rid of D first

Obviously this is a demonstration of my own home, so I know where to go in order to properly show only what is needed and hide the dirty nooks. I can also talk more about D than the rest of the pair, for the simple reason that I know him much better. Speaking with crude straightforwardness, the main problems of D are:
')

• Bad reception by the public after many years of nominal existence. Long-livers of the community can criticize such a statement (D in its current form is relatively young, popularity is growing, etc.). But this attitude persists and affects the further growth of popularity and this is a fact. As a result, managers and engineers are skeptical about popularizing a language that has been a loser for so long. Moreover, time works against D until there is no obvious increase in popularity.
• The sad story of D related to garbage collection (GC). GC is a great invention, but the decision to use it in D instantly isolated it from the main target audience - C and C ++ programmers. For them, the line of the party looked like “Don't want a GC? No problem! You can also use D with RAII or with manual control! ” Despite the fact that this is generally true, this approach was practically useless due to the lack of support for such a standard library, which meant for the intended user to be stripped to shorts and start with the creation of a basic infrastructure. Even for those who did not object to the GC, the quality of its implementation was rather inconspicuous. In general, we can say that D got all the shortcomings of the GC, but did not take advantage.
• Historical prevailing lack of visionaries. Deprived of corporate support, D led the community forward, in which it is easier to find an astute engineer than a project manager or a charismatic leader. For a long time, the success of D's efforts in promotion and self-promotion had a negative result. The first planning document is dated January 1, 2015, and the next iteration (Vision / 2015H2 - D Wiki) came out four months later than planned, which is a great example of self-irony in terms of planning

There were, of course, other troubles, but they either were a consequence of the above, or had much smaller consequences.

I think the 10x bonuses for D are as follows (once again, when I say 10 times, this is colloquial "better by an order"):

• In 10x, compilation is faster than C ++ for comparable code. This hole cannot be fundamentally closed in C ++, and it is extremely difficult to jump in any other languages. (Go compiles a little faster than D, but the resulting code is slower) The experience of using a system language that compiles so quickly into fast code is transformative of old practices and very promising. Combined with the power of abstractions in D, this essentially makes D a good choice for writing highly optimized code for the simple reason that experimenting is cheap.
• 10x faster than scripting languages ​​with comparable amenities. D is well suited for conveniently scripting everyday tasks. The compilation / launch cycle remains just as fast, and the gain in speed is immense. There is also no problem of “running into limits” - if the script becomes large, D always has enough language tools and modularity. There is, of course, a fly in the ointment, for example in Python there are much more ready-made libraries. But the 10x bonus is fundamental here - system languages ​​do not have so much syntactic sugar, and scripting languages ​​are hopelessly behind in speed.
• In 10x it is easier to integrate with C and C ++ than any other language. D uses the same structures in memory as C and C ++; and builds on top of them, but reading the underlying layers remains free in terms of speed. The standard C library is fully accessible without any penalties - neither in terms of speed, nor in syntax, and although some improvements are needed for similar simplicity in terms of the C ++ library, many C libraries are already available (https://github.com/D- Programming ...). It can be stated literally that no other language can achieve this level of integration.
• 10x better than any other system language in generics and metaprogramming. In D, static introspection, compile-time computing (CTFE), and mixin- based (code-mixing) code generation make up the Molotov cocktail, which is very difficult to mix correctly in other languages, neither new nor survivors; in this game Go is so crazy that it doesn’t even cut a chip; C ++ 17 is hopelessly lost in a dark forest; and Rust is just trying to babble.

Go to Go

I must emphasize that this is solely my opinion, nevertheless worth your attention. Go problems are as follows:

• Fundamental slowdown due to indirect calls and the garbage collector (GC). Almost no significant Go application can be written without resorting to indirect calls and GC, which are the center functionality. These are the main barriers to Go core performance. Go's response was mostly tactical - for example, improving the performance of the GC. However, it is unlikely to win the challenge of replacing C tactically.
• Politics. The party line at Go is disproportionately strong and tough on a number of issues, both small and large. One example of a big problem - the approach to generics was so meaningless and merciless that it made generics the word with the letter "G"; the whole topic turned into bloody tears, hindering any attempt to establish a constructive dialogue. I think that politicizing technical issues in the long run is an extremely detrimental model, and I hope that Go will find a way to fix this.
• Simplicity is worse than theft. It’s very easy to go (pun, Go - walk, comment) - there are even jokes about it. However, over time this becomes problematic; Go code is hopelessly pedestrian - Go coders find themselves writing the same things over and over from an ant's point of view, because Go cannot abstract even the simplest concepts or algorithms. Concepts that are not yet implemented by integration libraries are difficult to implement. There is a negative reaction from programmers who used Go for one project and no longer want to use it again. It would be nice if Go made life better for regular customers.

Go 10x bonuses in my perception are as follows:

• 10x in skill Strategy. After a brief period when Go was positioned as a system language, it was decided to position it for network services. It was a great marketing move that took advantage of the Go team's strengths (some of the best network services engineers in the world). This is a very hot market and Go simply became a breath of fresh air for the world, which was previously dominated by Java EE with its red tape and slow scripting languages. Now Go is the main player in this area and will be difficult to move.
• 10x in the skill Engineering. Go has a strong team of engineers behind it, and this is the main factor influencing the quality of the language, and in particular the network library and toolset. So far, good engineering has fully compensated for the weakness of the language.
• 10x in skill Branding. Many of us are ready to admit that the main motivator for using Go is its connection with Google. This gives him the authority of professionalism, quality and stability. Of course, a brand is not everything, but it already makes Go a worthy language; he should not be fantastically good. Brand will do the rest.

Last but not least, Rust

Let me remind you again that this is only my opinion. I think Rust is facing some interesting problems:

• Disharmonious personality. After reading a certain amount of Rust code, anecdotes such as “Dude missed days of legs swinging” appear, illustrated by comics with people with a torso and legs crossed (approx. Translation. In Russian, “Colossus on clay feet”, but inaccurate) Rust puts Accurate and secure memory management comes first and represents the center of the world. Suddenly, this is rarely a problem area, which leads to the fact that a large proportion of planning and coding is devoted, in fact, to clerical work (which languages ​​with GC automate without looking). Safe, predefined memory reuse is a serious task, but not the only, or at least not the most important in the program. As a result, Rust spends a disproportionate amount of language design resources on just that. It would be interesting to see how Rust swells for other aspects of the language; the only option is to expand the language, but the question is how much abstraction can help with the unpleasant need to control resources at all levels.
• Foreign syntax. Rust's syntax is different [from everyone], but there is no obvious advantage in such exoticism. This annoys people who come from languages ​​of the Algol family, who have to deal with radically different syntax, in addition to the need for manual management of all accounting with resources.

Rust's 10x bonuses are:

• 10 times the best theorists. Of these three, only Rust has world-class theorists in developing a coding language. This can be seen in the accuracy of the technical description of the language and in the depths of the technical approach.
• 10x more security than other system languages. Of course, this should be here, we can only debate about the cost of such an approach.
• 10 times the best PR (PR, advertising, approx. Per.) There was a rather long period when Rust was the favorite of the community, which could not be mistaken: for any problem, Rust either had a solution or had to get it with the release of 1.0. The reality of the release of 1.0 interrupted this honeymoon and was marked (in my measurements and expectations) by a sharp decrease in general interest, although these factors tend to prolong. Plus, in the end, Rust is a decent language with real achievements, and it is well positioned to turn this protracted hype into a stable market.

Briefly

Whether one of these languages ​​is capable of either gradually replacing C, C ++, or both languages ​​in existing software systems, and whether these languages ​​will become priority for projects that today choose C or C ++ by default - it all depends on the ability of these languages ​​to use their advantages and find creative solutions to their respective problems.

Note translator.
Sorry for the old article, I just came across it at the end of my series on reliable programming, and seemed fun enough to quote. In RuNet, however, a translation, and indeed a full discussion, was not found.