Andrei Alexandrescu
D Language Architect
137.6k Views
oUpvoted byGarry Taylor,
Been programming since 8 bit computers
Laeeth Isharc,
Programming in C since 1985
Dmitry Popov,
Happy D user since 2012.
Andrei is a Most Viewed Writer in
D (programming language)
In spite of my status and obvious bias as co-creator of D, I'll do my bes I follow Go and Rust, and I also definitely know where D's dirty laundry is. I'd encourage people with similar positions in the Rust and Go communities to share their honest opinion as well. So here goes.
First off, C++ needs to be somewhere in the question. Whether it's to be replaced alongside C, or be one of the candidates that's supposed to replace C, the C++ language is a key part of the equation. It's the closest language to C and the obvious step up from it. Given C++'s age, I'll assume in the following that the question also puts C++ alongside with C as a target for replacement.
Each language has a number of fundamental advantages (I call them &10x advantages& because they are qualitatively in a different league compared to at least certain baselines) and a number of challenges. The future of these languages, and their success in supplanting C, depends on how they can use their 10x advantages strategically, and how they overcome their challenges.
So let me dispense with D first
Obviously this is my house's tour so I know where to walk you all to appropriately show/hide the clean and dirty corners. I'll also have probably more to say about D than the two others for the simple reasons I
knowmore about D than the two others. Speaking with brutal honesty, D's main challenges are:
Poor adoption after many nominal years of existence.Insiders to the D community could qualify this statement (D in its current form is relatively new, adoption does grow, etc). Yet the perception remains, and adoption is driven by perception and becomes fact. So managers and engineers are nervous about adopting a language that's been around unsuccessfully for so long. Furthermore, time works against D unless/until a major uptick in adoption becomes obvious.
Weak story about D's relationship to garbage collection.GC is a great invention, but the decision to use it for D has instantly alienated a core market - existing C and C++ programmers. For those, the party line has historically been &Don't want GC? No problem! You can use D with RAII or manual management style as well!& Though true, that's next to useless because there's little support in the standard library for alternative memory management styles, which means the putative user would need to start with the language stripped down to the studs and create all the core infrastructure. Also, for those who are okay with using a GC, the quality of its implementation is lackluster. Overall it could be said that D has the downsides of GC but doesn't enjoy its benefits.
A historical lack of vision.Absent corporate support, D has been community-driven, where engineering acumen is easier to find than long-term vision, charisma, and leadership. For a good while, the stridency of D's attempts at promotion and PR has had negative value. The first vision document (
http://wiki.dlang.org/Vi
sion/2015H1
) is dated January 1, 2015, and the next iteration (
Vision/2015H2 - D Wiki
) has been four months late in a six-months cycle, which is at best ironic.
There would be, of course, other issues but they either derive from the above or have a much smaller impact.
D's 10x advantages are, I think, the following (when I say &10x& in the following I mean it colloquially a la &one order of magnitude&):
10x faster to compile than C++ for comparable produced code.This gap is essentially impossible to bridge for C++ and prohibitively difficult for any other language. (Go compiles a tad faster than D, but produces slower code.) The experience of using a system language that builds this fast code this fast is transformative and far-reaching. Combined with D's abstraction power, it essentially makes D a good choice for writing highly optimized code for the simple reason that experimentation has a low cost.
10x faster than scripting languages for comparable convenience.A good use of D is as a convenient scripting language for a variety of casual tasks. The build/run cycle is just as quick, and the gain in speed is enormous. Also, there's no &hitting the wall& effect - if a script grows large, D has always more power and modular mechanisms to offer. Of course, this must be taken with a grain of salt because e.g. Python has much more libraries available. But the 10x gap is fundamental: systems languages would have difficulty getting to D's level of conviviality, whereas scripting languages would have difficulty closing the speed gap.
10x easier to interface with C and C++ than any other language.D uses the same memory layout as C and C++; all it does is build structure on top of it, but the lower layers are readily accessible at no cost. The entire C standard library is readily accessible at no syntactic or speed cost, there is work to allow the same for the C++ standard library, and many C libraries are easy to interface with (
gramming...
). It could be claimed that literally no other language can reach that level of integration.
10x better than any other system language at generic and generative programming.D's static introspection, compile-time evaluation, and mixin-driven code generation combine to a powerful cocktail that is very difficult to mix right in other languages, b at this game, Go is so out of depth it doesn' C++17 is hopeless and Rust is just trying to dabble.
I should reinforce here that this is solely my opinion, worth what you pay for it. Go's challenges are the following:
Fundamental slowdown due to indirect calls and garbage collection.Virtually no meaningful Go can be written without resorting to indirect function calls and garbage collection, which are central to its core features. These are major impediments to achieving in-core performance. The response of the Go team has been tactical, e.g. work on a better garbage collector. However, it's unlikely that the challenge of replacing C can be won tactically.
Politics.Go's party line has been disproportionately strong and rigid on a number of issues, small and large. Among the larger issues, the approach on generics has been heavy-handed and demeaning enough to make generics the N word of Go; the whole topic has become enough of a stigma to discourage any attempts at meaningful dialog. I think politicizing of technical matters is an extremely damaging pattern in the long run, and I hope Go finds a way to repair this.
Simple-cum-simplistic.Go is famously simple - there are anecdotes of people picking it up quickly. However, that becomes problem Go code is hopelessly pedestrian - Go coders find themselves writing again and again the same things from an ant's vantage point because Go cannot abstract even the simplest notions or algorithms. Domains that are not already served by easy to glue libraries are difficult to get into. There is backlash from coders who have used Go for one project and wouldn't want to ever use it again. It would be great if Go made life better for repeat customers.
Go's 10x advantages are in my perception the following:
10x better strategy.After a brief period in which Go claimed to be a systems programming language, it has fully committed to the niche of networking services. This has been a brilliant marketing move, which capitalized on the strengths of the Go team (some of the best engineers in the world at networking services). That market is hot, and Go was a fresh breath of air in a world dominated by Java EE bureaucracy and slow scripting languages. Now Go is a major player in that area, and it would be difficult to displace it.
10x engineering.Go has a solid engineering team behind it, and that's a major influencer of the quality of the language and in particular the networking library and the tooling. Until now, good engineering has compensated very well for the lack of power in the language.
10x branding.Many of us are ready to admit that a main motivator of Go is its connection to Google. That gives it a clout of professionalism, quality, and stability. Of course, brand is not everything, but what it means is all Go has to do is
it doesn't have to be a fantastic language. The brand works out the rest.
Last but not least, Rust
Let me again remind that this is only my opinion. I think Rust is facing some interesting challenges:
A disharmonic personality.Reading any amount of Rust code evokes the joke &friends don't let friends skip leg day& and the comic imagery (
earch?q=...
) of men with hulky torsos resting on skinny legs. Rust puts safe, precise memory management front and center of everything. Unfortunately, that's seldom the problem domain, which means a large fraction of the thinking and coding are dedicated to essentially a clerical job (which GC languages actually automate out of sight). Safe, deterministic memory reclamation is a hard problem, but is not the only problem or even the most important problem in a program. Therefore Rust ends up expending a disproportionately large language design real estate on this one matter. It will be interesting to see how Rust starts bulking up other asp the only solution is to grow the language, but then the question remains whether abstraction can help the pesky necessity to deal with resources at all levels.
Foreign syntax.Rust's syntax is different, and there's no apparent advantage to the difference. This is irritating for folks coming from Algol-style languages, who need to deal with a gratuitously different syntax in addition to getting the resource bookkeeping right.
Rust's 10x advantages are:
10x better theorists.Of the three, Rust is the only language with world-class PL theorists on roster. This can be seen in the precise definition of the language and the depth of its technical approach.
10x better safety than other systems programming languages.Of course that had to be here, we just discussed the cost of that.
10x better PR. There has been a long period pre-1.0 when Rust was a community darling and could do no wrong: whatever problem there was, either Rust had a solution to it, or will have had by 1.0. The realities of 1.0 ended that honeymoon and marked (by my measurements and estimates) a stark decrease in general interest, but these effects have a way to linger. Plus, after all, Rust is a decent language with real things going for it, and it's well positioned to convert this lingering hype into solid marketing.
Whether any of these languages is well positioned to either progressively replace C, C++, or both i and whether any of these languages become preferred choices for projects that today would choose C or C++ by default---it all depends on the ability of these languages to play into their respective strengths and find creative solutions to their respective challenges.
View Upvotes
oAsked to answer byElias Abou Khalil
Related Questions
More Answers Below
Which of the following programming languages is the quickest to learn: C++, C#, Java, Erlang, Go, Rust, C, D and Hack?
Will Rust or D ever replace C++?
Is Rust going to replace C and C++?
Will Rust replace Go very soon?
C++11 (programming language)
Is the C++ standard going to include SIMD features?
Matej ?ach
Computer Science student, Rust enthusiast and contributor
16.7k Views
oMatej is a Most Viewed Writer in
Go (programming language)
As others have pointed out,
Rusthas the best shot here - by far.
Why, you ask?
Rust offers clear benefits over C- It's ownership system is demonstratively able to prevent many of the common errors related to resource management, which often lead to security risks or total crashes.
It also offers a much nicer concurrency story, one that does not require you to pull your hair out and that is tied nicely to the ownership & borrowing system to prevent data races.
On top of that, it offers a healthy dose of abstraction and modelling power, as well as functional programming concepts, something C programmers have been denied thus far.
It's still very familiar
- The syntax may be very different, but the basic still hold, curly braces are as integral to Rust as they are in C, basic constructs like
have very similar principles and even the object model with structs may resemble object-oriented programming in C, if only on the surface.
It doesn't require tradeoffs- It is somewhat of a tradition for a new language to come in and proclaim itself as a &C replacement&, only for the programmers to discover that it isn't really.
Take G it was initially promoted as a &systems programming language& only to later adopt the meaning of &systems& to &cloud infrastructure&.
C/C++ programmers couldn't work with it as it has a garbage collector in the same sense that Java has one.
Moreover, C++ programmers felt that they are loosing too much modelling power with the lack of generics and other important features that they've been used to - you don't want to downgrade your experience when switching to a new technology.
As for D, it has the modelling power of C++ and beyond, however it's memory model relies on a garbage collector for safety, without it it is unsafe as C/C++ are and its other benefits are not too many to justify the switch from C++, which is &good enough&.
For C programmers, D is not compelling for the same reasons as C++, too much complexity and lost elegance, for everything they want they can already do in C.
Rust doesn't require these tradeoffs, it doesn't have a garbage collector, is nearly as fast as C, offers as much modelling power as C++, while arguably being simpler and has clear benefits, like resource-safety and a much nicer concurrency story.
The above assumes a &systems programming& domain, since C is most often used there.
For application-level programming, I actually think that Go has a better shot here - it is very C-like, much more so than Rust is, it is as &simple& as C and offers a garbage collector, which is usually a convenience rather than a hurdle for application-level programming.
View Upvotes
oAsked to answer byElias Abou Khalil
Laeeth Isharc
Programming in C since 1985
4.4k Views
oLaeeth is a Most Viewed Writer in
D (programming language)
I am not a language guru' but I am a student of the development of social institutions (and language is one of the oldest human institutions) and an approach that is useful for understanding change in the domain of economics may prove of at least some small value when thinking about the role played by different computer languages and the relationship between them.
Peter Thiel is right: competiion is for losers!
/articles/pete...
And these languages are not truly competing with each other. I really can't imagine (in part for the reasons that Andrei mentions) that in the typical domain of Go there are many users who have an epiphany and think &well, really, this was all a big mistake and we should have written it all in Rust&. And the opposite is also true. Go, as Rob Pike has said, serves a particular purpose, and that's not the purpose of Rust. It really wouldn't make sense for Google to have put those developers not long out of school to work writing in a language whose basic design serves very different needs, and is far from simple, or quick to pick up to a level where you can be writing useful code. Similarly, I doubt anyone at Mozilla had the inclination to write their browser in a language like Go.
D is s little different, because it is more general in purpose. The language itself is quite suitable for writing for embedded systems and some kinds of system programming (the runtime needs some work for some of these cases because that hasn't been the focus to date, but that's a distinct issue). But it's also a pretty good replacement for a language like Python in certain cases, and indeed even at a shop like Adroll, known for its heavy use of Python, D is used by the data scientists because it is productive yet efficient (fast).
In my own domain, which is a particular part of financial markets, I really don't see a real competitor to D for much of what I am doing. That doesn't mean that I won't also use Python for some things, Lua for others, and in time Go might also make sense.
In his speech that is better known today for the pithy saying that &premature optimisation is the root of all evil&, Knuth also welcomed the future proliferation of languages, because language is the expression of thought, and different people naturally think differently, and that's also dependent on the problem domain. It's fun for a bit to pit languages against each other, but it's a mistake, in my view, to think that this captures the essential nature of this question, because it doesn't. I think these languages all have a bright future, but that mostly people will use them for different purposes. C will be around for a long time yet.
View Upvotes
oAsked to answer byElias Abou Khalil
Stephen Baker
Professional software developer since 2007 with computer science degree
6.8k Views
oUpvoted bySergey Zubkov,
C++ programmer (using boost and C++14)
Of those three? Rust is the only one that has a shot in the primary domain of C, and even then I'm not sure how good of a shot it has.
Both D and Go have fairly expensive runtimes which make them a non-starter for embedded programming and ring-0 kernel programming. Rust can be coded without a runtime. It also has an advantage in that not only can it bind against a C library, C code can bind against Rust libraries.
D and Go primarily compete against C#, Java, and a subset of the domain of C++ for application and enterprise development - C hasn't been dominent in those domains for a long time now. C is primarily a systems language for when close to hardware and low overhead are the most important factors. Rust can complete in this area, though they opt for safety over speed so it's likely not to replace C any time soon.
View Upvotes
Joe Duarte
now interested in social/cognitive science of code
3.9k Views
oUpvoted byLaeeth Isharc,
Programming in C since 1985
It's a long shot – D is unlikely to replace C, but I think it has a better chance long-term than Rust or Go. It might not look promising right now, but things change and the tortoise can win the race in the end.
1. Go is out of contention. It cannot replace C, given that it's garbage-collected and somewhat constrained.
Go's strength is that it is explicitly designed with an awareness of the
social contextof software development (or what you might call the organizational context.) This is underexposed. Go was developed
by Google for Google. It was developed with an awareness of the needs of integrating code from a bunch of different developers. That's why it's so opinionated and restricted – it's an entropy-reducing language.
In any case, it can't do what C does, and it doesn't contemplate the needs of non-Google-esque users, embedded systems, OS development, etc.
2. Rust could conceivably replace C, but it is very complex and seems harder for newbies to learn.
Here it's worth pausing to note that whatever replaces C will be adopted by young programmers – people who are young now – not old ones. Like Kuhn noted in describing scientific paradigm shifts, the old guard eventually retires or dies. So it doesn't matter what veteran programmers think about Rust, Go, or D. However, it does matter whether a language is easy to learn.
D is easier to learn. And I'm just very impressed with Andrei Alexandrescu. If he's working on D full-time now, I wouldn't rule D out just yet. They do need hip branding and more patrons. D has always had a pocket protector vibe, in contrast to Rust's youthful, futuristic brand.
All that said, I don't see any of them as
likelyto replace C – I just think D is most likely of the three. The reason is lack of vision. All three languages forgo an opportunity to fundamentally rethink programming language syntax and semantics. None of them are based on usability and learnability research, and rather seem to be based on the preferences of their creators. The culture of software development seems to reinforce and perpetuate insane syntactical conventions.
I think the fundamental insanity of almost all programming languages is a significant factor in the gender and ethnicity gaps in the software industry. People who end up being programmers tend to embrace a programming language as teenagers. They get over the initial craziness of the syntax, but lots of people are deterred by it and leave programming aside. Recent research posits that one of the reasons women are underrepresented in STEM is that smart women have more options than smart men – they have a broader set of skills, including social skills, and thus are free to pursue a broader set of careers. Programming languages look ridiculous to the uninitiated – they're gratuitously unintuitive in ways that don't buy us anything, don't help the compiler, etc. I think smart women are more likely to see it as a waste of their time, and pursue other careers.
The language that has the best shot of replacing C will have sane syntax and draw from research on usability and learnability – it doesn't exist yet. You probably need some fundamental advantages and advances to replace C. Sane syntax would be noteworthy. You also need to think about embedded systems and the broader user base. With Rust, Mozilla is thinking mostly about building a browser, understandably. Multiple dimensions of safety are a must. I think Andrei is fundamentally underestimating the enormity of the security crisis, the price the world is paying for C and POSIX. Computing is fundamentally insecure to such a degree that it might not even be rational to have certain data on computers at all. Software and systems need to work fundamentally differently than they currently do – e.g. code injection is a ludicrous phenomenon that should not be possible, but C does a lot to make it possible.
For some work on sane, research-based syntax, see the Quorum Language, a project led by Professor Andreas Stefik:
Quorum Programming Language
View Upvotes
View More Answers
最新教程周点击榜
微信扫一扫}