On Sunday, 3 January 2016 at 04:25:55 UTC, israel wrote:
> But maybe its just me, maybe im too young to know the olden days of the 80s/90s where C++ was a godsend compared to C. Or was it? I dont know, i wasnt alive...

C++ was hyped up in the press and commercial sector because it provided abstraction mechanisms on top of the existing C infrastructure. But most academics viewed C++ as an ugly hack back then, so it was no God send. Many programmers viewed it as bloated and inefficient, and it kinda was because compilers could not beat hand optimized C code (or: computers were too slow to make good compilers practical).  So C++ was more of an application level language than system level language.

That is still true, but today CPUs are fast, bottle necks are more in the memory system/multi threading, CPU internals are less transparent and programmers have less optimization skills... Which paves the way for high level programming languages like Swift.


Modern C++ is tolerable and fairly decent, but it will take a proficient programmer years to master. The big issue with C++ is that you also need to learn what _not_ to do, by trail and error...

C++ is not a language that one can reasonable select for a one-off project, it's a language for experts only. Unlike Python, Ruby, Swift or Go.

Maybe D2 is becoming a language for experts too at this point. A stronger focus on consistency and ergonomics would be beneficial.

On Sunday, 3 January 2016 at 09:55:14 UTC, Ola Fosheim Grøstad wrote:
> C++ was hyped up in the press and commercial sector because it provided abstraction mechanisms on top of the existing C infrastructure.

And just to give some context to this: in the 80s a large number of programmers were self-taught and had never been exposed to a disciplined language like Java as their first language, many started with BASIC and machine language. At best they had some experience with ad hoc structured programming in Pascal.

In the 80s it was not uncommon to implement applications or portions of applications in assembly, and CISC CPUs like motorola 68k had a rather high level instruction set so it wasn't as unpleasant as it sounds. One guy I knew implemented a full fledged BBS system (Amiga BBS) in assembly because he didn't know C and thought he might as well do it in machine language rather than learning C...

In that context C++/OOP provided a new market for educational books and magazine articles and lots of "propaganda". Which in turn made C++ fashionable... It created a sense of "you need to learn C++", yet in practice many just used it as C with inlining and overloading...

Hi,

I am looking to choose between D, Swift and Rust for a project that I am currently coding in C++. So far D seems the alternative but I guess I won't know until I try out a few things.

Is this the right forum to ask questions or should questions be sent to another forum?

Regards
Dibyendu

On Sunday, 3 January 2016 at 15:38:18 UTC, Dibyendu Majumdar wrote:
> Hi,
>
> I am looking to choose between D, Swift and Rust for a project that I am currently coding in C++. So far D seems the alternative but I guess I won't know until I try out a few things.
>
> Is this the right forum to ask questions or should questions be sent to another forum?
>
> Regards
> Dibyendu

Specific questions about how to program in D belong in the "Learn" forum: http://forum.dlang.org/group/learn

On Sunday, 3 January 2016 at 15:38:18 UTC, Dibyendu Majumdar wrote:
>
> I am looking to choose between D, Swift and Rust for a project that I am currently coding in C++. So far D seems the alternative but I guess I won't know until I try out a few things.

Why I now choose D, even for commercial jobs...

C++ had been my primary language (personally and professionally) for 20 years, and it was effective and enjoyable for me.  But, I was naive.  I didn't realize that what made it enjoyable for me, is that I always used effective and complete frameworks/toolsets (IBM VisualAgeC++ on OS/2, BeOS standard API, Qt on everything) with effective base classes and data structures that all worked together.  When forced out of my comfortable space, by a project a couple years ago that allowed no dependencies on Qt, I discovered the grief of C++.

So, time to give D a try.  I'd watched it through the tumultuous years, and saw that it had settled down. I like the pedegree of D - a pragmatic approach from a creator of a commercial C++ compiler.  Also, I was encouraged to see Alexander jump in to contribute to D (even before the D foundation announcement), as he's been tirelessly working to improve C++ over the years.

I, like you, wanted to "try out a few things" before committing to D on commercial effort. I found myself fantastically productive (more than C++, even with Qt) using rdmd to begin script-like and refactor as it grew. Easy, like Python that produces fast compiled single executables that are easy to deploy (even to folks without a Python development environment installed), especially with the 'import' feature to embed external resources.  It is so easy to keep unit tests current and running, and so easy to see testing code coverage, that I felt always safe refactoring.  I appreciate the ability to mark any scope @safe, and have the compiler keep me honest.

And I found myself using more "esoteric" features that were a pain in C++.  I loved the concept of meta-programming in C++, but always found myself using features in my framework - which had taken the great pains to provide the necessary functionality.  I found implementing threads and concurrency in D every bit as simple and safe as Qt.

Admittedly, GUI stuff in D is a mixed bag.  I've settled on creating D console applications that transmits json data, via stdin/stdout, directly into Qt base model classes so the rest of the Qt framework works seamlessly.  I quite like the solution, and I'm actually glad there was no "standard" gui interface that bound me.  But, gtk and sdl bindings seemed to work easy enough for simple things, and dlanggui is looking promising.

As for future commercial efforts, I'll continue with D.  I feel safe that straight C is relatively easy to integrate.  Having access to proven libs like sqlite, redis, libgit2, nanomsg makes little incentive to ever feel like replacing them.  Even many of the interesting Python libs are just linked to a standard C lib underneath.

Anyway, I'm just more productive at producing robust, fast code in D.
Best of luck in your efforts.

On Saturday, 2 January 2016 at 11:31:24 UTC, Dibyendu Majumdar wrote:
> * Do D compilers generate more efficient code compared to C++ compilers? Are there performance benchmarks comparing D implementation against C and C++?
>
> * Can D generics do everything C++ templates can (are they Turing complete for instance) - and what additional capabilities does D have that would make a significant difference to the way templates are used in C++?
>
> * How does D's performance compare with Java when it comes to concurrent applications or garbage collection?
>
> * How stable is D? Can one use it without fear that the next version will significantly change the language and therefore one would have to rewrite?
>
> I feel that the D website could do more to explain why someone should move from C++ or Java to D - and this has to be explained in terms of real world benefits in terms of:
>
> * Performance
> * Quality of implementation
>
> For someone like me - cool language features don't count that much unless they lead to real world benefits.
>
> My post here was triggered after watching a video by Andrei where he talked about how D generics are different from C++ templates - I think stuff like that needs to be explained in the front page of D website.
>
> Regards
> Dibyendu
>
> http://ravilang.org
> http://simpledbm.org

>Are there performance benchmarks comparing D
> implementation against C and C++?

C style D code will run the same as C style C++ code and a C style C code because they all compile to the same machine code. There will be differences if you use higher level language features, but then you are trading performance for convenience and its up to you to decide if that trade off is worth it.

Also keep in mind that D compilers do not apply all possible optimisation and your code next year my become faster.

> * How does D's performance compare with Java when it comes to concurrent applications or garbage collection?

In this world there are two options:
1. You build language around GC sacrificing flexibility and performance if you dont use GC.
2. Or you add simple GC.

D went with second option. D`s GC will never be as good as Java, C# or GO because it requires language change, but D can be used without GC and reach C level of performance.



You asked a lot about language performance, but application performance is mostly dependant on code you write and not the language you use. Benchmarking and tuning your code will give way more performance than changing languages.

On Sunday, 3 January 2016 at 18:39:21 UTC, Shannon wrote:
> On Sunday, 3 January 2016 at 15:38:18 UTC, Dibyendu Majumdar wrote:
>>
>> I am looking to choose between D, Swift and Rust for a project that I am currently coding in C++. So far D seems the alternative but I guess I won't know until I try out a few things.
>
> Why I now choose D, even for commercial jobs...
>
Nice story; mind if we put it on the user narratives wiki page?

-Wyatt