Moving back to .NET

[Laeeth Isharc via Digitalmars-d]

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.