February 08, 2019
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...

February 08, 2019
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.
February 08, 2019
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.
February 08, 2019
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/

February 08, 2019
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.
February 10, 2019
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
February 10, 2019
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...


February 10, 2019
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.

February 10, 2019
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


February 10, 2019
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.