On Monday, 21 September 2015 at 18:33:39 UTC, deadalnix wrote:
> https://issues.dlang.org/show_bug.cgi?id=14885

This was recently fixed this week:
http://arsdnet.net/this-week-in-d/sep-20.html

https://github.com/D-Programming-Language/druntime/pull/1354

> https://issues.dlang.org/show_bug.cgi?id=10679

I don't think this one is valid though maybe I'm wrong. But the instruction pointer would be on the next instruction.

On Sunday, 20 September 2015 at 17:32:53 UTC, Adam wrote:
> My experiences with D recently have not been fun.
> ...
> My main concern with .NET is portability and performance. I am going to give in to the portability and just assume Mono is good enough. Performance wise, I'd prefer D, but .NET is performant enough for most apps. Maybe in a few years things will change, I can't wait that long. Sorry guys! (not that you will miss me)

OK, the frustration is understandable. D is good enough to impress in short-run but has problems damaging itself in the long run. This leads to impression -> frustration cycle.

However, one point regarding portability. It is wrong to target cross - platform project by *assuming* that Mono is good enough. Either you need portability and you care what Mono does, or you don't. But then it is irrelevant what happens in Linux.

By the way, it seems you started from .Net from the very beginning. It is unclear why you considered D in such circumstances (of course, except portability, but it seems you actually don't need it).

Last point. You mentioned performance. Did you run benchmarks?

On Monday, 21 September 2015 at 19:15:28 UTC, Maxim Fomin wrote:
> On Sunday, 20 September 2015 at 17:32:53 UTC, Adam wrote:
>> My experiences with D recently have not been fun.

>> My main concern with .NET is portability and performance. I am going to give in to the portability and just assume Mono is good enough. Performance wise, I'd prefer D, but .NET is performant enough for most apps. Maybe in a few years things will change, I can't wait that long. Sorry guys! (not that you will miss me)
>
> OK, the frustration is understandable. D is good enough to impress in short-run but has problems damaging itself in the long run. This leads to impression -> frustration cycle.

Well, that may or may not be true.  But someone who finds the error messages offputting isn't a good exemplar of putative deficiencies that show up in the long run, because these are part of the initial learning curve and after a year or two or experience it's really unlikely to be a main factor in determining choice of framework.  Whereas it's understandable that in the beginning it can be a big source of frustration.  And if you leave the Microsoft ecosystem, I am not sure that D fares so badly in relation to a certain C family language that has had a big influence.

He didn't say how long he had been using D for, but as others point out one underestimates how much one knows in relation to existing languages, and forgets that it is a degree of work over months and years to learn something new...

A better example of long run deficiencies might be the guy here who tried to use D at work for embedded systems, which involved making his own runtime etc, and who gave up, at least for a while, in frustration.  On the other hand, it's always tough to try to be the first to do something, especially when your career is at stake.

> Either you need portability and you care what Mono does, or you don't.
Commercial decisions are often a matter of tradeoffs.  Eg for internal enterprise software you might find it valuable to be able to run on both linux and windows, but you can always make it a service on windows if linux is too much trouble.

On Mon, 21 Sep 2015 19:07:32 +0000, Adam D. Ruppe wrote:

>> https://issues.dlang.org/show_bug.cgi?id=10679
> 
> I don't think this one is valid though maybe I'm wrong. But the instruction pointer would be on the next instruction.

You are correct and I realized this later on and 'fixed' it in druntime: https://github.com/D-Programming-Language/druntime/ commit/8822115bc8d52fa61c15cef38fe77349f18747b9. I will close this now.

On Tuesday, 22 September 2015 at 06:03:25 UTC, Laeeth Isharc wrote:
> On Monday, 21 September 2015 at 19:15:28 UTC, Maxim Fomin wrote:
>
>> OK, the frustration is understandable. D is good enough to impress in short-run but has problems damaging itself in the long run. This leads to impression -> frustration cycle.
>
> Well, that may or may not be true.  But someone who finds the error messages offputting isn't a good exemplar of putative deficiencies that show up in the long run, because these are part of the initial learning curve and after a year or two or experience it's really unlikely to be a main factor in determining choice of framework.  Whereas it's understandable that in the beginning it can be a big source of frustration.

I do not consider error messages as long run issue (it is discussed in the thread and I didn't mentioned it, so it might caused impression that I agree with complains about error messages).

> And if you leave the Microsoft ecosystem, I am not sure that D fares so badly in relation to a certain C family language that has had a big influence.

If Microsoft ecosystem is left out then my opinion regarding comparison with Microsoft system is obviously irrelevant. Comparing with other languages I found D is decently good.

>
> He didn't say how long he had been using D for, but as others point out one underestimates how much one knows in relation to existing languages, and forgets that it is a degree of work over months and years to learn something new...

I always could not understand complaints regarding D hard learning curve for anyone with C/C++/C# background.

>
>> Either you need portability and you care what Mono does, or you don't.
> Commercial decisions are often a matter of tradeoffs.  Eg for internal enterprise software you might find it valuable to be able to run on both linux and windows, but you can always make it a service on windows if linux is too much trouble.

Sounds like 'lazy' portability: if app is portable - than good, if not - ok, we can leave with it:)

On Sunday, 20 September 2015 at 17:32:53 UTC, Adam wrote:

> It's almost exclusively due to the error messages and IDE. I know many here will write off such complaints, So be it.
>

The thing is that a lot of people who use D don't mind the lack of IDE support. One reason is that D doesn't need it as badly as e.g. Java or C++. Once you are comfortable with the idea of component programming, there's less need for an IDE. I don't know about .NET, but Java programs consist usually of classes that are somehow interwoven. In D you'd go for independent components that you can later stick together like Lego. I usually write new components as tiny projects with unit tests etc., and plug them into the big project once I'm happy with them. In this way, you don't work on the big project all the time, mostly on small components you add to the big project later.

> Remember, no reason to have the sharpest sword if you can't wield it.

Another reason is that for D programmers the power of D outweighs the lack of IDE support. While you may have an easy life with IDE-languages like Java or C#, the frustration of not being able to do certain things, to be confined by committee decisions etc., is worse in the long run. So D people prefer to learn how to wield the sharpest sword, although it may take some time. It's like everything in life, really, if you take the hard way, you'll get more out of it in the long run.

So don't give up. Maybe D will come to the rescue one day, when you hit a brick wall with .NET ;)

PS As to error messages, you'll soon know the "usual suspects".

On Tuesday, 22 September 2015 at 11:01:28 UTC, Chris wrote:
>
> to be confined by committee decisions etc.,

D has committee (Walter & Andrei). Some of their decisions frustrate D users too.

On Tuesday, 22 September 2015 at 11:44:35 UTC, Maxim Fomin wrote:
> On Tuesday, 22 September 2015 at 11:01:28 UTC, Chris wrote:
>>
>> to be confined by committee decisions etc.,
>
> D has committee (Walter & Andrei). Some of their decisions frustrate D users too.

Sure, but in many cases D allows you to work around decisions you don't like. Plus, you can actively contribute, make suggestions and prove your case. The length of some threads shows that Walter, Andrei and others involved in the development take input seriously and answer questions and give the reasons for their decisions.

That a language needs people who make the final decision about something is necessary. That these decisions are not always to everyone's liking is inevitable. Given the contradictory nature of requirements in programming, it's only logical that one cannot cater for both sides all the time. D has a long list of requested features that actually made it into the language quite fast, unlike other languages that beat about the bush for years, before they finally incorporate something users really do want. So the general approach is sound, however, due to a lack of resources, not all is well, e.g. PRs stay in the pipe too long. But as I said before, it's only from D that users expect perfection, other languages are accepted as they are, warts and all.

On Tuesday, 22 September 2015 at 13:38:33 UTC, Chris wrote:
> too long. But as I said before, it's only from D that users expect perfection, other languages are accepted as they are, warts and all.

I don't think that is true. It has been common among C++ users to build custom libraries with very little use of the standard library. C++ has never been accepted with warts and all. It is just C++ was the only option next to C, so people have rolled their own _gradually_ moving from C towards the C++ feature set.

Like, I wrote my own array reference library in the spring, but I am now replacing it with a C++17 prototype array_view since an implementation is available from Microsoft now.

What has made C and C++ tolerable is that they are very adaptable languages with very few deliberate constraints and runtime requirements.  A problem for D today is that D1 was originally deliberately constrained, which made perfect sense when the language was small (just like it makes sense for Go today).  But D2 is deliberately open, yet D2 has added features without redefining the core language from D1 first. It is possible to fix it, by defining a minimal D language and move everything else to libraries, but not without breaking backwards compatibility.

C/C++ are stuck in the 70s as far as memory goes, but D is still undecided. Leaving the field totally open for Rust who is moving quite fast AFAICT.

On Tuesday, 22 September 2015 at 14:46:30 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 22 September 2015 at 13:38:33 UTC, Chris wrote:
>> too long. But as I said before, it's only from D that users expect perfection, other languages are accepted as they are, warts and all.
>
> I don't think that is true.

I do, because every other (new) language is embraced as _the_ way to go, while in the D community even minor issues are blown out of proportion.

>  A problem for D today is that D1 was originally deliberately constrained, which made perfect sense when the language was small (just like it makes sense for Go today).  But D2 is deliberately open, yet D2 has added features without redefining the core language from D1 first. It is possible to fix it, by defining a minimal D language and move everything else to libraries, but not without breaking backwards compatibility.

Then we need a transition strategy. I wouldn't mind refactoring my code in order to adapt it to changes that are for the better in the long run. However, I wouldn't want it to happen in a sudden way that would render all my code useless. Nobody would accept this.