The issue with D...

[Ben]

> but building with 'dub --arch=x86_mscoff' (dmd -m32mscoff) 
> indeed should make dmd use lld if VS isn't available if it's 
> not the case right now.

1. Does not work:

> Running .\vibeApp.exe
> Program exited with code -1073741515

2. And "dub --arch=x86_mscoff" this is expected to be know to new 
users?

> You can also set the default architecture to x86_64 for all dub 
> projects as described here. .... "defaultArchitecture": 
> "x86_64",

Does not work as dub simply ignore this and gives the same linker 
error. Because the Windows DMD version is 32bit. So we get 64Bit 
DMD on 64bit Unix platforms, but getting 32Bit DMD on a 64Bit 
Windows platform. Makes sense to me.

> Just use the Microsoft linker by passing: -a=x86_mscoff when 
> building using dub.

See above. Does not work

> The linker is already shipped with DMD.

Only works with DMD directly. Dub acts like a inconsistent piece 
of software that does not know what its parent ( the compiler ) 
is capable of doing.

> You can install VC++ for 1.5 GB using the Build Tool install.

You are right, my numbers are wrong.

Visual Studio Build Tools 2017 -- 15.9.6
Option Selected: Visual C++ build tools ( default options are W10 
SDK, Visual C++ Tools, Test tools )

Total Space required: 4.58GB

Its 1.5GB more then stated i stated before. The 3GB must have 
been from the last time i installed 2015 version. My bad... Only 
4.6GB to install a advised linker.

/Offtopic: And the whole argument about how HD space is cheap, is 
the same click bait nonsense as why we end up with 20GB operating 
system, eating 3GB of ram by default, browsers eating gigs for 
simply display text, Electron ...

Sure, one thing is nothing but when you start stacking up all the 
moronic "just buy more ram or ssd space or ..." arguments, its 
pushing the issue of developer incompetence and laziness unto the 
end users. And we end up with the PCs experience feeling slower 
then in the past. As CPU and memory gains can not keep up with 
the wast full development.

> This user experience will attract  a lot of new users.

Not when Dub by default does not work properly on Windows. The 
fact that we are having a discussion about this, means its not 
user friendly to the point that getting a simple HTTP Server 
going, is a struggle.

Any discussion regarding adding build arguments, is a instant "no 
fly zone" for most new users. Its like talking to grandfathers, 
sorry, but us millenniums are "spoiled little brats" that have 
dozens of programming languages available on our fingertips and 
we can not be bothered wasting hours, days, weeks trying to 
figure out arcane design decisions. The moment you need more then 
simple run or build, your already losing to a whole series of 
language competitors who got their shit together.

Its not because a lot of people here have years of experience 
build up and know most compiler arguments like some ancient Jedi 
scriptures, that its a good things. Any basic business manager 
that is half competent can tell you this.

> Have you even been on the front page? Literally the first 
> example I was met with:

1. That is a ... Tatum ... LINUX EXAMPLE, so its already not 
platform agnostic path.
2. You think that running a hashbang example is a good 
introduction to end users?
3. People lean the wrong way and are bypassing the dub package 
manager

Let me compare to a few languages:

Go: import ( "net/http" ) ...

Ready, set, go ...

Crystal: require "http/server"

Ready, set, go ...

D: Learn package manager ( no example on the front page )
    Figure out why the package manager does not work on Platform W
D: Use example from the front page, that does not work on 
specific supported platform W
    Example that is also the "wrong" way to run D projects in the 
future.

I am not here to fight over what is right or wrong. From the 
looks people are already set in their ways with years of 
experience. This is my personal experience with D and the issue 
points that the language has. Its like a billionaire not 
understanding why people simply do not get a loan during the 
shutdown.

And here is another fun one:

> C:\Users\Ben\AppData\Local\dub\packages\vibe-d-0.8.4\vibe-d\mongodb\vibe\db\mongo\settings.d(16,8): Deprecation: alias `std.digest.digest.toHexString` is deprecated - import std.digest instead of std.digest.digest. std.digest.digest will be removed in 2.084
> dmd --version
> DMD32 D Compiler v2.084.0

What is wrong here? :)

Not counting the dozens of warnings that show up when trying to 
compile Vibe.D from deprecated functions. I call this a very bad 
introduction in a project but that is Vibe.d its issue, not D as 
a language but people will not differ.

The fact that we have a warning informing us that this deprecated 
and will be gone in 2.084 but DMD is 2.084.

And all these posts later and vibe.d is still as dead in the 
water as it was before. Experience: C-

My advice: Simply dump DMD Windows because if you can not support 
it to work correctly, then do not support it at all.