On Sunday, 1 July 2018 at 14:01:11 UTC, Jonathan M Davis wrote:
> On Sunday, July 01, 2018 13:37:32 Ecstatic Coder via Digitalmars-d-announce wrote:
>> On Sunday, 1 July 2018 at 12:43:53 UTC, Johannes Loher wrote:
>> > Am 01.07.2018 um 14:12 schrieb Ecstatic Coder:
>> >> Add a 10-liner "Hello World" web server example on the main page and that's it.
>> >
>> > There already is one in the examples:
>> >
>> > #!/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();
>> >
>> > }
>>
>> Yeah I know, guess who asked for it...
>>
>> But the last step, which is including such functionality into the standard library , will never happen, because nobody here seems to see the point of doing this.
>>
>> I guess those who made that for Go and Crystal probably did it wrong.
>>
>> What a mistake they did, and they don't even know they make a mistake, silly them... ;)
>
> What should and shouldn't go in the standard library for a language is something that's up for a lot of debate and is likely to often be a point of contention. There is no clear right or wrong here. Languages that have had very sparse standard libraries have done quite well, and languages that have had kitchen sink libraries have done quite well. There are pros and cons to both approaches.
>
> - Jonathan M Davis

I agree.

But here I'm just talking of the "public image" of the language.

Languages which integrates HTTP-related components in their standard library, and advertize on that (like Crystal for instance), obviously apply a different "marketing" strategy than languages which have chosen not to do so.

That's all I say...

I personally appreciate that my Go and Crystal code is mostly based on standard components which are updated along with the language, but I agree that vibe.d can perfectly get the job done if you better trust thirdparty libraries for that.

On Sunday, 1 July 2018 at 15:40:20 UTC, Ecstatic Coder wrote:
> On Sunday, 1 July 2018 at 14:01:11 UTC, Jonathan M Davis wrote:
>> On Sunday, July 01, 2018 13:37:32 Ecstatic Coder via Digitalmars-d-announce wrote:
>>> On Sunday, 1 July 2018 at 12:43:53 UTC, Johannes Loher wrote:
>>> > Am 01.07.2018 um 14:12 schrieb Ecstatic Coder:
>>> >> Add a 10-liner "Hello World" web server example on the main page and that's it.
>>> >
>>> > There already is one in the examples:
>>> >
>>> > #!/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();
>>> >
>>> > }
>>>
>>> Yeah I know, guess who asked for it...
>>>
>>> But the last step, which is including such functionality into the standard library , will never happen, because nobody here seems to see the point of doing this.
>>>
>>> I guess those who made that for Go and Crystal probably did it wrong.
>>>
>>> What a mistake they did, and they don't even know they make a mistake, silly them... ;)
>>
>> What should and shouldn't go in the standard library for a language is something that's up for a lot of debate and is likely to often be a point of contention. There is no clear right or wrong here. Languages that have had very sparse standard libraries have done quite well, and languages that have had kitchen sink libraries have done quite well. There are pros and cons to both approaches.
>>
>> - Jonathan M Davis
>
> I agree.
>
> But here I'm just talking of the "public image" of the language.
>
> Languages which integrates HTTP-related components in their standard library, and advertize on that (like Crystal for instance), obviously apply a different "marketing" strategy than languages which have chosen not to do so.
>
> That's all I say...

Two points:

- Andrei pushed to include vibe.d but it didn't happen.

"There's no web services framework (by this time many folks know of D, but of those a shockingly small fraction has even heard of vibe.d). I have strongly argued with Sönke to bundle vibe.d with dmd over one year ago, and also in this forum. There wasn't enough interest."
https://forum.dlang.org/post/nipb14$ldb$1@digitalmars.com

- As you acknowledge, integration has drawbacks too. I thought this was an interesting recent article about how it has now hobbled one of the biggest tech companies in the world:

https://stratechery.com/2018/intel-and-the-danger-of-integration/

I don't think the web matters enough these days that it is worth bundling, which is why a webassembly port is also not worth it for most:

https://www.mobiloud.com/blog/mobile-apps-vs-the-mobile-web/

On Friday, 29 June 2018 at 07:03:52 UTC, Dmitry Olshansky wrote:
> P.S. I mean what you think the future of native code is??? Rust? Crystal?? Nim???

Thank you very much for mentioning about the Crystal programming language. I din't know there is a Crystal lang so I changed my project name from Crystal to Liberty, 2 days ago so people don't get confuzed.

On Monday, 2 July 2018 at 05:20:51 UTC, Joakim wrote:
> On Sunday, 1 July 2018 at 15:40:20 UTC, Ecstatic Coder wrote:
>> On Sunday, 1 July 2018 at 14:01:11 UTC, Jonathan M Davis wrote:
>>> On Sunday, July 01, 2018 13:37:32 Ecstatic Coder via Digitalmars-d-announce wrote:
>>>> On Sunday, 1 July 2018 at 12:43:53 UTC, Johannes Loher wrote:
>>>> > Am 01.07.2018 um 14:12 schrieb Ecstatic Coder:
>>>> >> Add a 10-liner "Hello World" web server example on the main page and that's it.
>>>> >
>>>> > There already is one in the examples:
>>>> >
>>>> > #!/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();
>>>> >
>>>> > }
>>>>
>>>> Yeah I know, guess who asked for it...
>>>>
>>>> But the last step, which is including such functionality into the standard library , will never happen, because nobody here seems to see the point of doing this.
>>>>
>>>> I guess those who made that for Go and Crystal probably did it wrong.
>>>>
>>>> What a mistake they did, and they don't even know they make a mistake, silly them... ;)
>>>
>>> What should and shouldn't go in the standard library for a language is something that's up for a lot of debate and is likely to often be a point of contention. There is no clear right or wrong here. Languages that have had very sparse standard libraries have done quite well, and languages that have had kitchen sink libraries have done quite well. There are pros and cons to both approaches.
>>>
>>> - Jonathan M Davis
>>
>> I agree.
>>
>> But here I'm just talking of the "public image" of the language.
>>
>> Languages which integrates HTTP-related components in their standard library, and advertize on that (like Crystal for instance), obviously apply a different "marketing" strategy than languages which have chosen not to do so.
>>
>> That's all I say...
>
> Two points:
>
> - Andrei pushed to include vibe.d but it didn't happen.
>
> "There's no web services framework (by this time many folks know of D, but of those a shockingly small fraction has even heard of vibe.d). I have strongly argued with Sönke to bundle vibe.d with dmd over one year ago, and also in this forum. There wasn't enough interest."
> https://forum.dlang.org/post/nipb14$ldb$1@digitalmars.com
>
> - As you acknowledge, integration has drawbacks too. I thought this was an interesting recent article about how it has now hobbled one of the biggest tech companies in the world:
>
> https://stratechery.com/2018/intel-and-the-danger-of-integration/
>
> I don't think the web matters enough these days that it is worth bundling, which is why a webassembly port is also not worth it for most:
>
> https://www.mobiloud.com/blog/mobile-apps-vs-the-mobile-web/

Instead of trying to integrate vibe.d, which I don't think would be a good idea, personally I'd rather suggest taking the opportunity to design the interface of those standard HTTP-related components from scratch (listener server, fibers, channels, etc), independently from vibe.d and with a minimalistic mindset, by taking inspiration mainly from Go, along with Crystal and vibe.d, even if the implementation will obviously end up being very similar to the one of vibe.d.

On Saturday, 30 June 2018 at 03:02:15 UTC, Joakim wrote:
>> The future of native code will be replacing scripting languages. D is really good at that task.
>
> This will never happen, doesn't matter how good D is at it, they will always be better because they sacrifice performance for ease of use.

I think it depends on a couple of factors. First, some of us prefer static typing, but until a few years ago, the POS known as Java was the best available language with static typing. As languages like D build up libraries that make it easy to replace the functionality of scripting languages, many of us will move. Second, scripting languages lose their ease of use advantages quickly once performance becomes an issue. As data science and web services continue to grow at a fast pace, more programs are being written for which performance will eventually be an issue.

> AFAIK, nobody in the broader community was ever told that the D foundation money would be used to fund a bunch of Romanian interns, it just happened.

My understanding is that a lot of that was funded by Andrei (but maybe I am wrong) so I have never had a problem with that decision. Where it does cause problems is that anyone else, myself included, may not be eager to donate for that reason because it's not what we feel is going to help with adoption of the language. As you mentioned, some work on IDEs is being funded, but even then it appears to be one IDE for Windows users. That's not relevant to anything I'm doing. It's better if I contribute by improving the ecosystem in a way that helps others doing the same things.

On Monday, 2 July 2018 at 18:03:25 UTC, bachmeier wrote:
> On Saturday, 30 June 2018 at 03:02:15 UTC, Joakim wrote:
>>> The future of native code will be replacing scripting languages. D is really good at that task.
>>
>> This will never happen, doesn't matter how good D is at it, they will always be better because they sacrifice performance for ease of use.
Generalization

>
> I think it depends on a couple of factors. First, some of us prefer static typing, but until a few years ago, the POS known as Java was the best available language with static typing. As languages like D build up libraries that make it easy to replace the functionality of scripting languages, many of us will move. Second, scripting languages lose their ease of use advantages quickly once performance becomes an issue. As data science and web services continue to grow at a fast pace, more programs are being written for which performance will eventually be an issue.

JavaScript is the most popular and growing language on earth.

>
>> AFAIK, nobody in the broader community was ever told that the D foundation money would be used to fund a bunch of Romanian interns, it just happened.
>
> My understanding is that a lot of that was funded by Andrei (but maybe I am wrong) so I have never had a problem with that decision. Where it does cause problems is that anyone else, myself included, may not be eager to donate for that reason because it's not what we feel is going to help with adoption of the language. As you mentioned, some work on IDEs is being funded, but even then it appears to be one IDE for Windows users.

Windows?  It's not an IDE. Its a text editor by Microsoft called Visual Studio Code and it's cross platform. The D extension is the most capable cross platform option. I use it on Linux an it works really well. I wouldn't hesitate to donate money just to see it gain further improvements. Its really awesome.

When I see people complaining about lack of D support for code editors...I wonder if they make effort to assert their complaints.

If course D cannot be supported on every ide/text editor. Popular ones are well supported. Visual Studio and Visual Studio Code being the best IMO. However, sublime, vim, and monodevelop have good support too.

Maybe they should mention what they're not getting from supported IDEs/text editors.

> That's not relevant to anything I'm doing. It's better if I contribute by improving the ecosystem in a way that helps others doing the same things.


D has a very diverse use case so the generalization is moot. For example I prefer having the gc manage memory for me...For most of the things I do with D...contrary to other opinions.

> Let me echo this: transparency has historically been a big problem for D.  AFAIK, nobody in the broader community was ever told that the D foundation money would be used to fund a bunch of Romanian interns, it just happened. In the end, it appears to have worked out great, but why would anybody donate without being given transparency on where the money was going in the first place, when it could have ended badly?
>
> I understand Andrei had connections with that Romanian university, but some donor might have had connections with a Brazilian or Chinese university that might have worked out even better. We'll never explore such connections and alternatives without transparency.
>
> The current move to fund some IDE work with Opencollective is better in that regard, but with no concrete details on what it entails, not significantly better:
>
> https://forum.dlang.org/post/pxwxhhbuburvddnhacgh@forum.dlang.org
>
> Anyway, I don't use such IDEs, so not a reason for me to donate anyway.
>
> Honestly, Dmitry's posts starting this thread are incoherent, I'm not sure what he was trying to say. If he feels D users should be donating much more, he and others need to make clear how that money will be spent.

+1

And maybe it would be a good idea to use a Kickstarter-like philosophy to fund D's development with more transparency.

I mean, you should offer a short panel of D enhancement projects, with their precise goal, minimum bugdet and investment time limit (for instance one year to reach the required budget), plus an ordered list of additional developments if the gathered money exceeds the initial budget.

People can then invest in the project(s) that interest them the most.

If the minimum budget is not reached after the time limit, the investors can get their money back, or decide to invest it in another project which hasn't expired.

As you guess, in my opinion, two possible fundable projects would be :

1. a project to add http-related components to D's standard library
2. a project to allow D to be REALLY usable without GC, i.e. add weak/strong reference to the language and provide a standard library which uses them

> D has a very diverse use case so the generalization is moot. For example I prefer having the gc manage memory for me...For most of the things I do with D...contrary to other opinions.

+1

For most D use cases (including mine, which is file processing), D's GC is a blessing, and one of its main advantages over C++, IMHO.

And if you want to use D for C++-like use cases where you don't want it, this generally leads to having to reinvent the wheel in order to avoid unwanted garbage collections. For instance :

https://github.com/gecko0307/dlib/blob/master/dlib/container

That's why I'm personally in favor of D supporting reference-counting based memory management directly in its syntax (T@, etc), and also providing the GC-free standard components (strings, slices, maps, etc).

PS : BTW kudos to Timur Gafarov, it's a pity so many D developers prefer to start developing their own engines instead of helping Tibur finish Dagon to make it a production-ready game engine (adding terrain, UI, networking, etc). Very promising work IMHO !

https://dlang.org/blog/2016/09/16/project-highlight-timur-gafarov/

And having the language help him (native strong/weak references) would be nice too :D

On Tuesday, 3 July 2018 at 05:52:40 UTC, Ecstatic Coder wrote:

> I mean, you should offer a short panel of D enhancement projects, with their precise goal, minimum bugdet and investment time limit (for instance one year to reach the required budget), plus an ordered list of additional developments if the gathered money exceeds the initial budget.
>
> People can then invest in the project(s) that interest them the most.

That's what we thought we were getting with Open Collective goals before we activated it. That was a bit disappointing. Anyway, the plan is to have something similar to what you describe. It won't be Kickstarter, though. Before activating yet another service, I want to look at ways to integrate what we already have. I'll have more news on this somewhere down the road.

On Sunday, 1 July 2018 at 12:43:53 UTC, Johannes Loher wrote:
> Am 01.07.2018 um 14:12 schrieb Ecstatic Coder:
>> 
>> Add a 10-liner "Hello World" web server example on the main page and that's it.
>
> There already is one in the examples:
>
> #!/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();
> }

Its nice when it works.

First: its a hack as nobody will run any production code with the shebang include like the example posted. And they will be forced set up a dub package. This already confuses people as its two standards. Shebang is nice and well if you have Unix experience but not so much for Windows users who have no Posix experience.

Crystal or Go where your simply adding a import http and your can keep working on that code.

Second: Its a hack and it fails easily. Maybe its dub or whatever but i remember trying that example in the past several times and had a lot of issues with failures using it. Using the proper dub package actually worked better.

So this http example is not exactly prime. Add to this that Vibe.d also keeps having issues with D releases. Where DMD breaks something (regressions come to mind) and when Vibe.d ( and its dependencies ) as a result also break.

I never found D + Vibe.D very reliable or stable. Your almost forced to stick to a version of D and never reinstall your system. Even setting up a home / work setup with some time between can result in issues that eat away hours of your time.

It also does not help that Vibe.D has problems to reach higher performance levels.

https://www.techempower.com/benchmarks/#section=test&runid=7dc8ea3a-6db5-41b8-a4d3-c18cfe72182b&hw=ph&test=fortune

Even in my own tests, D+Vibe always lags behind Crystal, Go and other languages. That is just shucking resources out of the window. Not what you expect for a language this old.