Currently I have been learning D for about a year and a half. This may seem like a short time, but this is the longest I have stuck with any language. I have only been learning for 4 years and I am currently in university studying first year of computer systems engineering.

My main problem is that now I am looking for industry placements, it is clear that in this field C and C++ are highly desired. I have used C++ prior to discovering D, but much of my learning curve has occured while using D, and I feel quite comfortable using it. Using D makes me look back at what a great language it is compared to C++ (I know it can also be compared to C but I haven't used C).

So I don't want to go back. It isn't as if I have a career in C++ (like I know some people here have) and use D (only) for pleasure so I have no real knowledge of how things I write in D compare to what I would do in C++ (and none whatsoever for C).

Does anyone have any advice for me? Obviously I'm going to have to make this leap and the organizations will have their own ecosystem but while I'm learning how can I replace some of the great things about D? Things like built-in unittests, sane static if, painless CTFE, ranges, or even just the DUB package manager/build tool.

Failing that, think of this as another one of those 'D is great!' posts ;). And whatever happens, I'll certainly try and convince my host company to use it...

On Monday, 5 December 2016 at 17:18:25 UTC, e-y-e wrote:
> Currently I have been learning D for about a year and a half. This may seem like a short time, but this is the longest I have stuck with any language. I have only been learning for 4 years and I am currently in university studying first year of computer systems engineering.
>
> My main problem is that now I am looking for industry placements, it is clear that in this field C and C++ are highly desired. I have used C++ prior to discovering D, but much of my learning curve has occured while using D, and I feel quite comfortable using it. Using D makes me look back at what a great language it is compared to C++ (I know it can also be compared to C but I haven't used C).
>
> So I don't want to go back. It isn't as if I have a career in C++ (like I know some people here have) and use D (only) for pleasure so I have no real knowledge of how things I write in D compare to what I would do in C++ (and none whatsoever for C).
>
> Does anyone have any advice for me? Obviously I'm going to have to make this leap and the organizations will have their own ecosystem but while I'm learning how can I replace some of the great things about D? Things like built-in unittests, sane static if, painless CTFE, ranges, or even just the DUB package manager/build tool.
>
> Failing that, think of this as another one of those 'D is great!' posts ;). And whatever happens, I'll certainly try and convince my host company to use it...

I'm an academic, so no useful advice. I was reminded when reading your post of all the comments from Lisp, Scheme, Haskell, and [insert language] users that are able to choose their language for much of their job. Many use Lisp. Just not for production. An advantage of D is that you can mix C/C++ with D, so that increases the chance of using it.

Hi e-y-e,

The main problem with D for production is its runtime. GC, DRuntime, Phobos is big constraint for real world software production.

Good D code should be nothrow, @nogc, and betterC. BetterC means that it must not require DRuntime to link and to start. I started Mir as scientific/numeric project, but it is going to be a replacement for Phobos to use D instead/with of C/C++.

For example, Mir CPUID, Mir GLAS, Mir Random are nothrow @nogc and do not need DRuntime to start/link. (Mir Random is not tested for BetterC, so maybe few dependencies are exist.) Mir Random covers C++11 random number generation for example.

If D code can be compiled into a common C libraries like Mir libs, than you can include it into existing ecosystem. Currently it is possible only with LDC (requires some programming techniques for now).

I will be happy to see more Mir contributors [1]

Currently there are 5 Mir devs (not all are visible publicly).

[1] https://github.com/libmir

Cheers,
Ilya

On Monday, 5 December 2016 at 20:25:00 UTC, Ilya Yaroshenko wrote:
> Hi e-y-e,
>
> The main problem with D for production is its runtime. GC, DRuntime, Phobos is big constraint for real world software production.
>
> Good D code should be nothrow, @nogc, and betterC. BetterC means that it must not require DRuntime to link and to start. I started Mir as scientific/numeric project, but it is going to be a replacement for Phobos to use D instead/with of C/C++.
>
> For example, Mir CPUID, Mir GLAS, Mir Random are nothrow @nogc and do not need DRuntime to start/link. (Mir Random is not tested for BetterC, so maybe few dependencies are exist.) Mir Random covers C++11 random number generation for example.
>
> If D code can be compiled into a common C libraries like Mir libs, than you can include it into existing ecosystem. Currently it is possible only with LDC (requires some programming techniques for now).
>
> I will be happy to see more Mir contributors [1]
>
> Currently there are 5 Mir devs (not all are visible publicly).
>
> [1] https://github.com/libmir
>
> Cheers,
> Ilya

You know from the 15th December I will have a month of free time, and I would love to get myself up to speed with Mir to contribute to it. If you don't mind me saying, I think Mir could be one of the best things for the future of D (along with LDC) and I'd be glad to help it on its way.

On Monday, 5 December 2016 at 17:18:25 UTC, e-y-e wrote:
> Currently I have been learning D for about a year and a half. This may seem like a short time, but this is the longest I have stuck with any language. I have only been learning for 4 years and I am currently in university studying first year of computer systems engineering.
> ...
> Does anyone have any advice for me?

Honestly, I recommend just learning C and C++.  Especially C if you're into low level stuff.  You won't just broaden your job market, you'll learn stuff that will help you use D more effectively.  You don't have to think of it as "leaving" the language.

> how can I replace some of the great things about D? Things like built-in unittests, sane static if, painless CTFE, ranges, or even just the DUB package manager/build tool.

You'll have to learn to do without them :)

On Monday, 5 December 2016 at 20:49:50 UTC, e-y-e wrote:
> On Monday, 5 December 2016 at 20:25:00 UTC, Ilya Yaroshenko wrote:
>> [...]
>
> You know from the 15th December I will have a month of free time, and I would love to get myself up to speed with Mir to contribute to it. If you don't mind me saying, I think Mir could be one of the best things for the future of D (along with LDC) and I'd be glad to help it on its way.

That'd be great, drop in to our gitter some time https://gitter.im/libmir/public if you have any questions. The modules last updated before November are not very interesting at the moment. dcompute is, but is waiting on pulls for LDC.

On Monday, 5 December 2016 at 20:25:00 UTC, Ilya Yaroshenko wrote:
> Good D code should be nothrow, @nogc, and betterC. BetterC means that it must not require DRuntime to link and to start. I started Mir as scientific/numeric project, but it is going to be a replacement for Phobos to use D instead/with of C/C++.

Completly disagree. You're speaking about scientific projects, maybe.
Phobos/Druntime are pretty good for a lot of projects.

Andrea

On Tuesday, 6 December 2016 at 08:14:17 UTC, Andrea Fontana wrote:
> On Monday, 5 December 2016 at 20:25:00 UTC, Ilya Yaroshenko Phobos/Druntime are pretty good for a lot of projects.

In theory

On Monday, 5 December 2016 at 20:49:50 UTC, e-y-e wrote:
> On Monday, 5 December 2016 at 20:25:00 UTC, Ilya Yaroshenko wrote:
>> [...]
>
> You know from the 15th December I will have a month of free time, and I would love to get myself up to speed with Mir to contribute to it. If you don't mind me saying, I think Mir could be one of the best things for the future of D (along with LDC) and I'd be glad to help it on its way.

Awesome! The main directions are:
 1. stdC++ analogs implementation in betterC Dlang subset
 2. betterC analogs of existing Phobos modules. We can reuse DRuntime / Phobos code for initial commits.
 3. Various numeric / sci software.
 4. GPU algorithms. This require dcompute to be a part of LDC.

Thank you,
Ilya

On 12/6/16 3:28 AM, Ilya Yaroshenko wrote:
> On Tuesday, 6 December 2016 at 08:14:17 UTC, Andrea Fontana wrote:
>> On Monday, 5 December 2016 at 20:25:00 UTC, Ilya Yaroshenko
>> Phobos/Druntime are pretty good for a lot of projects.
>
> In theory

And what seem to be the issues in practice with code that is not highly specialized? -- Andrei