A Few thoughts on C, C++, and D

[aberba via Digitalmars-d]

On Monday, 29 May 2017 at 16:08:11 UTC, Russel Winder wrote:
> A few thoughts not entirely random but without a well thought 
> out storyline, prompted by a couple of recent threads here.
>
> I like the comment from DConf that D should be the successor to 
> Vala for writing GObject-based code. We have GtkD and in it 
> GStreamer. Writing programs in C with them is a real pain in 
> the a### and using C++ is only a little bit better. Having a 
> number of exemplar applications showing how good D is for this 
> sort of application would be a big win. I have been steeling 
> myself to rewrite Me TV in D for two years, but there is always 
> another problem that means leaving it in C++ is easier.
>
> GObject code requires RAII and C does not provide it. And the 
> C++ wrappers do a poor job because of all the dynamic runtime 
> behaviour the C++ wrapper model badly. D should be able to 
> cover this ground easily.
>
> My biggest problem of the moment is libdvbv5 and librtlsdr. 
> DStep seemingly cannot help as yet, and wrapping manually is a 
> pain, and there is no GIR files for these. Thus D is a non 
> starter whereas C++ can just use the C header files.  This 
> inability to get past the inertia is a huge barrier. Seriously, 
> I end up with C++ because the manual wrapping hill is too steep.
>
> And… if the application is written in C++ or C there might be 
> others willing to join in. As soon as the application is 
> written in D, there appears to be no audience of people willing 
> to get stuck in to help evolve the application. So here is the 
> real barrier: writing GtkD/GStreamerD applications is less 
> attractive because everyone in the universe expects such 
> applications to be written in C or C++.
>
> Each person trying to reach over the barrier tends to be an 
> island to themselves as no-one else seems to give a #### about 
> the problem that person is interested in.  The isolation of the 
> people trying to get D some traction is arguably the biggest 
> barrier to traction for D. It's the "no-one does it because 
> no-one does it" problem.
>
> If everyone in the D community got interested in and just 
> supplied moral support and advice for everyone else, even 
> though the application was uninteresting, there might be the 
> possibility of serious traction. Which then becomes a 
> self-fulfilling prophesy.
>
> In the mean time the Rust community are trying all of this sort 
> of marketing to try and prove to themselves they are actually 
> relevant and not a small clique. OK so they have some financial 
> support, but maybe that can be got round in the D community.

IMO,  the most important thing is getting the job done.  I don't 
want to write my own pdf generator,  my own web socket lib, json 
lib,... I just want to get my job done... Some languages are not 
fast,  nor offer control nor safe, ... they get jobs done for 
(most)  people. Plus their docs are good for figuring things out 
for (most)  people.


Majority of developers are probably web developers or 
library-consumers using other more technical devs work. Chasing 
after companies doesn't help. Its better to capitalise on D's 
productivity and make it easy to get things done (as a community).

It's individuals that come together to form companies that end up 
being aquired by bigger corps or distrubt the industry.