|
Never mind my position as one of the creators of the D language. I will answer this question honestly. I am familiar with Go and Rust, and I know where D's shortcomings are. I encourage people in similar positions in the Rust and Go communities to give their honest opinions. So, let's get started. First, where does C++ fit into the equation? Whether it replaces C or is a candidate to replace C, C++ is a key part of the equation. It is the closest to C and it is also derived from C. In the following questions I will assume that C++ aims to replace C. Each language has some basic advantages (I call them "10x advantages" because they are indeed more efficient than others on certain benchmarks) and several challenges. Whether these languages can replace C in the future depends on how they use their 10x advantages and how they overcome their several challenges. [[156276]] Let me abandon D first Talking about D is like showing you around my house. I know how to show you/hide the clean/dirty corners. I can say more about D than the other two languages. The reason is simple: I understand D more deeply. To put it bluntly: The main challenges of D are as follows: - Low adoption – Despite being around for so many years. Those in the know in the D community would argue that D is still relatively new and adoption is up. And, this perception still exists, and adoption is driven by perception. So managers and engineers feel apprehensive about adopting a language that hasn’t matured in years. Time will continue to work against D in the future unless/until adoption numbers grow by leaps and bounds.
- D is tenuously connected to the garbage collection story. Garbage collection is a great invention, but the decision to use it in D immediately separated D from its core market - existing C and C++ programmers. For these programmers, the party dividing line has always been "Don't want garbage collection? No problem, you can use D with RAII or a manual management style!" While this is true, it is close to useless, because the standard library has little support for other memory management styles, which means that the putative user needs to rebuild the entire core infrastructure. And even if you think it's okay to use garbage collection, the quality of the implementation is nothing to brag about. In short, it can be said that D has the disadvantages of GC, but none of its advantages.
- There has always been a lack of vision. Few companies support D. D became popular in the community, where engineering sensitivity is high, and long-term vision, charisma and leadership are difficult to find. For a long time, D tried to influence and public relations, but all had negative effects. The first vision document (http://wiki.dlang.org/vision/2015H1) was written in January 2015, and the second iteration (Vision/2015H2 – D Wiki) was written 4 months later. One cycle is 6 months. This is really a *** irony.
Of course, there are other problems, but they are either derived from these problems or have similar effects. I think the 10x advantage of D is as follows (when I say "10x" below, I generally mean "an order of magnitude"): - Compiles 10 times faster than C++. The gap between C++ and other languages is simply unbridgeable. (Go compiles slightly faster than D, but runs slower) Using a system-level language to code quickly is a profound change. Combined with the abstraction power of the D language, D is basically a good choice for writing highly optimized code, simply because the experimental cost is very low.
- 10 times faster than scripting languages. One great use of D is as a scripting language for simple tasks, where the speed benefits are huge. Of course, there is no "bottleneck period" effect - if a script grows large, D always has a very efficient and modular mechanism to provide. Of course, this is questionable, for example, Python already has a lot of libraries to choose from, but the 10-fold gap is fundamental: it is difficult for system-level languages to reach the level of D, but it is difficult for scripting languages to break through the speed gap with it.
- 10x easier to integrate with C and C++ than any other language. D uses the same memory layout as C and C++; what it does is build structures on top of it, but is much closer to the bottom layer at almost no cost, the entire C standard library couldn't be closer in syntax and speed, it's also the standard library for C++, and many C libraries integrate easily with D. (https://github.com/D-Programming-Deimos). It can claim that no other language can match its level of integration
- 10x better than other systems languages and languages in general. D's static introspection, compile-time evaluation, and mixin-driven code make it very effective in ways that are difficult in other languages, new or existing; Go lacks the depth or even the focus in this game; C++ is hopelessly lost; and Rust is still trying.
Let’s talk about Go Let me reiterate here that Go is my only choice and it is worth your effort. The main challenges of choosing Go are as follows: - The inherent performance degradation caused by indirect calls and garbage collection. In fact, it makes no sense to transform Go without indirect function calls and garbage collection, because these are its core functions. These are the main obstacles to improving core performance indicators. The response of the Go team is to improve the performance of garbage collection tactically. However, the challenge of replacing C language cannot be accomplished through some tactics.
- Political factors. Go's factions are extremely powerful, and each has its own insistence on many issues, some big and some small. Among the bigger issues, the implementation of generics is very clumsy and low-level, making generics one of the shortcomings of the Go language; discussions on similar topics are enough to make people depressed. I think the political factors of technical issues are an extremely destructive factor in the long run, and I hope the Go team can find a solution.
- Simplified but oversimplified. Go is famous for its simplicity - it's really fast for everyone to get started. But over time, this becomes a problem; Go code slows down completely - programmers find themselves writing the same thing all day long, like an ant, because Go doesn't have a good abstraction for even simple concepts and algorithms. If a field doesn't have ready-made easy-to-use libraries, it's hard for ordinary people to get into it. It's a bad feeling for programmers who never want to use Go again after using it. It would be great if Go could make the situation better for users who always repeat work.
Here are my 10x advantages of Go: - 10x better strategy. For a while Go was purported to be a systems programming language, but then it became a completely new language for web services. This is a very promising market, and the Go team has a very good grasp of it (they have some of the best engineers in this area). This market is very hot, and has been dominated by Java EE and some slow scripting languages, and Go was a completely new choice in this area, but now it has become a major choice, and its low position is irreplaceable.
- 10x advantage in engineering. There is a pure engineering team behind the Go language, which greatly helps the quality of the language, especially for network libraries and tools. Excellent engineering management makes up for some shortcomings in language capabilities.
- 10x brand effect. Many users who plan to use Go language do so because of Google. Google products seem to mean professionalism, high quality and stability. Of course, brand is not everything, but it means that Go language only needs to be good, not perfect. The brand can do the rest.
***But not least Let me remind you again that this is just my opinion. I think Rust faces some interesting challenges: - A discordant personality. Reading any amount of Rust code brings to mind the comic image from the joke "Friends Don't Let Friends Have a Day of Crossed Legs" (https://www.google.com/search?q=..). The man with his torso resting on skinny legs. Rust puts safe, precise memory management front and center for everything. Very little problem domain, unfortunately, which means that most of the thinking and coding is devoted to basic clerical work (the GC that the language actually automates is missing). The problem of safe, deterministic memory reclamation is hard, but it's not the only problem, or even the most important problem in a program. So Rust is consuming itself hugely on this language design problem. It's interesting that Rust is starting to grow out of other aspects of the language; the only solution is to evolve the language, but the question remains whether abstractions can help deal with the necessity of resources at all levels.
- Foreign syntax. Rust's syntax is different, with no discernible advantage to the difference. This is for people coming from Algol-style irritating languages who need to deal with a syntax that's different for no reason other than proper resource bookkeeping.
Rust's 10x advantage is: - Theoretically, it is 10 times faster than the others. Among the three, Rust is the only one that has world-class performance. This can be seen in the depth of its precisely defined language and technical approach.
- 10 times better security than other system programming languages. Of course, here we are limited to discussing its cost in security.
- The price-performance ratio is 10 times better than others. For a long time, Rust's 1.0 preview version was the darling of the community, without any mistakes: no matter what problems occurred, the existing Rust or the future 1.0 version would have a solution. Now that the 1.0 version has ended its honeymoon period, people's interest has dropped significantly (according to my personal calculations and estimates), but its influence will continue to exist. In addition, after all, Rust is an orthodox and practical language, and it is easy to convert people's enthusiasm into physical sales.
all in all Whether these languages are positioned to gradually replace C, C++ or exist simultaneously in the code base, or they will become the first choice for future projects, people today will still choose C or C++ first - it all depends on the capabilities of these languages, try to play their strengths and make breakthroughs in their respective challenges. |
