On Wednesday, 30 September 2015 at 09:49:34 UTC, rumbu wrote:
> Or when mscoff32 libs will be included in setup.

Said to be in 2.068.1: https://issues.dlang.org/show_bug.cgi?id=13889

On Tuesday, 29 September 2015 at 17:33:04 UTC, Chris wrote:
> This is not my impression. Even "geeks" don't touch D (I know this from personal experience), even when there's no risk involved, e.g. when writing a small internal tool. As soon as they hear they have to learn about ranges and map!(a => to!string(a)) and the like, they lose interest. Fear or plain laziness ("couldn't be ar*sed"), one of the two. "I certainly won't learn D" is a comment I've heard myself.

But that does what is happening here, when people who have invested time in D complain. Also generators, iterators and functional style programming (D ranges) is something many languages provide one way or the other. In my experience that is of limited use and more often than not explicit loops are more transparent and maintainable. Although if a language offers comprehensions I use those.

And yes, I know what Phobos offers and how people who publish Phobos-centric code write their D code. There is nothing particularly surprising about Phobos.

>> Projecting "fear" onto professional decision making is just a way to make excuses for D's shortcomings.
>
> The shortcomings D has wouldn't even interest the majority of those who reject D. They wouldn't get deep enough in their daily tasks to find out.

Then we perceive reality quite differently. What I see is that people do try D, like qualities like syntactical familiarity and flexibility and then get disappointed. So basically people play with D, realize it is not where they expect it to be at, leave, then some time later they download D again, same shortcomings, leave... etc. Then at some point they share their frustration.

> You've said it again. Java's design is orthodox, so IBM embraced it. Again, people prefer simple set menus, rules and strict guidelines. It's more of a psychological thing than objective risk aversion.

D isn't particularly novel either, lots of Simula67/C++ influence, so I don't really see how this works. IBM did it for competitive reasons.

> One example that come immediately to mind is data processing in Python. A lot of it is parsing and counting which is much faster and often easier to do in D/Phobos.

D can work as a replacement solution for parts of Python's domain. IMO Python "replaced/complemented" sed/awk/perl/bash/php/etc, so that would be a rather small portion of Python usage. And that is the primary reason for Python's adoption, I think, it replaced not a single tool, but people got to use one tool instead of multiple tools.

> I think it is. It took me a while to realize this. Why is there this passionate hostility towards D? I don't go to a Go or Rust forum to tell them that I don't like this or that feature and that it's all crap. I've decided they're not the right tools for what I need and that's it.

Ok, but this is actual D users complaining, not Go and Rust users.

The reason is much more likely that the expectations are set at a level where D does not deliver. If you want a production environment to be judged favourably it is a good idea to set the expectations one notch below what you deliver. There is a bit too much hubris in how D is portrayed and therefore you get a backlash, from actual D users.

People also complain in Go fora, and certainly in C++ fora (lots of sulking over accumulated syntax bloat), but with Go they know that the language is set in stone because the language designers are very clear in their communication. So the complaints is more along the lines of "Go is kinda boring, but I can use it for XYZ, then use other languages for W".

In Rust the moderation is quite harsh and the language is also too new for users to "give up" on it.

On Tuesday, 29 September 2015 at 22:05:48 UTC, rumbu wrote:
> The original OP complained about compiler error messages and the lack of a true IDE, these are not "qualities" of a system level programming language, I see them as basic failures.

Yes, sure, but people looking for a system level language don't have much to choose from so IDE is not a big issue.

Comparisons to C# comes up regularly. My point is more that there is no way D can compete with projects that are good fit for C#. A the D project should be up front about that.

> My main complaints are also the compiler error messages ("Out of memory" is the most annoying one) and the Linux-centric approach of the development, but I'm far from being disgruntled.

Ok. I didn't mean to address you specifically. Sorry if you read it that way.

Certainly the complaints coming from D end users is rooted in realties coming from the D project itself. Whether it is quality problems or communication problems, one just cannot blame the end users that express the issues they experience like several people in the D community does. That kind of denial is toxic.

I don't think a full IDE experience is essential, but a comparable debugging experience probably is.

On Wednesday, 30 September 2015 at 09:16:44 UTC, Kagamin wrote:
> On Tuesday, 29 September 2015 at 05:52:13 UTC, Ola Fosheim Grøstad wrote:
>> D2 does not solve C++'s issues
>
> Heartbleed?

C++ offers optional bounds checks + static analysis tools.

On Wednesday, 30 September 2015 at 07:44:09 UTC, Laeeth Isharc wrote:
> On Tuesday, 29 September 2015 at 16:19:19 UTC, Ola Fosheim Grøstad wrote:
>> On Tuesday, 29 September 2015 at 15:31:30 UTC, Laeeth Isharc wrote:
>>> We know that you think D is a toy language, although you also say that you aren't calling it a toy language.
>>
>> That's a rather manipulative assertion.
>
> That's a statement about intent that is based on a poor reading.  And my statement - whatever you may perceive its intent to be - is based purely on what you have said (both that D is a toy language - in your view this being an entirely factual assertion - and that you are not calling D a toy language).
>
> http://forum.dlang.org/search?q=ola+toy&scope=forum

I am tired of your manipulative mind games.

From http://forum.dlang.org/post/amosmrxatnkntpgsjpqz@forum.dlang.org :

«I said "if D is a toy language". That is not calling it anything. But it is, like Rust, a toy language by academic use of the phrase which is not a pejorative term, but an affectionate term in my book. The pejorative term is to call a language a "hack". C++ is a hack. String mixins is a hack. Etc.»

On Wednesday, 30 September 2015 at 12:43:10 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 30 September 2015 at 09:16:44 UTC, Kagamin wrote:
>> On Tuesday, 29 September 2015 at 05:52:13 UTC, Ola Fosheim Grøstad wrote:
>>> D2 does not solve C++'s issues
>>
>> Heartbleed?
>
> C++ offers optional bounds checks + static analysis tools.

C++ offers hidden features, D solves the issue :)

>  working as advertised



libucrtd.lib is still sought and not found after another new release.
you guys should get your shit together, otherwise more people that try D will "Moving back to .NET" and not tell you about it.

well i guess i leave now too, since i don't have the time and patience to wait any longer for the compiler to work.

sincerely yours

On Wednesday, 30 September 2015 at 09:49:34 UTC, rumbu wrote:
> I would believe that when core.sys.windows will have the same amount of code like core.sys.posix after the default installation.

I'm unbelievably close to that now, I just have a million other things to do (...including adding Linux headers that are missing from druntime too. it is less Linux- or Windows- centric and more "the smallest amount of work the core devs can possibly do that is useful"- centric)

> Or when mscoff32 libs will be included in setup.

dmd -m32mscoff generates those files and links with the Microsoft linker. It just works when I try it on my computer (which already has VS installed btw).

> Or when the libs from windows\lib will not have a content from 15 years ago.

I might change that too though I'm not in as much of a rush since the 32mscoff and 64 don't use them anyway; they use the up-to-date MS sdks.

On Wednesday, 30 September 2015 at 15:45:02 UTC, learn wrote:
>>  working as advertised
>
>
>
> libucrtd.lib is still sought and not found after another new release.
> you guys should get your shit together, otherwise more people that try D will "Moving back to .NET" and not tell you about it.
>
> well i guess i leave now too, since i don't have the time and patience to wait any longer for the compiler to work.
>
> sincerely yours

what is libucrtd.lib? what kind of application/library were you trying to build?

i just wanted to see if i can use dmd without any problems with windows 10. downloaded it, installed it and everything just worked fine.

On Wednesday, 30 September 2015 at 17:12:37 UTC, Mengu wrote:
> On Wednesday, 30 September 2015 at 15:45:02 UTC, learn wrote:
>>>  working as advertised
>>
>>
>>
>> libucrtd.lib is still sought and not found after another new release.
>> you guys should get your shit together, otherwise more people that try D will "Moving back to .NET" and not tell you about it.
>>
>> well i guess i leave now too, since i don't have the time and patience to wait any longer for the compiler to work.
>>
>> sincerely yours
>
> what is libucrtd.lib? what kind of application/library were you trying to build?
>
> i just wanted to see if i can use dmd without any problems with windows 10. downloaded it, installed it and everything just worked fine.

please see "new release doesn't work as advertised" of august 13, 2015.

(x64)
Building Debug\ConsoleApp1.exe...
LINK : fatal error LNK1104: cannot open file 'libucrtd.lib'
Building Debug\ConsoleApp1.exe failed!

win10 - vs2015