17 ms·
D Future
- fithisux 10y agoDlang's future is bright. It is the one true C++. In a related article, someone proposes C++ for physicists instead of Fortran. I propose to use Dlang or evolve Fortran to be more D-like. But take a look at the vast research C++ code. It is there unmaintained and unmaintainable. Dlang would make a huge difference here. The best are yet to come. C++ suffers from a serious personality disorder. It is C / it is SML / it is Python and finally it is perplexing and dangerous like JavaScript. If I had to use C++, I would stick to C. If I could change C++, I could throw away OO and Exceptions and see how to integrate templates and closures to C and make the language less forgiving.
- greyman 10y agoIn my career I worked on three C++ projects with about 100 developers, and OOP proven to be useful. If the codebase is so large that not a single person knows it as a whole, OOP allows to express the structure of the code. I surely wouldn't want to do it in C. The only drawback I noticed is that you need to learn more to understand and be proficient in C++.
- jcoffland 10y agoOne of the great things about C++ is that it weeds out the shitty developers. Not that there isn't plenty of shitty C++ code out there. There's just not a lot of C++ code out there that's both shitty and kind of works. If you don't do C++ right it will fail spectacularly. Poorly written software in languages like Java, Go, Python, etc. can hobble along miserably for decades because when it's broke it probably still kind of works event if it's slow and constantly spits stack traces. A C++ program has to be beautiful or it probably wont last long.
- pjmlp 10y agoI imagine you are yet to enjoy the wonders of outsourcing and offshoring C++ code.
- kibwen 10y agoI don't think that this argument proves the initial assertion that C++ "weeds out the shitty developers". Shitty code doesn't just appear out of thin air, and god knows I've both read and written some shitty code (including shitty C++ code) in my day. Shitty C++ code survives exactly the same way that shitty code survives in all languages: by piling ill-considered hack upon ill-considered hack until your boss stops complaining.
- MaulingMonkey 10y ago> There's just not a lot of C++ code out there that's both shitty and kind of works. I promise you, there is. That you've managed to avoid it earns you my envy, although not my agreement. Raymond Chen sometimes blogs about all the weird historical niggles and backwards compatibility hacks that lace the Win32 API because of, ultimately, shitty C++ code. I've seen similar, or even worse. And yet, I've got absolutely nothing to complain about compared to some of the horror stories I've heard from other devs and the codebases they work on.
- fithisux 10y agoI am a shitty developer, but as a researcher, I have common sense and my BS radar shows a very big signal at C++ direction. When I see problematic C++ I do not start blaming the developers. Part of the problem is the developer and the other part ~ 50% is the language. Since I am a shitty developer and a coward, I would never do C++ buddy jumping again. Last time I pissed my underwear. The others, who didn't back-off, destroyed a 200.000 EU research program fixing bugs, refactoring and seeking the holy Grail of low-level performance instead of doing meaningful research and improving algorithmic complexity.
- jcoffland 10y agoThank you for admitting it and knowing your limitations. The world could be saved a lot of time and money if more people followed your example. However, as with any challenging skill in life, you have to be shitty at C++ before you can hope to be good at it. We need some brave souls to attempt to become good programmers otherwise we won't have any. The biggest problem with software today is all the shitty programmers out there who are employed as if they were good at it. C++ helps weed those programmers out because it's very difficult to be at all productive in that language of you're shitty.
- p0nce 10y ago> A C++ program has to be beautiful or it probably wont last long. You can't be serious. A C++ program has difficulty being beautiful because changing anything takes lots of time to compile. C++ subtly trains your brain not to ever change anything. Beautiful C++ code does exist though, and is often the output of a single developer.
- jcoffland 10y agoProducing non-shitty C++ code with multiple developers is exceptionally hard since all your developers have to be good. Of course that's true for any language.
- 72deluxe 10y agoStroustrup explicitly mentioned in his keynote at this year's CPPCON that 2016 that C++ has the ability to be low level and also provide higher abstractions so you get away from thinking specifically about implementation details and more about ideas. I think that's the power of C++ (the fact you can do both), and without OOP would be useless.
- sanxiyn 10y agoI disagree Rust is more complex. Sure, Rust is more different, but not more complex.
- jasoncchild 10y agoAgreed. A lot of the op is bit hyperbolic in expressiveness.
- ainar-g 10y agoSame goes for "Go saps all the fun out of the coding". As an ex-Ruby programmer, with Go I've never had so much fun programming since tinkering with C in college. Go just doesn't get in the way of implementing ideas, which is the core of the fun.
- pawadu 10y agoSame here, go feels "fun" for some reason. Maybe its the well-thought standard library, maybe its the way the compiler helps you. Maybe its because we can actually catch bugs at compile time instead of those runtime errors and silent drops of javascript
- simfoo 10y agoOf course Rust is more complex. Lifetimes and the borrow checker are hard to get used to
- holydude 10y agoI think we are experiencing a fatigue in general when it comes to IT and technologies. Sure technology evolves but you can learn only so much at the same time. People prioritize. If the technology is not appealing to me I won't use it but at the same time if the technology is massively used and pushed by corps and startup hype I have to at least take a look. D did not attract enough people nor it has a backing of multi billion dollar corporation.
- qznc 10y agoReasons for D: It is a way out of the C++ tar pit, because it does C++ interop better than any other language. D needs to continue to outrun C++ evolving, though. See http://dconf.org/2016/talks/watson.html http://dconf.org/2016/talks/watson.html or https://www.youtube.com/watch?v=IkwaV6k6BmM https://www.youtube.com/watch?v=IkwaV6k6BmM It has powerful meta-programming. It is effectively the opposite of Go, which does not even have generics. This certainly provides foot shooting as well, so other languages (e.g. Rust) are more conservative with that. D examples: https://qznc.github.io/d-tut/meta.html https://qznc.github.io/d-tut/meta.html Those are the two reasons, which D has ahead of all other languages (ok, not Lisp wrt meta-programming). If you compare it to another specific language, there are more things to talk about.
- robochat 10y agoI found the post slightly contradictory but overall strongly evoked the frustration that the author felt. My reading is that most of the problems come from a lack of manpower or perhaps a lack of delegation but I'm only reading this as an outsider. I think that D is a language that I would like to use but I don't because few seem to have heard of it. This is the catch22 problem that D finds itself in. Popularity contests are fickle and not just restricted to the high school playground unfortunately. Look at swift, i read about problems with breaking changes and compiler crashes and it just doesn't seem to matter because Apple. Anyway, my question is, what are the weak points of D? I should state at the outset that I have no problem with there being a GC as I'm a python programmer not a C programmer but one who wants to learn a compiled language. I'm more interested in any other issues that might warn me away from D.
- qznc 10y agoThe weak points of D? If you want the high-level view by the project leaders what needs to be done, look at the vision document: https://wiki.dlang.org/Vision/2016H2 https://wiki.dlang.org/Vision/2016H2 D certainly needs more libraries, but which language doesn't? The currently available stuff is: https://code.dlang.org/ https://code.dlang.org/ Further stuff depends on what you would use D for. You describe yourself as a "Python programmer". Web development? In this area D is still weak. There is only one solid framework http://vibed.org/ http://vibed.org/ which does not officially support any SQL database (it has Mongo and Redis though). Personally, I think vibe.d is fine for micro services, but it is still a long way until it could compete with Django. I built a prediction market web app with vibe.d. It has hand-written SQL queries (should probably have used https://code.dlang.org/packages/hibernated https://code.dlang.org/packages/hibernated). I had to write Github authentication from scratch. There are few conventions, which is irritating if you are used to follow Django tutorials. You feel lost. That is my experience with D. Personally, I have no issues with the standard library like the ranter, but I assume I'm in the minority with that.
- robochat 10y agoThanks for the link to the vision document. Even the fact that such a document exists does show that steps are already being taken to give D more direction. I'm not really a web developer, more of a data analyst with some web services. So the lack of SQL libraries is a disappointment.
- ognyankulev 10y agoRust: Promotes itself to be better C but its simply a more complex language design. huh? Rust tries to solve the real problem of shooting yourself in the foot in C without compromising on being as close as possible to bare metal. D is C++ but improved/simplified. Its not to hard to get into, its more easy for anybody from a C background. The main virtue of C++ is its vast legacy base that needs to be maintained. Replacing C++ with D can't possibly be for the reason of being "improved/simplified". Take it from a guy that spend a large part of his life in PHP. This explains a lot of the statements in the publication.
- kibwen 10y ago> This explains a lot of the statements in the publication. I hope we can avoid offhand judgments like this. As for the OP, and leaving aside the parts discussing other languages, this is a useful document for those outside the D community for summarizing some issues that may be apparent mostly to insiders. However, I think the author underestimates the amount of effort that it takes to develop and polish a complete and modern-feeling language/library/tooling ecosystem, especially for projects dependent on volunteer contributions (rare are the volunteers who sign up for grunt work, however essential that grunt work may be).
- qznc 10y ago> this is a useful document for those outside the D community for summarizing some issues that may be apparent mostly to insiders That is my fear. Some of the issues raised are non-issues, but as an outsider you cannot distinguish them. I envy Rust. Grunt work and PR seems go much smoother over there.
- ivanhoe 10y ago> Replacing C++ with D can't possibly be for the reason of being "improved/simplified". Author says exactly the same, don't try to replace C++, offer an alternative to C-like scripting languages. > This explains a lot of the statements in the publication. Is it really that easy for you to generalize about thousands of people all round the world? I know quite a few excellent engineers in my home town with background in various other languages (me included) who also happen to work mainly in php because when you live outside US it's much easier to find a well paid remote jobs in php then for instance in C++. Are we all ignorant fools not entitled to have an opinion on other languages because of it?
- qznc 10y agoThe title is very misleading. This is a rant by programmer about the current state of D. There is very little about the future of D and it is certainly nothing official like the Vision document [0] twice a year. [0] https://wiki.dlang.org/Vision/2016H2 https://wiki.dlang.org/Vision/2016H2
- skl0 10y agoAn official document that's just a wiki page that can fit almost entirely on a single page. That is nothing more than a very brief outline of what to accomplish with no real documentation of a plan to achieve listed goals. No surprise this list is so long: Other topics from H1 underwent only little development and will be copied as ongoing topics for H2: safety, memory management, tooling, improve language stability and specification, C++ and Objective C integration, library additions, smartphone support.
- kaoD 10y ago> Rust: [...] A over active amount of fans, that do not understand its complex. No. We understand it is complex. We also understand why: memory management is complex in and of itself, but RC/GC everything (or ad-hoc memory management) is the wrong approach for a systems language.
- qznc 10y ago> RC/GC everything (or ad-hoc memory management) is the wrong approach for a systems language D agrees with the "everything" part. D wants to give you options, so you can use GC/RC/manual where appropriate. Sadly, I have not found the time to wrestle with the Rust borrow checker myself. I still have doubts if it is worth it. For example, assume you write a graph data structure. To pass the lifetime analysis, you have to store the nodes in some background store vector. If you want to free/reuse memory of nodes, Rust essentially requires you to write a garbage collector for the nodes yourself. Afaik there are plans to add an optional GC to the standard library? So ultimately, D and Rust converge to the same point from different angles. Both want all the options. Rust started from safe manual and gains options. D started with safe automatic and gains safety for manual.
- kaoD 10y ago> D wants to give you options, so you can use GC/RC/manual where appropriate. Again, those options are what I listed as the wrong approaches. Manual = ad-hoc memory management. There's an additional option only present in Rust: automatic memory management via static analysis. Rust does not allow manual memory management at all unless writing unsafe code. Unlike Rust, D code with memory allocations is either GC'd or unsafe. Just to make it clear: the borrow and lifetime checkers are not manual memory management. Lifetimes are just hints for the compiler to do its automatic memory management at compile time. > ultimately, D and Rust converge to the same point Definitely not.
- qznc 10y ago> the borrow checker is not manual memory management Ok, we disagree on the terminology here. I would consider that manual, because it looks the same in C++. Rust only has the static analysis to weed out all the unsafe/broken code.
- verroq 10y ago>Go: Its is a "simple" language. But its forced restrictions at times are so annoying its saps all the fun out of the coding. Its not really C. Its more Basic on steroids. Unfortunately while Go has huge amount of traction and packages ( 70k from my count ), the quality is also... It has a few real gems those gems are a result of the mass amount of packages. It has its own market. A scripting replacement market mostly. lol no
- johnnydoebk 10y ago>> lol no That was my reaction as well. I'm surprised that this kind of "deep" analysis is on the front page.
- Bino 10y agoAs a language designer, I highly admire the design choices of D and happily copy them.
- WalterBright 10y agoYes, a lot of D's choices are finding their way into other languages :-)
- p0nce 10y agoNot sure why an overall rant post is given this visibility
- kevlar1818 10y agoIt's hard to take a post like this seriously when it uses such awful grammar and spelling.
- skl0 10y agoNot that difficult, you just have to understand english isn't everyone's first language. If you've ever taken the time to learn another language, you would have realized it is very difficult to do. Especially later in life. If a child as young as 11 was never exposed to language, they might never be capable of understanding it.
- flavoie 10y agoI don't understand why it's such a big deal with the GC. Ok if you want to build drivers or OSes related stuff. For AAA games, I can understand, but they will not switch to a new language as long as there is no engine like Unreal or Unity3D (GCed) that worth the switch. And the rest are indie and a GC will not affect performance. For web services, GUI application, the GC would be desirable because it will enable the developper to work on the business model and not the computer model and it will removed stupid memory management kind of bugs. Plus, 1200 fps vs 1120 fps is not faster since we can't see the difference. Is it that the D's GC is really slow or really memory inefficient?