December 23, 2017 Re: Maybe D is right about GC after all ! | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dan Partelly | On Saturday, 23 December 2017 at 09:23:22 UTC, Dan Partelly wrote: > You could name it Deimos. That name's already taken: https://github.com/D-Programming-Deimos/ Deimos is a repository of D language bindings to many existing libraries, though sadly it doesn't appear to get much maintenance. Personally, I think the C language bindings that currently exist in the D runtime should be moved to Deimos and privately imported by the ports that need it. But, I seem to be in the minority on that. Mike |
December 23, 2017 Re: Maybe D is right about GC after all ! | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Saturday, 23 December 2017 at 09:10:25 UTC, Walter Bright wrote: > On 12/22/2017 7:23 AM, Russel Winder wrote: >> I think we are now in a world where Rust is the zero cost abstraction >> language to replace C and C++, except for those who are determined to >> stay with C++ and evolve it. > > Maybe it is. But that is not because D isn't up to the task. I've converted a large program from C to D (Digital Mars C++'s front end) with -betterC and it really is a zero cost abstraction. The memory safety benefits are there (DIP 1000), RAII is there, nested functions, array bounds checking, template metaprogramming, CTFE, etc. Is it planned to add more (I'm thinking of exceptions, which I guess means classes too) of full D into betterC? As I wrote earlier, it should be possible to achieve some rough kind of feature parity with modern C++. I really do like Rust; I think it's a brilliant language. There are domains that require zero cost abstractions that are currently NOT covered well by Rust though; D's Mir library is pushing into one of those. > D as betterC really is a game changer, for anyone who cares to give it a try. Yes, it really is. I really wish that D had a performant fully precise GC, but I'm beginning to think that is unlikely to ever happen. Maybe being a betterModernC++ in that regard would be good enough? |
December 24, 2017 Re: Maybe D is right about GC after all ! | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dan Partelly Attachments:
| On Fri, 2017-12-22 at 16:17 +0000, Dan Partelly via Digitalmars-d wrote: > […] > Why should we settle for this ? D code (efortless) is easier to > read then Rust. I assume this to be true for a lot of programmers […] And for many Rust is easier to read than D. -- Russel. =========================================== Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk |
December 24, 2017 Re: Maybe D is right about GC after all ! | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dylan Graham Attachments:
| On Sat, 2017-12-23 at 01:12 +0000, Dylan Graham via Digitalmars-d wrote: > […] > I wish D would stop bending over backwards to appease C/C++ programmers. I think D would have more success branding itself as a general purpose language and letting itself become the language it should be, not the language some C++ programmer wants but is never going to use anyway. A point worth reiterating. -- Russel. =========================================== Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk |
December 24, 2017 Re: Maybe D is right about GC after all ! | ||||
---|---|---|---|---|
| ||||
Posted in reply to ketmar Attachments:
| On Sat, 2017-12-23 at 11:33 +0200, ketmar via Digitalmars-d wrote: > Russel Winder wrote: > > > I think we are now in a world where Rust is the zero cost > > abstraction > > language to replace C and C++, except for those who are determined > > to > > stay with C++ and evolve it. > > sorry, but it is not zero cost. we have alot of C and C++ code. > converting > it to Rust is not zero cost at all. and using it as-is won't make > our > codebases any better. I think we are using different meanings of "zero cost abstraction". […] > > what i want to say (and didn't, as usual) is that Rust is not zero > cost due > to exisiting codebases. either you have to invest alot of time and > efforts > to port those codebases, or you have to use both Rust and C/C++, and > suffer > the consequences. Porting code and "zero cost abstraction" are totally separate things, there is no causal relation between them. > […] > > that is, D actually has *no* competitors. if not google and mozco, > people > won't even start talking seriously about Go/Rust. yet even in this > unfair > race, D presence is constantly growing. just wait a little, and > you'll see > a dawn of Rust and Go. and D will be still there, standing strong > and > proud. ;-) Programming language traction is only partly related to any technical arguments. Hugely important is resource and marketing. C++ has Intel and others. Rust has Mozilla and others. Go has Google and others. -- Russel. =========================================== Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk |
December 24, 2017 Re: Maybe D is right about GC after all ! | ||||
---|---|---|---|---|
| ||||
Posted in reply to John Gabriele | On Friday, 22 December 2017 at 18:59:34 UTC, John Gabriele wrote:
> I'm new to D. Coming primarily from Python these days, I'm looking at D not as a better C++ (haven't used that in many years), but as a better Python.
If the world views D as a better [insert programming language] the marketing battle has been lost. We need the world to view D as a convenient way to do [insert some task]. It doesn't even have to be the "best" way to do it, just a convenient way.
Claiming to be a better version of some other language is worse than no marketing at all. D's "we're a better C++" version of marketing is the reason I avoided the language for years. You have to like C++ a lot to want an even better version of C++, and that definitely doesn't describe me, and given C++'s reputation, I'm probably not alone.
|
December 24, 2017 Re: Maybe D is right about GC after all ! | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dan Partelly | On 2017-12-23 09:15, Dan Partelly wrote: > Ironically, D is so close to beeing the language a C++ programmer would > really use that you can smell it. It doesnt have to bend, since it got > so close with a lot of good decisions. That's because it already has bent over backwards several times to get to the current state. -betterC, C++ ABI compatibility and so on. -- /Jacob Carlborg |
December 24, 2017 Re: Maybe D is right about GC after all ! | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dan Partelly | On Saturday, 23 December 2017 at 08:15:04 UTC, Dan Partelly wrote:
> On Saturday, 23 December 2017 at 01:12:53 UTC, Dylan Graham wrote:
>> language it should be, not the language some C++ programmer wants but is never going to use anyway.
>
> Ironically, D is so close to beeing the language a C++ programmer would really use that you can smell it. It doesnt have to bend, since it got so close with a lot of good decisions. D is the first language Im aware of which has the potential to satisfy the needs of a very large portion of the market,
How much further does D have to go to start snatching C++'s userbase?
In my honest opinion, D doesn't offer as much of an advantage over C++ as it does C# and Java. Currently D has much better template syntax, modules (although that idea is being floated in the C++ community), but what else? The C++ juggernaut keeps piling on new features every 3 years. It's hard for D to stay in the lead (that is if it is).
I've been writing a voxel engine in C#. Writing anything high performance in C# becomes non-idiomatic, you're locked into OOP and performance sucks.
D offers far more features C# and Java. As a result, I think D would have a greater appeal on those audiences.
For example, writing vector structs in C# requires you to duplicate the code for each size of the vector and then again for each type. You can cut down on the type duplications by using the dynamic keyword but that infers a performance hit. On the flip side, D's metaprogramming reduces the complexity of writing such utilities.
Furthermore, C# and Java deeply emphasise the OOP paradigm. They're not very expressive languages. D can do everything C#'s OOP can do and offers many other paradigms. D is more a toolbox to let you program the way you want. C++ is much the same, just uglier. Thus, there's going to be less draw to D from C++.
I also recall someone saying that C++'s memory problem is fixed. D's MMM seems infantile in comparison.
Also, there is not much in the way of getting around C#'s GC. Well, you can. But it gets ugly and unidiomatic. You also have to consult the documentation frequently to know what certain allocates. In D you can receive warnings about what allocates GC memory (compiler flag -- can't remember which one (-vgc on DMD?)) and also enforce non-gc allocations. It also lets me use other memory management techniques if need be.
I think D should try to advertise to more restrictive languages such as C# and Java and present itself as a general purpose language. I think it will draw more people from the C#/Java crowd than it will from the C++ crowd.
|
December 24, 2017 Re: Maybe D is right about GC after all ! | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dylan Graham | On Sunday, 24 December 2017 at 15:00:09 UTC, Dylan Graham wrote: > On Saturday, 23 December 2017 at 08:15:04 UTC, Dan Partelly wrote: >> On Saturday, 23 December 2017 at 01:12:53 UTC, Dylan Graham wrote: >>> language it should be, not the language some C++ programmer wants but is never going to use anyway. >> >> Ironically, D is so close to beeing the language a C++ programmer would really use that you can smell it. It doesnt have to bend, since it got so close with a lot of good decisions. D is the first language Im aware of which has the potential to satisfy the needs of a very large portion of the market, > > How much further does D have to go to start snatching C++'s userbase? > > In my honest opinion, D doesn't offer as much of an advantage over C++ as it does C# and Java. Currently D has much better template syntax, modules (although that idea is being floated in the C++ community), but what else? The C++ juggernaut keeps piling on new features every 3 years. It's hard for D to stay in the lead (that is if it is). That's the biggest problem with C++, they pile on relentlessly half baked feature after half baked feature in a big dump that no one with a life can ever grasp. > > I've been writing a voxel engine in C#. Writing anything high performance in C# becomes non-idiomatic, you're locked into OOP and performance sucks. > > D offers far more features C# and Java. As a result, I think D would have a greater appeal on those audiences. The big issues with Java and C# are the required infrastructure for deployment. They could be the best languages since sliced bread, they would still be annoying to deploy as the runtime is an emulator. I ported 1 app from Java to D. It was so unspectacular (or better said it was spectacularly easy) that you're probably right. Reaching to Java devs is a good idea. The advantage of Java though, is not the language but the huge, huge, huge existing libraries and packages and know how. This will be difficult to overcome for any language. |
December 24, 2017 Re: Maybe D is right about GC after all ! | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dylan Graham | Programming languages are tools for solving problems, and people face different problems and they also have different capabilities and tastes, which means even for people facing identical problems, the right tool for the job may not be the same because they aren't identical as groups and as individuals. Languages are also about much more than syntax; they are also about communities, ecosystems, and values. In the beginning people generally join a community because they admire the values and capabilities of those prominent in the community. Prestige often has a lot to do with that. How does prestige develop? From tangible consequences produced by able and virtuous people acting together to create something. There's a long lead time on that one, but it's not something that can be rushed. It's also hard to begin something - much energy poured in for no tangible result. You love your creation, but for a long time indeed it does not love you back. However once it ignites then things take on a momentum of their own. It's almost impossible to believe because you're expecting it to be difficult, like usual, and somehow things just almost magically start to unfold in that direction without your having to do that much. On Sunday, 24 December 2017 at 15:00:09 UTC, Dylan Graham wrote: > How much further does D have to go to start snatching C++'s userbase? That's already happening, surely. Here there are lots of former C++ programmers, or professional C++ programmers who write D on the side. Andy Smith gave a talk about use of D in the automated trading systems at a financial company - I won't say who it is, but it's a very well-known firm that's well established and in the top handful of hedge funds. We're a newer fund (established in 2014, we were the largest Asian hedge fund startup), but we're starting to explore the use of D, and one project where we are moving to D was originally written in C++. It forms the basis of our analytics across the firm. And I didn't need to sell it because when someone is suffering they are looking for salvation, which is what D represents. Before, we had C++ analytics (and for each one the implementation and a header file). Then a C++ to C# shim. Then a C# to C++ low-level shim. Then a high level C# wrapper. Then an Excel function wrapper written in C#. Now you want me to add a new function??? And a new trader starts who would like to access the analytics from Python. Oh, and it would also be nice to have the analytics accessible from R, Java, Julia and Matlab. Conceptually, there are other ways to get to the same result. But practically for us we decided to rewrite the analytics in D and generate code at compile-time to wrap the functions to make them accessible from other languages (for native code ABI, with other language wrapping being generated at a combination of compile and run-time). It's by far a cleaner and easier-to-read solution. And it doesn't need selling to anyone, because it's an upfront cost that pays dividends for years not just on current code but all the new code that will be written in time. D has unit-testing and documentation generation built in, and as far as the community goes, there's an expectation that you use these! Wrapping for Excel is largely done (excel-d) and I've got something basic that can be used for Java if you are relaxed about efficiency (which we mostly are for that use case). We're working on C#. For Python we could easily use PyD (which we have now fixed to work also on 64 bit Windows), but we will try going via generating Cython as it's a bit cleaner. There's still more work to do, but it's a much better solution. And I think that's how D will be adopted. People who have problems, for which using D is in part the solution. And decision-makers who are acting as principals not agents, so that they can act without having to spend a huge investment on addressing social factors (there are always social factors, but it's a matter of proportion). Liran at Weka didn't have to ask someone to decide to use a new language he had never used before for a startup building complex code that had to just work. He had earned the right to decide, and there's plenty of risk in a startup anyway, and I suppose his investors trusted his judgment. Similarly, Remedy Games had a problem, and from his account of it, Manu was not entirely serious when he suggested why don't we use D for scripting, but the group was receptive, and they didn't need to make a presentation to the board to act. Andy Smith was in a position where he could 'build a prototype' in D, and then decide it wasn't necessary after all to rewrite in C++. Of course recognition that D can be helpful won't happen all by itself. It's worth doing the work to spread awareness, as we are. But if people agree, then I think talking about success stories, warts and all, is likely to be quite persuasive. And also to explain how to address the difficulties of relatively early adoption (Manu talked about documentation, training materials and so on). > The C++ juggernaut keeps piling on new features every 3 years. It's hard for D to stay in the lead (that is if it is). Then why do C++ programmers here say D has ruined them for C++. Piling on features and never refactoring,redesigning, or removing old functionality - what does that lead to in an application? And it's not better in a programming language. > I've been writing a voxel engine in C#. Writing anything high performance in C# becomes non-idiomatic, you're locked into OOP and performance sucks. > Furthermore, C# and Java deeply emphasise the OOP paradigm. They're not very expressive languages. D can do everything C#'s OOP can do and offers many other paradigms. D is more a toolbox to let you program the way you want. C++ is much the same, just uglier. Thus, there's going to be less draw to D from C++. And OO has other difficulties in terms of readability and fragmentation of the code. The banana/gorilla/jungle problem described by Joe Armstrong. > D offers far more features C# and Java. As a result, I think D would have a greater appeal on those audiences. It's not a quantity of features thing though, is it? People don't like Apple products because they have more features (even when they do). It's because of good design, and that's something you can copy but that it is difficult to do in a dynamic sense. > I think D should try to advertise to more restrictive languages such as C# and Java and present itself as a general purpose language. I think it will draw more people from the C#/Java crowd than it will from the C++ crowd. Facebook say 'code wins arguments'. So it's much better to write a blog post and say other people should do more along these lines than just argue for it. And concrete and vivid examples might be more persuasive (though complementary to technical arguments). |
Copyright © 1999-2021 by the D Language Foundation