ACCU 2013 and D

[Paulo Pinto]

Am 20.01.2013 10:15, schrieb Russel Winder:
> As some of you know, the C User Group UK and the European C and C++ User
> Group long ago merged to create the Association of C and C++ Users
> (ACCU). Over the years, the emphasis on C and C++ gave way to a more
> diverse approach including patterns, Java, Python, Go, agile processes.
> Even the name of the group formally changed to ACCU to lose the direct C
> and C++ link. Due to the history, members of the group had and retain
> roles with the British Standards Institute, as the UK representatives on
> the C and C++ standards committees, especially the C++ one. When it is
> the UK's turn to host a C++ standards committee meeting, the meeting is
> either before or after the ACCU conference, and the obvious suspects get
> drafted in to do keynotes and other talks at the conference, as well as
> ACCU members attending the open meetings of JTC1/SC22/WG21.
> http://accu.org/index.php/conferences/accu_conference_2013
>
> This seems like an ideal opportunity to do a lightning talk (5 mins) on
> why C++ is crap and D is the only native code language that should be
> used. (I have a history in this group of bashing C++ :-) It would be
> really helpful to create a few one liners (with code examples) as to why
> D is the clear language of choice for native code working and, C++, Go,
> Rust, Clay, etc. should be consigned to the dustbin of history. People
> will expect me to emphasize concurrency and parallelism issues so it
> would be good to throw others into the mix as well.
>
> Thanks in advance for any input. Attribution of sources if appropriate
> will be given unless people prefer anonymity!
>

Modules already here. C++ might get them, if ever, around 2020. Who
knows how the computing landscape will look then.

Compile time meta-programming via use of templates and mixins.

C++ has lots of nice features, however with the increasing size of the 
standard, I doubt anyone will be able to understand it past the planned 
C++17 revision.

And the most dear to my heart, C's legacy just opens the door to 
security exploits by design, which force you to rely on third-party 
tools to assess that you not doing any buffer overrun, strange pointer 
manipulation and so on.

As for arguments against the other languages you pointed out.

Beating on Go is kind of easy, due to the stubbornness of the language 
designers to leave certain common features out, like the ever recurring
discussion on generics that even I take part in go-nuts.

Plus showing that certain Go PR features are actually also available in 
D, like actors having a similar role to channels, strides, fast 
compilation times.

Actually I kind of like Rust, since I am a big ML fan. They just should
give up on their Perlisms for pointer definitions. And the language is 
not yet fully defined.

I would rephrase the "clear language of choice for native code working" 
to "clear language of choice for system native code working", because 
almost any mainstream static type language also has native code 
compilers available.

--
Paulo