www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - The issue with D...

reply Ben <benny.luypaert rhysoft.com> writes:
Not to be a downer but just trying out D again with Vibe.d and 
getting confronted with the typical bug: Unexpected OPTLINK 
Termination at EIP=0040F60A

Tracing this back, bring up issues in the bugtracker from 2017 ( 
17508 ), that is still open.

First impressions and such matter. And for some reason ever new 
"first impression" with D seems to result in annoying bugs being 
discovered ( Windows 10 ).

Yes, i already know. No Visual Studio linker installed ( and no, 
i do not want a 3GB installation just for the linker, when DMD 
already includes it ). But somebody forgot to tell dub!

So anybody using Vibe.d or any other project that rely on dub 
figuring out that DMD can be run without Visual Studios linker, 
can enjoy very nice and cryptic errors. User friendly it is not.

/Frustrated that this is still a issue.
Feb 01
next sibling parent reply evilrat <evilrat666 gmail.com> writes:
On Saturday, 2 February 2019 at 02:32:28 UTC, Ben wrote:
 Not to be a downer but just trying out D again with Vibe.d and 
 getting confronted with the typical bug: Unexpected OPTLINK 
 Termination at EIP=0040F60A
 ...
 Yes, i already know. No Visual Studio linker installed ( and 
 no, i do not want a 3GB installation just for the linker, when 
 DMD already includes it ). But somebody forgot to tell dub!
 ...
This isn't dub or D problem, normally dub shouldn't know about linker, so you can set compiler flag to tell which linker to use(if there is such for dmd...) from dub project. The actual problem in this case is DMD defaulting to old object file format/pipeline, 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. Because even if you tell dmd -m32 to use lld it probably won't work because it produce stuff for OPTLINK for that target. There is rumors about making the COFF default format when all major issues with lld will be ironed out.
Feb 01
parent reply Ben <benny.luypaert rhysoft.com> writes:
 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\mon
o\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.
Feb 04
next sibling parent Andre Pany <andre s-e-a-p.de> writes:
On Monday, 4 February 2019 at 23:28:51 UTC, Ben wrote:
 [...]
1. Does not work:
 [...]
2. And "dub --arch=x86_mscoff" this is expected to be know to new users? [...]
There are several points addressed in you post. 1) Please provide a reproducible example for Program exited with code -1073741515 2) My expectation is, x86_mscoff will become the default for 32 Bit dmd, while x86_64 will become the default for 64 bit dmd. Hopefully this year. The hard work of some fantastic people made this possible. 3) Setting default architecture in dub settings file should work and can be overwritten with command line arg --arch. If it is not working please provide details. 4) vibe-d example is working fine on my windows computer. The shebang line is just ignored. But you are right, it should be removed. If it is not working please provide details. 5) The warning for mongodb is already fixed (https://github.com/vibe-d/vibe.d/commit/07599b09b5d0404d7dc64db4696c722ec637db77#diff-a8cdd5513604e73687c443113cd17a9b) Kind regards André
Feb 04
prev sibling next sibling parent reply Laurent =?UTF-8?B?VHLDqWd1aWVy?= <laurent.treguier.sink gmail.com> writes:
On Monday, 4 February 2019 at 23:28:51 UTC, Ben wrote:
 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 ...
My 2 cents: The comparison cith Go holds, but comparing D with Crystal is invalid if you are talking about Windows issues; since Crystal isn't natively available on Windows.
Feb 05
parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Tuesday, 5 February 2019 at 10:47:36 UTC, Laurent Tréguier 
wrote:
 On Monday, 4 February 2019 at 23:28:51 UTC, Ben wrote:
 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 ...
My 2 cents: The comparison cith Go holds, but comparing D with Crystal is invalid if you are talking about Windows issues; since Crystal isn't natively available on Windows.
Indeed, but the problem remains. Using D for server and GUI development should appear easy and natural. The current vibe.d examples isn't conveying that, with all its "black magic" comments. Contrarily to what D's "leadership" thinks, D has the potential to become a very good competitor to Go and Crystal for server development, as both of them are also performant garbage collected languages. And with dlangui, developing connected desktop application is a real pleasure. D should be promoted for what it does best, and should how complex application can be made easily and efficiently with simple code.
Feb 07
parent reply Andre Pany <andre s-e-a-p.de> writes:
On Thursday, 7 February 2019 at 08:26:50 UTC, Ecstatic Coder 
wrote:
 On Tuesday, 5 February 2019 at 10:47:36 UTC, Laurent Tréguier 
 wrote:
 On Monday, 4 February 2019 at 23:28:51 UTC, Ben wrote:
 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 ...
My 2 cents: The comparison cith Go holds, but comparing D with Crystal is invalid if you are talking about Windows issues; since Crystal isn't natively available on Windows.
Indeed, but the problem remains. Using D for server and GUI development should appear easy and natural. The current vibe.d examples isn't conveying that, with all its "black magic" comments. Contrarily to what D's "leadership" thinks, D has the potential to become a very good competitor to Go and Crystal for server development, as both of them are also performant garbage collected languages. And with dlangui, developing connected desktop application is a real pleasure. D should be promoted for what it does best, and should how complex application can be made easily and efficiently with simple code.
From your post I am not sure whether you know the purpose of the comments in the vibe.d example. The dub.sdl comment is a dub single package descriptor. You can save the lines to a file example.d and run it with command: dub example.d With latest dub you can even save the file without the extension .d and if you are on a Linux system you can execute it just with command: ./example. That this the purpose of the shebang line. I would not describe it as black magic but as very convenient way of calling D coding. Vibe.d does here a very good job and just leverage features of posix os and features of the dub package manager. Kind regards Andre
Feb 07
parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Thursday, 7 February 2019 at 11:51:37 UTC, Andre Pany wrote:
 On Thursday, 7 February 2019 at 08:26:50 UTC, Ecstatic Coder 
 wrote:
 On Tuesday, 5 February 2019 at 10:47:36 UTC, Laurent Tréguier 
 wrote:
 On Monday, 4 February 2019 at 23:28:51 UTC, Ben wrote:
 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 ...
My 2 cents: The comparison cith Go holds, but comparing D with Crystal is invalid if you are talking about Windows issues; since Crystal isn't natively available on Windows.
Indeed, but the problem remains. Using D for server and GUI development should appear easy and natural. The current vibe.d examples isn't conveying that, with all its "black magic" comments. Contrarily to what D's "leadership" thinks, D has the potential to become a very good competitor to Go and Crystal for server development, as both of them are also performant garbage collected languages. And with dlangui, developing connected desktop application is a real pleasure. D should be promoted for what it does best, and should how complex application can be made easily and efficiently with simple code.
From your post I am not sure whether you know the purpose of the comments in the vibe.d example. The dub.sdl comment is a dub single package descriptor. You can save the lines to a file example.d and run it with command: dub example.d With latest dub you can even save the file without the extension .d and if you are on a Linux system you can execute it just with command: ./example. That this the purpose of the shebang line. I would not describe it as black magic but as very convenient way of calling D coding. Vibe.d does here a very good job and just leverage features of posix os and features of the dub package manager. Kind regards Andre
Don't get me wrong. I'm not saying that including dub commands into D source code can't be convenient. I'm just saying that when you show only one example on the landing page of a programming language, it'd better be crystal clear. Or people will see this "complication" as the norm with this language. It's just a matter of public perception. As you know, I'm personally in favor of showing **THREE** **SIMPLE** **USEFUL** examples : 1. how to declare/initialize/process an array and read/write/split/replace stuff in a text file 2. how to make a "hello world" http web server 3. how to open a window, enter some text, and say "hello xxx" when you push a "hello" button Simple, easy and concise code. I'm VERY happy there is a web server example on D's landing page. I mean it. But removing this sort of "garbage" comment, as useful as it is, would probably make the example more pleasant to read for people evaluating the interest of using D for their next personal/professionnal project...
Feb 07
parent reply Seb <seb wilzba.ch> writes:
On Thursday, 7 February 2019 at 18:18:16 UTC, Ecstatic Coder 
wrote:
 Simple, easy and concise code.

 I'm VERY happy there is a web server example on D's landing 
 page. I mean it.

 But removing this sort of "garbage" comment, as useful as it 
 is, would probably make the example more pleasant to read for 
 people evaluating the interest of using D for their next 
 personal/professionnal project...
Do you mind if I ask how the current example is dark magic for you? How would you/we make it better?
Feb 07
parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Thursday, 7 February 2019 at 20:22:17 UTC, Seb wrote:
 On Thursday, 7 February 2019 at 18:18:16 UTC, Ecstatic Coder 
 wrote:
 Simple, easy and concise code.

 I'm VERY happy there is a web server example on D's landing 
 page. I mean it.

 But removing this sort of "garbage" comment, as useful as it 
 is, would probably make the example more pleasant to read for 
 people evaluating the interest of using D for their next 
 personal/professionnal project...
Do you mind if I ask how the current example is dark magic for you? How would you/we make it better?
Stupid simple : void main() { import vibe.d; listenHTTP(":8080", (req, res) { res.writeBody("Hello, World: " ~ req.path); }); runApplication(); } Not stupid simple : #!/usr/bin/env dub /+ dub.sdl: name "hello_vibed" dependency "vibe-d" version="~>0.8.0" +/ void main() { import vibe.d; listenHTTP(":8080", (req, res) { res.writeBody("Hello, World: " ~ req.path); }); runApplication(); } It's just pure cosmetics. But as with everything, "how it looks" is something that matter. If I arrive at a professional IT appointment with my customer with a three day beard and my jogging clothes, he won't judge me the same as if I'm shaved and with my suit and tie. When you are evaluating a programming language, the first lines of code you see give you a good or bad impression about it. And in all matters it's always better to give a good impression from the start. I guess some people are very fond of cryptic languages with esoteric syntaxes, etc. But honestly I'm not sure it's the norm, and that most people dislike simple, crystal clear code.
Feb 07
parent reply Jordan Wilson <wilsonjord gmail.com> writes:
On Thursday, 7 February 2019 at 20:49:31 UTC, Ecstatic Coder 
wrote:
 On Thursday, 7 February 2019 at 20:22:17 UTC, Seb wrote:
 On Thursday, 7 February 2019 at 18:18:16 UTC, Ecstatic Coder 
 wrote:
 [...]
Do you mind if I ask how the current example is dark magic for you? How would you/we make it better?
Stupid simple : void main() { import vibe.d; listenHTTP(":8080", (req, res) { res.writeBody("Hello, World: " ~ req.path); }); runApplication(); } Not stupid simple : #!/usr/bin/env dub /+ dub.sdl: name "hello_vibed" dependency "vibe-d" version="~>0.8.0" +/ void main() { import vibe.d; listenHTTP(":8080", (req, res) { res.writeBody("Hello, World: " ~ req.path); }); runApplication(); } It's just pure cosmetics. But as with everything, "how it looks" is something that matter. If I arrive at a professional IT appointment with my customer with a three day beard and my jogging clothes, he won't judge me the same as if I'm shaved and with my suit and tie. When you are evaluating a programming language, the first lines of code you see give you a good or bad impression about it. And in all matters it's always better to give a good impression from the start. I guess some people are very fond of cryptic languages with esoteric syntaxes, etc. But honestly I'm not sure it's the norm, and that most people dislike simple, crystal clear code.
Is it pure cosmetics? I thought the whole point of the dub comment was so that you could just run "dub server.d" and it would just work? In your super simple example, it won't just work, you need to do to the whole dub fetch/build thing. Not saying it's a bad thing, but we are talking about first impressions, and I can see pros/cons to both approaches. Jordan
Feb 07
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Feb 07, 2019 at 09:27:47PM +0000, Jordan Wilson via Digitalmars-d wrote:
 On Thursday, 7 February 2019 at 20:49:31 UTC, Ecstatic Coder wrote:
[...]
 Stupid simple :
 
 void main()
 {
     import vibe.d;
     listenHTTP(":8080", (req, res) {
         res.writeBody("Hello, World: " ~ req.path);
     });
     runApplication();
 }
 
 Not stupid simple :
 
 #!/usr/bin/env dub
 /+ dub.sdl:
 name "hello_vibed"
 dependency "vibe-d" version="~>0.8.0"
 +/
 void main()
 {
     import vibe.d;
     listenHTTP(":8080", (req, res) {
         res.writeBody("Hello, World: " ~ req.path);
     });
     runApplication();
 }
[...]
 Is it pure cosmetics? I thought the whole point of the dub comment was
 so that you could just run "dub server.d" and it would just work?
 
 In your super simple example, it won't just work, you need to do to
 the whole dub fetch/build thing. Not saying it's a bad thing, but we
 are talking about first impressions, and I can see pros/cons to both
 approaches.
[...] I think his point is that whatever effect is triggered by the dub comment should be made the *default* behaviour, such that you don't need to type out any of it explicitly and the compiler/toolchain/whatever will just Do It(tm), whatever It may be. The current default is that it will not work if the dub comment isn't there. His argument is that this default should be changed so that it *does* work. In theory, dub "should" be able to detect the "import vibe.d" line and from there figure out what to do "automatically". I'm unsure whether I agree with him, though. In order to pull this off, dub will have to implement heuristics for detecting VibeD imports and somehow map that to the requisite vibe-d dependency declaration. I'm uncertain I'm entirely comfortable with this kind of IMO hackish implementation that may end up interacting badly with other things once you get beyond trivial projects. But regardless, he certainly has a point in making things work out-of-the-box with minimal effort, even if we may disagree on just how minimal this minimal effort should be. Not everyone is a masochistic programmer like myself who would shun such niceties and prefer manually compiling and linking stuff on the command-line. (This is why it'd probably be a bad idea to put me on the marketing / UI design team. :-P) T -- Those who don't understand Unix are condemned to reinvent it, poorly.
Feb 07
next sibling parent Jordan Wilson <wilsonjord gmail.com> writes:
On Thursday, 7 February 2019 at 21:47:07 UTC, H. S. Teoh wrote:
 On Thu, Feb 07, 2019 at 09:27:47PM +0000, Jordan Wilson via 
 Digitalmars-d wrote:
 [...]
[...]
 [...]
[...]
 [...]
[...] I think his point is that whatever effect is triggered by the dub comment should be made the *default* behaviour, such that you don't need to type out any of it explicitly and the compiler/toolchain/whatever will just Do It(tm), whatever It may be. The current default is that it will not work if the dub comment isn't there. His argument is that this default should be changed so that it *does* work. In theory, dub "should" be able to detect the "import vibe.d" line and from there figure out what to do "automatically". I'm unsure whether I agree with him, though. In order to pull this off, dub will have to implement heuristics for detecting VibeD imports and somehow map that to the requisite vibe-d dependency declaration. I'm uncertain I'm entirely comfortable with this kind of IMO hackish implementation that may end up interacting badly with other things once you get beyond trivial projects. But regardless, he certainly has a point in making things work out-of-the-box with minimal effort, even if we may disagree on just how minimal this minimal effort should be. Not everyone is a masochistic programmer like myself who would shun such niceties and prefer manually compiling and linking stuff on the command-line. (This is why it'd probably be a bad idea to put me on the marketing / UI design team. :-P) T
Ah I see. I pretty much started using dub because I was sick of manually dealing with includes/libs from within my previous IDE, and thought the ability to simply put dependency "vibe-d" version="~>0.8.4" in my project and be done was great; the thought of even more automagic convenience didn't even occur to me! Jordan
Feb 07
prev sibling parent Wyatt <wyatt.epp gmail.com> writes:
On Thursday, 7 February 2019 at 21:47:07 UTC, H. S. Teoh wrote:
 I think his point is that whatever effect is triggered by the 
 dub comment should be made the *default* behaviour
I'm pretty sure it's just that it looks messy because of the dub stuff (which isn't _strictly_ necessary). I honestly kind of agree. Sure, removing it would remove your ability to just paste it in a file and run it, but... do people actually do that? I wonder if it'd be helped by putting a comment explaining the top matter? Or link to a "runnable" version? -Wyatt
Feb 07
prev sibling parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Thursday, 7 February 2019 at 21:27:47 UTC, Jordan Wilson wrote:
 On Thursday, 7 February 2019 at 20:49:31 UTC, Ecstatic Coder 
 wrote:
 On Thursday, 7 February 2019 at 20:22:17 UTC, Seb wrote:
 On Thursday, 7 February 2019 at 18:18:16 UTC, Ecstatic Coder 
 wrote:
 [...]
Do you mind if I ask how the current example is dark magic for you? How would you/we make it better?
Stupid simple : void main() { import vibe.d; listenHTTP(":8080", (req, res) { res.writeBody("Hello, World: " ~ req.path); }); runApplication(); } Not stupid simple : #!/usr/bin/env dub /+ dub.sdl: name "hello_vibed" dependency "vibe-d" version="~>0.8.0" +/ void main() { import vibe.d; listenHTTP(":8080", (req, res) { res.writeBody("Hello, World: " ~ req.path); }); runApplication(); } It's just pure cosmetics. But as with everything, "how it looks" is something that matter. If I arrive at a professional IT appointment with my customer with a three day beard and my jogging clothes, he won't judge me the same as if I'm shaved and with my suit and tie. When you are evaluating a programming language, the first lines of code you see give you a good or bad impression about it. And in all matters it's always better to give a good impression from the start. I guess some people are very fond of cryptic languages with esoteric syntaxes, etc. But honestly I'm not sure it's the norm, and that most people dislike simple, crystal clear code.
Is it pure cosmetics? I thought the whole point of the dub comment was so that you could just run "dub server.d" and it would just work? In your super simple example, it won't just work, you need to do to the whole dub fetch/build thing. Not saying it's a bad thing, but we are talking about first impressions, and I can see pros/cons to both approaches. Jordan
I agree. I've already had this discussion about that same http stuff being installed by default in Go and Crystal, but not in D, despite D already has support by default for json, sqlite, etc. And very honestly, preinstalling dlangui to allow people to immediately start developing connected applications (like in Python and Red) after the DMD installation could also help D become by far the best alternative to both Go and Python. But I know this won't happen, because D's leadership, instead of focusing on D's strengths, tries for a decade to compete with C/C++ (low level no-GC languages), and clearly not Go, Python, etc (high-level languages for web/gui/scripting). Just my two cents...
Feb 08
next sibling parent reply JN <666total wp.pl> writes:
On Friday, 8 February 2019 at 12:09:20 UTC, Ecstatic Coder wrote:
 I agree. I've already had this discussion about that same http 
 stuff being installed by default in Go and Crystal, but not in 
 D, despite D already has support by default for json, sqlite, 
 etc.

 And very honestly, preinstalling dlangui to allow people to 
 immediately start developing connected applications (like in 
 Python and Red) after the DMD installation could also help D 
 become by far the best alternative to both Go and Python.

 But I know this won't happen, because D's leadership, instead 
 of focusing on D's strengths, tries for a decade to compete 
 with C/C++ (low level no-GC languages), and clearly not Go, 
 Python, etc (high-level languages for web/gui/scripting).

 Just my two cents...
While I agree with you on the silliness in chasing C/C++, I disagree with the rest. I don't think adding a package is such a big deal. And you don't have to run dub fetch, dub build/run will do that for you, and the IDE can handle that too. It's just people have a fear of dub and try to avoid it in favor of makefiles whenever possible. I took a look at the competition. I googled "rust web server" and got this result: https://gist.github.com/mjohnsullivan/e5182707caf0a9dbdf2d . To be honest, the code doesn't look too nice, it's too low-level and it's not something one would write in a hurry. On the bottom though is an example using external packages and it looks very nice. I think things like sockets, xml, json belong to standard library, because it promotes interoperability (imagine if we didn't have string in stdlib and everyone would make their custom string classes, it'd be a mess). Dlangui - no. At most it should be promoted as a most straighforward way to do GUIs with D. But even then, I have doubts. I've never used this library, but the screenshots give me a very non-native GUI feeling. In theory it looks fine, but it just looks off.
Feb 08
next sibling parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Friday, 8 February 2019 at 12:29:57 UTC, JN wrote:
 On Friday, 8 February 2019 at 12:09:20 UTC, Ecstatic Coder 
 wrote:
 I agree. I've already had this discussion about that same http 
 stuff being installed by default in Go and Crystal, but not in 
 D, despite D already has support by default for json, sqlite, 
 etc.

 And very honestly, preinstalling dlangui to allow people to 
 immediately start developing connected applications (like in 
 Python and Red) after the DMD installation could also help D 
 become by far the best alternative to both Go and Python.

 But I know this won't happen, because D's leadership, instead 
 of focusing on D's strengths, tries for a decade to compete 
 with C/C++ (low level no-GC languages), and clearly not Go, 
 Python, etc (high-level languages for web/gui/scripting).

 Just my two cents...
While I agree with you on the silliness in chasing C/C++, I disagree with the rest. I don't think adding a package is such a big deal. And you don't have to run dub fetch, dub build/run will do that for you, and the IDE can handle that too. It's just people have a fear of dub and try to avoid it in favor of makefiles whenever possible. I took a look at the competition. I googled "rust web server" and got this result: https://gist.github.com/mjohnsullivan/e5182707caf0a9dbdf2d . To be honest, the code doesn't look too nice, it's too low-level and it's not something one would write in a hurry. On the bottom though is an example using external packages and it looks very nice. I think things like sockets, xml, json belong to standard library, because it promotes interoperability (imagine if we didn't have string in stdlib and everyone would make their custom string classes, it'd be a mess). Dlangui - no. At most it should be promoted as a most straighforward way to do GUIs with D. But even then, I have doubts. I've never used this library, but the screenshots give me a very non-native GUI feeling. In theory it looks fine, but it just looks off.
I'm not saying that adding a package is a big deal. I'm a VERY happy user of Dub. In just two lines it can create my dlangui project, compile it and run it. I'm simply saying that nowadays many languages (Go, Python, etc) which appear to be more "popular" than D come with preinstalled web or gui libraries, and that **maybe** this helps them in convincing people to use them for this kind of development. Like them, D also has a very extensive standard library, but doesn't see the interest in having some basic http server classes provided by default, which I regularly regret.
Feb 08
parent reply JN <666total wp.pl> writes:
On Friday, 8 February 2019 at 21:42:18 UTC, Ecstatic Coder wrote:
 I'm simply saying that nowadays many languages (Go, Python, 
 etc) which appear to be more "popular" than D come with 
 preinstalled web or gui libraries, and that **maybe** this 
 helps them in convincing people to use them for this kind of 
 development.

 Like them, D also has a very extensive standard library, but 
 doesn't see the interest in having some basic http server 
 classes provided by default, which I regularly regret.
Perhaps. But for example when it comes to GUI, Python only comes preinstalled with Tk, which isn't exactly the best GUI library available. Go doesn't come with anything. I think what these languages do better is messaging on what libraries are available. Rust notably has the are we X websites: https://www.arewewebyet.org/ http://areweguiyet.com/ http://arewegameyet.com . In case of Python and Go, there's usually a one defacto unofficial library for every usecase. With D it's a bit trickier. Imagine you want to use a XML library. First try - std.xml. But everyone tells you it sucks and even documentation says it's not the best. So you try external packages. You type "xml" in package search. That doesn't work too good: http://code.dlang.org/search?q=xml . After some more searching you learn about std-experimental-xml, dxml, kxml. std-experimental-xml and kxml I don't even know if they work with recent D versions. dxml seems to work, although I don't know if it's considered release ready already. Similar story for other libraries, especially json, or mysql wrappers. I don't think having all that stuff built-in is an advantage, but knowing where to look definitely is.
Feb 08
parent Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Friday, 8 February 2019 at 21:59:45 UTC, JN wrote:
 On Friday, 8 February 2019 at 21:42:18 UTC, Ecstatic Coder 
 wrote:
 I'm simply saying that nowadays many languages (Go, Python, 
 etc) which appear to be more "popular" than D come with 
 preinstalled web or gui libraries, and that **maybe** this 
 helps them in convincing people to use them for this kind of 
 development.

 Like them, D also has a very extensive standard library, but 
 doesn't see the interest in having some basic http server 
 classes provided by default, which I regularly regret.
Perhaps. But for example when it comes to GUI, Python only comes preinstalled with Tk, which isn't exactly the best GUI library available. Go doesn't come with anything. I think what these languages do better is messaging on what libraries are available. Rust notably has the are we X websites: https://www.arewewebyet.org/ http://areweguiyet.com/ http://arewegameyet.com . In case of Python and Go, there's usually a one defacto unofficial library for every usecase. With D it's a bit trickier. Imagine you want to use a XML library. First try - std.xml. But everyone tells you it sucks and even documentation says it's not the best. So you try external packages. You type "xml" in package search. That doesn't work too good: http://code.dlang.org/search?q=xml . After some more searching you learn about std-experimental-xml, dxml, kxml. std-experimental-xml and kxml I don't even know if they work with recent D versions. dxml seems to work, although I don't know if it's considered release ready already. Similar story for other libraries, especially json, or mysql wrappers. I don't think having all that stuff built-in is an advantage, but knowing where to look definitely is.
I agree, but providing the same basic building blocks has allowed the Crystal and Go to buid LOTS of GREAT web frameworks. And yes, after you can decide if you also want to use one of them for your big web app or directly use those same buildings blocks for your tiny web app. For instance, I'm currently using Chi as Go web framework, and its source code is ridiculously small in size, with almost no dependencies. Those are two reasons why we are so many to love it. Same reasons for the incredible success of Kemal in the Crystal community. Small code, almost no dependencies. But in both languages there are MANY other great alternatives, also mainly or exclusively based on the standard http classes. So having less choice might be a very good thing as well, but personally I still prefer to have the opportunity to choose what suits me best among a large panel of great solutions.
Feb 10
prev sibling next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Friday, 8 February 2019 at 12:29:57 UTC, JN wrote:
 On Friday, 8 February 2019 at 12:09:20 UTC, Ecstatic Coder 
 wrote:
 [...]
I took a look at the competition. I googled "rust web server" and got this result: https://gist.github.com/mjohnsullivan/e5182707caf0a9dbdf2d . To be honest, the code doesn't look too nice, it's too low-level and it's not something one would write in a hurry. On the bottom though is an example using external packages and it looks very nice. I think things like sockets, xml, json belong to standard library, because it promotes interoperability (imagine if we didn't have string in stdlib and everyone would make their custom string classes, it'd be a mess). Dlangui - no. At most it should be promoted as a most straighforward way to do GUIs with D. But even then, I have doubts. I've never used this library, but the screenshots give me a very non-native GUI feeling. In theory it looks fine, but it just looks off.
Microsoft is using Actix for their Rust Azure backend projects, a bit more powerful and easier to use than that gist. https://actix.rs/
Feb 08
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2019-02-08 13:29, JN wrote:

 I took a look at the competition. I googled "rust web server" and got 
 this result: https://gist.github.com/mjohnsullivan/e5182707caf0a9dbdf2d 
 . To be honest, the code doesn't look too nice, it's too low-level and 
 it's not something one would write in a hurry.
I don't know Rust, but that doesn't look like HTTP, it looks like a socket example. It's possible to do the same in D, with roughly the same amount of code, using only the standard library. -- /Jacob Carlborg
Feb 12
prev sibling parent reply 0xEAB <desisma heidel.beer> writes:
On Friday, 8 February 2019 at 12:09:20 UTC, Ecstatic Coder wrote:
 And very honestly, preinstalling dlangui
What qualifies DlangUI to become the default GUI lib that should be pre-installed (in terms of: what disqualifies other libs)? - Elias
Feb 09
parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Sunday, 10 February 2019 at 01:13:16 UTC, 0xEAB wrote:
 On Friday, 8 February 2019 at 12:09:20 UTC, Ecstatic Coder 
 wrote:
 And very honestly, preinstalling dlangui
What qualifies DlangUI to become the default GUI lib that should be pre-installed (in terms of: what disqualifies other libs)? - Elias
Just try them all, and you will quickly find which one is the most cross-platform, compiles easily, runs fast on all the platforms, behaves the same everywhere, can use 3D or canvas rendering, has small dependencies, can be easily mixed with 3D rendering too and gets the job done with crystal clear code. Gtkd, tkd, etc are all good, but as you guess my personal favorite one is obviously dlangui, for all the reasons above...
Feb 10
next sibling parent Andre Pany <andre s-e-a-p.de> writes:
On Sunday, 10 February 2019 at 10:22:07 UTC, Ecstatic Coder wrote:
 On Sunday, 10 February 2019 at 01:13:16 UTC, 0xEAB wrote:
 On Friday, 8 February 2019 at 12:09:20 UTC, Ecstatic Coder 
 wrote:
 And very honestly, preinstalling dlangui
What qualifies DlangUI to become the default GUI lib that should be pre-installed (in terms of: what disqualifies other libs)? - Elias
Just try them all, and you will quickly find which one is the most cross-platform, compiles easily, runs fast on all the platforms, behaves the same everywhere, can use 3D or canvas rendering, has small dependencies, can be easily mixed with 3D rendering too and gets the job done with crystal clear code. Gtkd, tkd, etc are all good, but as you guess my personal favorite one is obviously dlangui, for all the reasons above...
There is only a small enhancement missing in dub to allow following command: dub init example -t dlangui This will create a new dlangui example package on your local file system which you can then immediately run with command dub. With this enhancement in place for me it seems there is no reason to include any specific ui toolkit. But of course there could be some more advertising on the dlang page for the different ui toolkits. Kind regards Andre
Feb 10
prev sibling parent Rubn <where is.this> writes:
On Sunday, 10 February 2019 at 10:22:07 UTC, Ecstatic Coder wrote:
 On Sunday, 10 February 2019 at 01:13:16 UTC, 0xEAB wrote:
 On Friday, 8 February 2019 at 12:09:20 UTC, Ecstatic Coder 
 wrote:
 And very honestly, preinstalling dlangui
What qualifies DlangUI to become the default GUI lib that should be pre-installed (in terms of: what disqualifies other libs)? - Elias
Just try them all, and you will quickly find which one is the most cross-platform, compiles easily, runs fast on all the platforms, behaves the same everywhere, can use 3D or canvas rendering, has small dependencies, can be easily mixed with 3D rendering too and gets the job done with crystal clear code. Gtkd, tkd, etc are all good, but as you guess my personal favorite one is obviously dlangui, for all the reasons above...
It really depends on what you are doing, not everyone needs are going to met with one UI. I don't think a UI should be included with DMD, there's a reason very few languages do it. Especially ones that compile to machine code.
 behaves the same everywhere
That wouldn't be a plus for everyone. People expect their programs to behave a certain way for their platform. Not having the look and feel of their platform is enough for people to not like using it. It's a 8 mb download, there's really no reason to preinstall or include it into the standard.
Feb 10
prev sibling next sibling parent reply sai <sai dummy.com> writes:
On Monday, 4 February 2019 at 23:28:51 UTC, Ben wrote:
 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.
... <snip>
I couldn't agree more. I am trying to expand using D from a simple 1 file scripts to bigger applications, but its always a struggle. Programming is not my day job, but I use it occasionally for my job related work. Funny thing is after reading all these emails I am still confused how to get vibe.d working on windows. Could somebody create a step-by-step instructions with an example that actually works? Pretty please? Thanks in advance.
Feb 05
parent Laurent =?UTF-8?B?VHLDqWd1aWVy?= <laurent.treguier.sink gmail.com> writes:
On Tuesday, 5 February 2019 at 20:15:55 UTC, sai wrote:
 Funny thing is after reading all these emails I am still 
 confused how to get vibe.d working on windows. Could somebody 
 create a step-by-step instructions with an example that 
 actually works? Pretty please? Thanks in advance.
On a Windows 10 VM I had lying around that should be bare, the following worked for me: - Installing dmd for Windows from dlang.org - Not installing anything from Visual Studio during dmd's installation - Installing the Visual C++ runtimes 2010 and 2013 from microsoft.com (https://www.microsoft.com/download/details.aspx?id=14632 and https://www.microsoft.com/download/details.aspx?id=40784) - In a command prompt, in whichever directory you'd like to work: `dub init --type=vibe.d hello-web` - `cd hello-web` - `dub run --arch=x86_64` This seemed to be enough to have a Hello World on 127.0.0.1:8080, I hope I hadn't done anything else I've forgotten.
Feb 05
prev sibling parent Rubn <where is.this> writes:
On Monday, 4 February 2019 at 23:28:51 UTC, Ben wrote:
 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
You don't need W10 SDK for the linker or any of the other options. Just cause they are default options does not mean you need them. Hint: you can uncheck the checkmark unless it is greyed out. When you uncheck all the options except for the one you can't (the one with the linker) you will be left with 1.5 GB :).
Feb 05
prev sibling next sibling parent reply Andre Pany <andre s-e-a-p.de> writes:
On Saturday, 2 February 2019 at 02:32:28 UTC, Ben wrote:
 Not to be a downer but just trying out D again with Vibe.d and 
 getting confronted with the typical bug: Unexpected OPTLINK 
 Termination at EIP=0040F60A

 [...]
You can also set the default architecture to x86_64 for all dub projects as described here https://dub.pm/settings.html Kind regards Andre
Feb 01
next sibling parent reply Ron Tarrant <rontarrant gmail.com> writes:
On Saturday, 2 February 2019 at 06:23:32 UTC, Andre Pany wrote:

 You can also set the default architecture to x86_64 for all dub 
 projects as described here

 https://dub.pm/settings.html
Is this a typo: %APPDATA%\dub\settings.json Shouldn't it be: %APPDATA%\roaming\dub\settings.json or: %APPDATA%\local\dub\settings.json I've never seen any software create it's folder at the top level of %APPDATA%.
Feb 03
parent reply Andre Pany <andre s-e-a-p.de> writes:
On Sunday, 3 February 2019 at 10:20:41 UTC, Ron Tarrant wrote:
 On Saturday, 2 February 2019 at 06:23:32 UTC, Andre Pany wrote:

 You can also set the default architecture to x86_64 for all 
 dub projects as described here

 https://dub.pm/settings.html
Is this a typo: %APPDATA%\dub\settings.json Shouldn't it be: %APPDATA%\roaming\dub\settings.json or: %APPDATA%\local\dub\settings.json I've never seen any software create it's folder at the top level of %APPDATA%.
The environment variable APPDATA points to the roaming folder. Kind regards Andre
Feb 03
parent reply Ron Tarrant <rontarrant gmail.com> writes:
On Sunday, 3 February 2019 at 10:49:59 UTC, Andre Pany wrote:

 The environment variable APPDATA points to the roaming folder.
I didn't know that. Thank you, Andre.
Feb 03
parent bauss <jj_1337 live.dk> writes:
On Sunday, 3 February 2019 at 14:44:48 UTC, Ron Tarrant wrote:
 On Sunday, 3 February 2019 at 10:49:59 UTC, Andre Pany wrote:

 The environment variable APPDATA points to the roaming folder.
I didn't know that. Thank you, Andre.
Neither did I, but now I do!
Feb 03
prev sibling parent Ron Tarrant <rontarrant gmail.com> writes:
On Saturday, 2 February 2019 at 06:23:32 UTC, Andre Pany wrote:

 You can also set the default architecture to x86_64 for all dub 
 projects as described here

 https://dub.pm/settings.html
But OTOH, creating a settings.json file in c:\ProgramData with the following contents: { "defaultArchitecture": "x86_64", "defaultCompiler": "ldc" } has solved my dub linking problem. Perhaps creating this file could become part of the Windows install process, or at least, an option during installation.
Feb 03
prev sibling parent reply bauss <jj_1337 live.dk> writes:
On Saturday, 2 February 2019 at 02:32:28 UTC, Ben wrote:
 Not to be a downer but just trying out D again with Vibe.d and 
 getting confronted with the typical bug: Unexpected OPTLINK 
 Termination at EIP=0040F60A

 Tracing this back, bring up issues in the bugtracker from 2017 
 ( 17508 ), that is still open.

 First impressions and such matter. And for some reason ever new 
 "first impression" with D seems to result in annoying bugs 
 being discovered ( Windows 10 ).

 Yes, i already know. No Visual Studio linker installed ( and 
 no, i do not want a 3GB installation just for the linker, when 
 DMD already includes it ). But somebody forgot to tell dub!

 So anybody using Vibe.d or any other project that rely on dub 
 figuring out that DMD can be run without Visual Studios linker, 
 can enjoy very nice and cryptic errors. User friendly it is not.

 /Frustrated that this is still a issue.
vibe.d doesn't compile with OPTLINK and it hasn't for years. Just use the Microsoft linker by passing: -a=x86_mscoff when building using dub. Also look forward to the future when you don't need to install Visual Studio to get the linker as it will ship with DMD (If it doesn't already? It's been a while since I've checked.)
Feb 02
next sibling parent reply evilrat <evilrat666 gmail.com> writes:
On Saturday, 2 February 2019 at 12:11:56 UTC, bauss wrote:
 Also look forward to the future when you don't need to install 
 Visual Studio to get the linker as it will ship with DMD (If it 
 doesn't already? It's been a while since I've checked.)
It is. But there is another problem. D is a SYSTEM programming language, not just some productivity language. It means there is still dependency on the system libs! Heck, even Rust given up with jemalloc in favor of system allocator by default, if this says something... Of course the problem with packaging the libs with compiler installation can be solved by using same approach MinGW did, like people say, or even using the MinGW libs if it is possible.
Feb 02
parent reply Andre Pany <andre s-e-a-p.de> writes:
On Saturday, 2 February 2019 at 13:18:08 UTC, evilrat wrote:
 On Saturday, 2 February 2019 at 12:11:56 UTC, bauss wrote:
 Also look forward to the future when you don't need to install 
 Visual Studio to get the linker as it will ship with DMD (If 
 it doesn't already? It's been a while since I've checked.)
It is. But there is another problem. D is a SYSTEM programming language, not just some productivity language. It means there is still dependency on the system libs! Heck, even Rust given up with jemalloc in favor of system allocator by default, if this says something... Of course the problem with packaging the libs with compiler installation can be solved by using same approach MinGW did, like people say, or even using the MinGW libs if it is possible.
Mingw libs and headers are also included in recent dmd. Except of rare cases you may not need anymore to install vs or build tools. Kind regards Andre
Feb 02
parent reply Rubn <where is.this> writes:
On Saturday, 2 February 2019 at 14:36:00 UTC, Andre Pany wrote:
 On Saturday, 2 February 2019 at 13:18:08 UTC, evilrat wrote:
 On Saturday, 2 February 2019 at 12:11:56 UTC, bauss wrote:
 Also look forward to the future when you don't need to 
 install Visual Studio to get the linker as it will ship with 
 DMD (If it doesn't already? It's been a while since I've 
 checked.)
It is. But there is another problem. D is a SYSTEM programming language, not just some productivity language. It means there is still dependency on the system libs! Heck, even Rust given up with jemalloc in favor of system allocator by default, if this says something... Of course the problem with packaging the libs with compiler installation can be solved by using same approach MinGW did, like people say, or even using the MinGW libs if it is possible.
Mingw libs and headers are also included in recent dmd. Except of rare cases you may not need anymore to install vs or build tools. Kind regards Andre
I don't get people complaining about and they are usually misinformed as well. You can install VC++ for 1.5 GB using the Build Tool install. Of that 1.5 GB 1 GB are library files and most of that is for the static libraries for the runtime. The last time this came up someone was developing on a cheap tablet or something with 16 GB of space that isn't expandable.
Feb 02
next sibling parent Andre Pany <andre s-e-a-p.de> writes:
On Saturday, 2 February 2019 at 15:43:56 UTC, Rubn wrote:
 On Saturday, 2 February 2019 at 14:36:00 UTC, Andre Pany wrote:
 On Saturday, 2 February 2019 at 13:18:08 UTC, evilrat wrote:
 On Saturday, 2 February 2019 at 12:11:56 UTC, bauss wrote:
 [...]
It is. But there is another problem. D is a SYSTEM programming language, not just some productivity language. It means there is still dependency on the system libs! Heck, even Rust given up with jemalloc in favor of system allocator by default, if this says something... Of course the problem with packaging the libs with compiler installation can be solved by using same approach MinGW did, like people say, or even using the MinGW libs if it is possible.
Mingw libs and headers are also included in recent dmd. Except of rare cases you may not need anymore to install vs or build tools. Kind regards Andre
I don't get people complaining about and they are usually misinformed as well. You can install VC++ for 1.5 GB using the Build Tool install. Of that 1.5 GB 1 GB are library files and most of that is for the static libraries for the runtime. The last time this came up someone was developing on a cheap tablet or something with 16 GB of space that isn't expandable.
I completely agree. On the other side, due to the hard work of some fantastic people, today you can just extract the dmd zip and immediately compile 64 bit applications on windows. This user experience will attract a lot of new users. Kind regards Andre
Feb 02
prev sibling parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Saturday, 2 February 2019 at 15:43:56 UTC, Rubn wrote:
 On Saturday, 2 February 2019 at 14:36:00 UTC, Andre Pany wrote:
 On Saturday, 2 February 2019 at 13:18:08 UTC, evilrat wrote:
 On Saturday, 2 February 2019 at 12:11:56 UTC, bauss wrote:
 Also look forward to the future when you don't need to 
 install Visual Studio to get the linker as it will ship with 
 DMD (If it doesn't already? It's been a while since I've 
 checked.)
It is. But there is another problem. D is a SYSTEM programming language, not just some productivity language. It means there is still dependency on the system libs! Heck, even Rust given up with jemalloc in favor of system allocator by default, if this says something... Of course the problem with packaging the libs with compiler installation can be solved by using same approach MinGW did, like people say, or even using the MinGW libs if it is possible.
Mingw libs and headers are also included in recent dmd. Except of rare cases you may not need anymore to install vs or build tools. Kind regards Andre
I don't get people complaining about and they are usually misinformed as well. You can install VC++ for 1.5 GB using the Build Tool install. Of that 1.5 GB 1 GB are library files and most of that is for the static libraries for the runtime. The last time this came up someone was developing on a cheap tablet or something with 16 GB of space that isn't expandable.
I think that the reason why people complain is that not everybody thinks in the same way as you. Seriously, the last time I had to install D on my freshly reinstalled Windows partition, I almost gave up before finishing the installation procedure, because it once seemed I was doomed to unavoidingly install the X GB of Visual Studio environment (or its build tools, same problem) just to install a small D compiler needed to build my tiny single-file tools (Basil, Pendown, etc) on Windows. By luck, I tried the Mingw option, which worked and this saved my day, but I think you have no idea how unlikely people will click on this Mingw option, and how this little install menu design can turn off people from D if they were just trying to experiment it as a Python or Ruby alternative, because **not everyone** is willing to start that LONG and HUGE Visual Studio thing just to try the finally-not-so-swift D compiler which seems to need it. IMO, the two most urgent things you should improve to avoid immediately pushing people away from their curiosity about D is : 1/ make D's web site landing page show D advantages from the user point of view : why D would be better than Python etc to make file processing scripts, GUI applications, web servers, etc 2/ make the installation process quick and easy : you download a <50MB installer executable, click install, and in less than 2 minutes you are ready to go. For 1, you should really consider putting this text on the landing page : "D is a powerful and expressive language which compiles directly to efficient, native machine code. It is the culmination of decades of experience implementing compilers for many diverse languages and has a unique set of features: high level constructs for great modeling power high performance, compiled language static typing direct interface to the operating system API's and hardware blazingly fast compile-times memory-safe subset (SafeD) maintainable, easy to understand code gradual learning curve (C-like syntax, similar to Java and others) compatible with C application binary interface limited compatibility with C++ application binary interface multi-paradigm (imperative, structured, object oriented, generic, functional programming purity, and even assembly) built-in error detection (contracts, unittests)" Followed by THREE examples : 1. a very simple one which shows D basic syntax "a la JavaScript", by showing how to declare an string array, initialize it with [ "apple", "banana", "orange" ], how to iterate on them, print them, etc 2. a small "hello world" web server example (the one using vibe.d you see IF you select that example) 3. a small GUI example (opening a window with a menu, two radio buttons and a scroll view, using dlangui) All directly visible, with a small text explaining how it is easy to : 1. make JavaScript/Python/Ruby like file scripting 2. easily develop web servers with vibe.d 3. easily develop multiplatform (Win/Mac/Linux) desktop with dlangui (which rocks btw) And for the second point, about the installer, put the quick & easy installation option (Mingw) above and selected by default. Or completely ignore those advices, and be happy what you think is already perfect for D's newcomers :)
Feb 02
next sibling parent Rubn <where is.this> writes:
On Saturday, 2 February 2019 at 16:43:34 UTC, Ecstatic Coder 
wrote:
 On Saturday, 2 February 2019 at 15:43:56 UTC, Rubn wrote:
 On Saturday, 2 February 2019 at 14:36:00 UTC, Andre Pany wrote:
 On Saturday, 2 February 2019 at 13:18:08 UTC, evilrat wrote:
 On Saturday, 2 February 2019 at 12:11:56 UTC, bauss wrote:
 Also look forward to the future when you don't need to 
 install Visual Studio to get the linker as it will ship 
 with DMD (If it doesn't already? It's been a while since 
 I've checked.)
It is. But there is another problem. D is a SYSTEM programming language, not just some productivity language. It means there is still dependency on the system libs! Heck, even Rust given up with jemalloc in favor of system allocator by default, if this says something... Of course the problem with packaging the libs with compiler installation can be solved by using same approach MinGW did, like people say, or even using the MinGW libs if it is possible.
Mingw libs and headers are also included in recent dmd. Except of rare cases you may not need anymore to install vs or build tools. Kind regards Andre
I don't get people complaining about and they are usually misinformed as well. You can install VC++ for 1.5 GB using the Build Tool install. Of that 1.5 GB 1 GB are library files and most of that is for the static libraries for the runtime. The last time this came up someone was developing on a cheap tablet or something with 16 GB of space that isn't expandable.
I think that the reason why people complain is that not everybody thinks in the same way as you.
Never said otherwise, I can have my own opinion and people can have theirs and I can have the opinion that their opinions are silly.
 Seriously, the last time I had to install D on my freshly 
 reinstalled Windows partition, I almost gave up before 
 finishing the installation procedure, because it once seemed I 
 was doomed to unavoidingly install the X GB of Visual Studio 
 environment (or its build tools, same problem) just to install 
 a small D compiler needed to build my tiny single-file tools 
 (Basil, Pendown, etc) on Windows.
Well at least you said "X GB" instead of just fabricating an incorrect number like everyone else :). And how did you get that small compiler to work in the first place? I guess you've never had to install your Windows operating system. I can only imagine you complaining about having to install a 20 GB operating system just to be able to install a small D compiler to build a tiny single-file tool. The D compiler can be small and your tool and be tiny because the complexity of what is actually going on is hidden from you, you don't have to worry about it. But alas people still complain with horrible metaphors.
 By luck, I tried the Mingw option, which worked and this saved 
 my day, but I think you have no idea how unlikely people will 
 click on this Mingw option, and how this little install menu 
 design can turn off people from D if they were just trying to 
 experiment it as a Python or Ruby alternative, because **not 
 everyone** is willing to start that LONG and HUGE Visual Studio 
 thing just to try the finally-not-so-swift D compiler which 
 seems to need it.
Lol, I can't help but laugh "long" and "huge" visual studio thing. As I sit here downloading a 40 GB file, you have no idea the meaning of long or huge. What you need are the VC++ runtime libraries and the linker. Visual Studio is an IDE, they are two different projects and you don't need the IDE to compile and link programs on Windows. There's your problem, you are comparing D, a language that compiles to native machine code with interpreted languages that are specifically designed to be overly simplistic and go to great lengths to hide operating system and architecture specific problems. Hardly a fair comparison and D will probably never be as simple to use as those, as you don't need any development system libraries to use those languages. That's the benefit of an interpreted language.
 IMO, the two most urgent things you should improve to avoid 
 immediately pushing people away from their curiosity about D is 
 :

 1/ make D's web site landing page show D advantages from the 
 user point of view : why D would be better than Python etc to 
 make file processing scripts, GUI applications, web servers, etc
Have you even been on the front page? Literally the first example I was met with: https://dlang.org/ "Start a minimal web server" #!/usr/bin/env dub /+ dub.sdl: name "hello_vibed" dependency "vibe-d" version="~>0.8.0" +/ void main() { import vibe.d; listenHTTP(":8080", (req, res) { res.writeBody("Hello, World: " ~ req.path); }); runApplication(); }
 2/ make the installation process quick and easy : you download 
 a <50MB installer executable, click install, and in less than 2 
 minutes you are ready to go.

 For 1, you should really consider putting this text on the 
 landing page :

 "D is a powerful and expressive language which compiles 
 directly to efficient, native machine code.

 It is the culmination of decades of experience implementing 
 compilers for many diverse languages and has a unique set of 
 features:

     high level constructs for great modeling power
     high performance, compiled language
     static typing
     direct interface to the operating system API's and hardware
     blazingly fast compile-times
     memory-safe subset (SafeD)
     maintainable, easy to understand code
     gradual learning curve (C-like syntax, similar to Java and 
 others)
     compatible with C application binary interface
     limited compatibility with C++ application binary interface
     multi-paradigm (imperative, structured, object oriented, 
 generic, functional programming purity, and even assembly)
     built-in error detection (contracts, unittests)"

 Followed by THREE examples :

 1. a very simple one which shows D basic syntax "a la 
 JavaScript", by showing how to declare an string array, 
 initialize it with [ "apple", "banana", "orange" ], how to 
 iterate on them, print them, etc

 2. a small "hello world" web server example (the one using 
 vibe.d you see IF you select that example)

 3. a small GUI example (opening a window with a menu, two radio 
 buttons and a scroll view, using dlangui)

 All directly visible, with a small text explaining how it is 
 easy to :
 1. make JavaScript/Python/Ruby like file scripting
 2. easily develop web servers with vibe.d
 3. easily develop multiplatform (Win/Mac/Linux) desktop with 
 dlangui (which rocks btw)

 And for the second point, about the installer, put the quick & 
 easy installation option (Mingw) above and selected by default.

 Or completely ignore those advices, and be happy what you think 
 is already perfect for D's newcomers :)
It's not really my decision and I never said anything was good about what D is already doing. It needs to chuck that optlink linker garbage into the bin where it belongs.
Feb 02
prev sibling parent reply Basile B. <b2.temp gmx.com> writes:
On Saturday, 2 February 2019 at 16:43:34 UTC, Ecstatic Coder 
wrote:
 On Saturday, 2 February 2019 at 15:43:56 UTC, Rubn wrote:
 [...]
I think that the reason why people complain is that not everybody thinks in the same way as you. [...]
DMD64 could be released for windows now, with -m64 the default just like under linux or osx. This would work. Actually people still download the 32 bit compiler after all so this is not so crazy that it defaults to -m32
Feb 02
parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Saturday, 2 February 2019 at 20:50:58 UTC, Basile B. wrote:
 On Saturday, 2 February 2019 at 16:43:34 UTC, Ecstatic Coder 
 wrote:
 On Saturday, 2 February 2019 at 15:43:56 UTC, Rubn wrote:
 [...]
I think that the reason why people complain is that not everybody thinks in the same way as you. [...]
DMD64 could be released for windows now, with -m64 the default just like under linux or osx. This would work. Actually people still download the 32 bit compiler after all so this is not so crazy that it defaults to -m32
For DMD to be a truly multi-platform language (Windows/Linux/MacOS), consistency across platforms should always be a must, never an option. Using -m32 by default on Windows, while -m64 is the default on Linux and MacOSX, needlessly breaks that cross-platform promise, and thus creates compilation problems that could easily have been avoided by using a consistent behavior across platforms. And I've experienced this problem first hand... D is clearly what I call an "almost" cross-platform language. It could be close to perfection on that aspect, but unfortunately a few poor decisions here and there regularly breaks its cross-platform behavior in a very annoying way.
Feb 03
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 03/02/2019 10:12 PM, Ecstatic Coder wrote:
 Using -m32 by default on Windows, while -m64 is the default on Linux and 
 MacOSX, needlessly breaks that cross-platform promise, and thus creates 
 compilation problems that could easily have been avoided by using a 
 consistent behavior across platforms.
Keep in mind we are going to be dropping (if I remember correctly) 32-bit support for OSX. So its not quite as simple as the above posts may suggest. Every platform is different, both in hardware in use and in the OS in question. Defaults for targets may not make sense everywhere.
Feb 03
parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Sunday, 3 February 2019 at 09:23:59 UTC, rikki cattermole 
wrote:
 On 03/02/2019 10:12 PM, Ecstatic Coder wrote:
 Using -m32 by default on Windows, while -m64 is the default on 
 Linux and MacOSX, needlessly breaks that cross-platform 
 promise, and thus creates compilation problems that could 
 easily have been avoided by using a consistent behavior across 
 platforms.
Keep in mind we are going to be dropping (if I remember correctly) 32-bit support for OSX. So its not quite as simple as the above posts may suggest. Every platform is different, both in hardware in use and in the OS in question. Defaults for targets may not make sense everywhere.
I agree, but IMO this is one more reason to use 64 bit as the new Windows default. There will always be old PCs running on 32 bit OS, but many statistics corroborate the fact that most Windows users have now switched to the 64 bit version. That's especially true for PC gamers, if you simply look at the Steam statistics : https://store.steampowered.com/hwsurvey/ (click on OS Version)
Feb 03
next sibling parent reply Andre Pany <andre s-e-a-p.de> writes:
On Sunday, 3 February 2019 at 11:30:34 UTC, Ecstatic Coder wrote:
 On Sunday, 3 February 2019 at 09:23:59 UTC, rikki cattermole 
 wrote:
 On 03/02/2019 10:12 PM, Ecstatic Coder wrote:
 Using -m32 by default on Windows, while -m64 is the default 
 on Linux and MacOSX, needlessly breaks that cross-platform 
 promise, and thus creates compilation problems that could 
 easily have been avoided by using a consistent behavior 
 across platforms.
Keep in mind we are going to be dropping (if I remember correctly) 32-bit support for OSX. So its not quite as simple as the above posts may suggest. Every platform is different, both in hardware in use and in the OS in question. Defaults for targets may not make sense everywhere.
I agree, but IMO this is one more reason to use 64 bit as the new Windows default. There will always be old PCs running on 32 bit OS, but many statistics corroborate the fact that most Windows users have now switched to the 64 bit version. That's especially true for PC gamers, if you simply look at the Steam statistics : https://store.steampowered.com/hwsurvey/ (click on OS Version)
As far as I understand, it is technically possible to provide a 64 bit dmd which defaults to x86_64 for windows. The release pipeline needs to adapted. To get this right, this will take several days of work (assumption). Kind regards Andre
Feb 03
next sibling parent Ecstatic Coder <ecstatic.coder gmail.com> writes:
 I agree, but IMO this is one more reason to use 64 bit as the 
 new Windows default.

 There will always be old PCs running on 32 bit OS, but many 
 statistics corroborate the fact that most Windows users have 
 now switched to the 64 bit version.

 That's especially true for PC gamers, if you simply look at 
 the Steam statistics :

 https://store.steampowered.com/hwsurvey/
 (click on OS Version)
As far as I understand, it is technically possible to provide a 64 bit dmd which defaults to x86_64 for windows. The release pipeline needs to adapted. To get this right, this will take several days of work (assumption). Kind regards Andre
That would clearly be the best solution, but just having the -m64 option activated by default on the 32-bit compiler would already be a big step into that direction...
Feb 03
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/3/2019 3:41 AM, Andre Pany wrote:
 As far as I understand, it is technically possible to provide a 64 bit dmd
which 
 defaults to x86_64 for windows. The release pipeline needs to adapted. To get 
 this right, this will take several days of work (assumption).
Compiling 64 bit executables on Windows relies on the user having the Microsoft VS tools installed. For 32 bit executables, we ship everything needed.
Feb 10
parent Seb <seb wilzba.ch> writes:
On Sunday, 10 February 2019 at 23:11:17 UTC, Walter Bright wrote:
 On 2/3/2019 3:41 AM, Andre Pany wrote:
 As far as I understand, it is technically possible to provide 
 a 64 bit dmd which defaults to x86_64 for windows. The release 
 pipeline needs to adapted. To get this right, this will take 
 several days of work (assumption).
Compiling 64 bit executables on Windows relies on the user having the Microsoft VS tools installed. For 32 bit executables, we ship everything needed.
Thanks to Reiner's excellent work this isn't true anymore since already a year (2.079): https://dlang.org/changelog/2.079.0.html#lld_mingw
Feb 10
prev sibling parent reply Rubn <where is.this> writes:
On Sunday, 3 February 2019 at 11:30:34 UTC, Ecstatic Coder wrote:
 On Sunday, 3 February 2019 at 09:23:59 UTC, rikki cattermole 
 wrote:
 On 03/02/2019 10:12 PM, Ecstatic Coder wrote:
 Using -m32 by default on Windows, while -m64 is the default 
 on Linux and MacOSX, needlessly breaks that cross-platform 
 promise, and thus creates compilation problems that could 
 easily have been avoided by using a consistent behavior 
 across platforms.
Keep in mind we are going to be dropping (if I remember correctly) 32-bit support for OSX. So its not quite as simple as the above posts may suggest. Every platform is different, both in hardware in use and in the OS in question. Defaults for targets may not make sense everywhere.
I agree, but IMO this is one more reason to use 64 bit as the new Windows default. There will always be old PCs running on 32 bit OS, but many statistics corroborate the fact that most Windows users have now switched to the 64 bit version. That's especially true for PC gamers, if you simply look at the Steam statistics : https://store.steampowered.com/hwsurvey/ (click on OS Version)
0.93% have cpus with only 1 core in it. Really shows how people just hold on to their CPU. Would be interesting to see what CPUs are 32-bit and 64-bit Vs. the OS that are 32-bit, but they don't provide that information for CPUs. It's kind of funny there is someone that would argue that the Windows version of DMD should target 32-bit. This is why Windows is so horrible, people that don't understand or care about the platform making decisions for it. What makes more sense is for the default to be based on the host's OS version, like what LDC does. Doesn't make sense to compile 64-bit on a 32-bit OS as you won't be able to run the program. Which is probably what most people are going to try to do.
Feb 03
parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
 0.93% have cpus with only 1 core in it. Really shows how people 
 just hold on to their CPU. Would be interesting to see what 
 CPUs are 32-bit and 64-bit Vs. the OS that are 32-bit, but they 
 don't provide that information for CPUs.

 It's kind of funny there is someone that would argue that the 
 Windows version of DMD should target 32-bit. This is why 
 Windows is so horrible, people that don't understand or care 
 about the platform making decisions for it. What makes more 
 sense is for the default to be based on the host's OS version, 
 like what LDC does. Doesn't make sense to compile 64-bit on a 
 32-bit OS as you won't be able to run the program. Which is 
 probably what most people are going to try to do.
+1
Feb 03
parent Basile B. <b2.temp gmx.com> writes:
On Sunday, 3 February 2019 at 15:19:03 UTC, Ecstatic Coder wrote:
 0.93% have cpus with only 1 core in it. Really shows how 
 people just hold on to their CPU. Would be interesting to see 
 what CPUs are 32-bit and 64-bit Vs. the OS that are 32-bit, 
 but they don't provide that information for CPUs.

 It's kind of funny there is someone that would argue that the 
 Windows version of DMD should target 32-bit. This is why 
 Windows is so horrible, people that don't understand or care 
 about the platform making decisions for it. What makes more 
 sense is for the default to be based on the host's OS version, 
 like what LDC does. Doesn't make sense to compile 64-bit on a 
 32-bit OS as you won't be able to run the program. Which is 
 probably what most people are going to try to do.
+1
Your message doesn't include the author you quote, but i think he referred to my previous message. "there is someone that would argue that the Windows version of DMD should target 32-bit" What i meant is that - DMD32 should target 32 bits binary by default (this is the case) - DMD64 should target 64 bits binary by default. Now the yikes is that there's >>no DMD64 officially distributed for windows<<. And now that -m64 works without the MS build tools, maybe this DMD64 can be released officially ?
Feb 03
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2019-02-02 13:11, bauss wrote:

 Also look forward to the future when you don't need to install Visual 
 Studio to get the linker as it will ship with DMD (If it doesn't 
 already? It's been a while since I've checked.)
The linker is already shipped with DMD. -- /Jacob Carlborg
Feb 02