On Tuesday, 12 May 2015 at 18:35:10 UTC, FujiBar wrote:
> "Wikipedia tells us that there were a lot of other attempts besides D to kill C++ - for example Vala, Cyclone, Limbo, BitC. How many of you have even heard of these languages?"

I've heard of every one except Limbo.

> Walter would probably violently disagree with the "no decent development tools" assessment. But I got to say that people used to Visual Studio and XCode (like myself) not being impressed  by D's 1980s-style bare basic command line tools is not surprising.

I program in D in Visual Studio and it's fine, I like the experience more than doing C++ in VS. Because the support for C++ in VS was always a meh, not comparable to C#, for example. Only if you use a special third-party tool like Visual Assist X you get some real benefits and only then you start to miss them in VisualD.


> I think an IDE, one could call it "DCode" (great name, isn't it?), which integrates all the available tools and provides a modern graphical interface to them would do wonders.

Have you actually tried Mono-D and VisualD?

On Tuesday, 12 May 2015 at 22:57:32 UTC, Max Klyga wrote:
> On 2015-05-12 20:02:05 +0000, Brian Schott said:
>
>> On Tuesday, 12 May 2015 at 18:35:10 UTC, FujiBar wrote:
>>> "But there are no vacancies..."
>> 
>> There's at least one:
>> https://emsi.bamboohr.com/jobs/view.php?id=30
>
> https://arex.recruiterbox.com/jobs/fk0hjlh/

As long as Walter and Andrei keep the D ecosystem stable and streamlined, new jobs should keep popping up...

On 5/12/15 3:57 PM, Max Klyga wrote:
> On 2015-05-12 20:02:05 +0000, Brian Schott said:
>
>> On Tuesday, 12 May 2015 at 18:35:10 UTC, FujiBar wrote:
>>> "But there are no vacancies..."
>>
>> There's at least one:
>> https://emsi.bamboohr.com/jobs/view.php?id=30
>
> https://arex.recruiterbox.com/jobs/fk0hjlh/

Should we put together a page of "D job openings" on the wiki? -- Andrei

On 12/05/15 21:35, FujiBar wrote:

> Walter would probably violently disagree with the "no decent development
> tools" assessment. But I got to say that people used to Visual Studio
> and XCode (like myself) not being impressed  by D's 1980s-style bare
> basic command line tools is not surprising.
I don't think the command line aspect of things is justified. With that said, C++ has some really good cross referencing tools (e.g. in eclipse) that D not only does not match, but with CTFE, I do not see how it /can/ match. I actually miss those occasionally.

What bothers me most about D, however, is that the toolchain itself isn't there to pick up its share of the load. Transitioning between versions of the compiler requires a task with several days' worth of work behind it, and getting the code to compile on both dmd and gdc is a full time task for someone here. With DMD's optimizer not worth much, this is a real issue.

And this is before mentioning stability. I've lost count of the number of times my compilation failed with an assert thrown by dmd, and just last week I've had to refactor the code around a consistent segmentation fault by the compiler when trying to compile it. It got better for it, but ideally I'd like to refactor my code because I want to, not because the compiler crashes unless I do so.

Shachar

On Wednesday, 13 May 2015 at 05:13:55 UTC, Shachar Shemesh wrote:
> On 12/05/15 21:35, FujiBar wrote:
>
>> Walter would probably violently disagree with the "no decent development
>> tools" assessment. But I got to say that people used to Visual Studio
>> and XCode (like myself) not being impressed  by D's 1980s-style bare
>> basic command line tools is not surprising.
> I don't think the command line aspect of things is justified. With that said, C++ has some really good cross referencing tools (e.g. in eclipse) that D not only does not match, but with CTFE, I do not see how it /can/ match. I actually miss those occasionally.
>
> What bothers me most about D, however, is that the toolchain itself isn't there to pick up its share of the load. Transitioning between versions of the compiler requires a task with several days' worth of work behind it, and getting the code to compile on both dmd and gdc is a full time task for someone here. With DMD's optimizer not worth much, this is a real issue.
>
> And this is before mentioning stability. I've lost count of the number of times my compilation failed with an assert thrown by dmd, and just last week I've had to refactor the code around a consistent segmentation fault by the compiler when trying to compile it. It got better for it, but ideally I'd like to refactor my code because I want to, not because the compiler crashes unless I do so.
>
> Shachar

Interesting. Since >= DMD 2.05x I haven't had any real stability problems with each new release.

Each release still breaks my code in some way because each new compiler version improves on the last and detects latent bugs in my code.

My only concern now with a new release is the compiler's memory usage growing.

bye,
lobo

On 5/12/2015 10:13 PM, Shachar Shemesh wrote:
> And this is before mentioning stability. I've lost count of the number of times
> my compilation failed with an assert thrown by dmd, and just last week I've had
> to refactor the code around a consistent segmentation fault by the compiler when
> trying to compile it. It got better for it, but ideally I'd like to refactor my
> code because I want to, not because the compiler crashes unless I do so.

Have bugzilla reports been filed for these?

I totally agree

On Wednesday, 13 May 2015 at 05:05:54 UTC, Andrei Alexandrescu wrote:
> On 5/12/15 3:57 PM, Max Klyga wrote:
>> On 2015-05-12 20:02:05 +0000, Brian Schott said:
>>
>>> On Tuesday, 12 May 2015 at 18:35:10 UTC, FujiBar wrote:
>>>> "But there are no vacancies..."
>>>
>>> There's at least one:
>>> https://emsi.bamboohr.com/jobs/view.php?id=30
>>
>> https://arex.recruiterbox.com/jobs/fk0hjlh/
>
> Should we put together a page of "D job openings" on the wiki? -- Andrei

On 13/05/15 08:48, Walter Bright wrote:
> On 5/12/2015 10:13 PM, Shachar Shemesh wrote:
>> And this is before mentioning stability. I've lost count of the number
>> of times
>> my compilation failed with an assert thrown by dmd, and just last week
>> I've had
>> to refactor the code around a consistent segmentation fault by the
>> compiler when
>> trying to compile it. It got better for it, but ideally I'd like to
>> refactor my
>> code because I want to, not because the compiler crashes unless I do so.
>
> Have bugzilla reports been filed for these?
>

Not yet. I saved the git tag in which this happens and will try to isolate.

Shachar

On Wednesday, 13 May 2015 at 03:30:53 UTC, thedeemon wrote:
> On Tuesday, 12 May 2015 at 18:35:10 UTC, FujiBar wrote:
>> "Wikipedia tells us that there were a lot of other attempts besides D to kill C++ - for example Vala, Cyclone, Limbo, BitC. How many of you have even heard of these languages?"
>
> I've heard of every one except Limbo.
>

Maybe you know Go?

Limbo was Inferno's programming language, Plan 9's successor, where two of Go main creators were involved.

Go is at its core a merge between Limbo and Oberon-2 method declaration syntax.

http://www.vitanuova.com/inferno/docs.html

"You are making a cool project and we'd like to contribute to it, but we don't know and neither feel like studying this silly D".

This is indeed a problem for many newly created languages. Scala has somewhat managed to create its own eco system with Akka, Spark, Spray in a specialized area like concurrent programming and big data. Also because Scala has found some liking in academical circles (e.g. Spark, Scala STM). I don't know how things will look like for Kotlin. Maybe there will be a niche for Android development. For Groovy there is basically only Grails as a killer application.

For company internal development those languages might find some aficionados, but for open-source development exactly that "but we don't know and neither feel like studying" argument pops up. The rise of Scala started with Akka. Go has CSP-style concurrency as a killer feature (10k problem solved out of the box, much simpler concurrency). Rust fixes the problem with manual memory management being error prone. So you need some killer argument/feature/application. Otherwise you always face this counter argument.