On Wednesday, 8 June 2016 at 17:17:37 UTC, Adam D. Ruppe wrote:
> bother with a proper setup. There's a reason ALL the other major languages and frameworks use Apache/nginx/IIS on their websites. It's the recommended way to do it.

Sure, you can have vibe.d behind nginx, if you want to, but it would be more impressive if you didn't have to. Scripting languages do of course have to.

The main point is that it isn't visible at all that vibe.d is involved or how it is being used. So you loose out on a showcase opportunity.

What other adopted solutions do is not really relevant as they already _have_ massive amounts of showcases around the web _or_ they are not trying to position themselves in as a web backend langauge. D is not a scripting language, if it wants to compete with Go in the web arena it has to showcase itself where it can.

AFAIK golang.org uses their own stuff, Go on AppEngine.


> There's a difference between an application server and a frontend web server.

Well, you should be able to write a proxy in a system level language. If you can showcase that it is easy to get comparable performance then all the better.

On Wednesday, 8 June 2016 at 17:25:32 UTC, Brad Anderson wrote:
> On Wednesday, 8 June 2016 at 14:41:55 UTC, Ola Fosheim Grøstad wrote:
>> [snip]
>>
>> I like the "are we fast yet" websites that various project put up, displaying improvements over time.
>
> You mean like this? http://digger.k3.1azy.net/trend/

Yes, but running DMD with/without GC, compiling itself.

Such graphs are very good for showing end-users that you have steady progress (as changes in absolute values are difficult to experience over 12 months)

On Wednesday, 8 June 2016 at 17:05:42 UTC, Jonathan Marler wrote:
> On Wednesday, 8 June 2016 at 15:51:58 UTC, Adam D. Ruppe wrote:
>> On Wednesday, 8 June 2016 at 15:05:54 UTC, Ola Fosheim Grøstad wrote:
>>> The forum-index http header report:
>>>
>>> Server:nginx/1.4.6 (Ubuntu)
>>>
>>> People check out stuff like that.
>>
>> Yeah, and that's an industry-standard production deployment.
>>
>> But perhaps we should just change the server line for the people who do look at it. No need to change the deployment, just the apache/nginx config to spit out something different.
>
> I can picture the article now:
>
>> The D programming language maintains its own web framework called vibe.d, but the official website dlang.org doesn't use it.  Instead they use the Apache framework written in C.  They also decided to modify Apache to make it look like their own vibe.d framework.  Apparently tricking people into thinking they use their own code was easier the actually using it.

Did you even bother reading my response????
Stop wasting your time by trolling - make a difference!

----------

I agree - this is bikeshedding. We all rely on existing software for our day to day life. I quickly checked the first hit server for other languages - have a look:

rust.org: nginx
php.net: nginx
julia.org: Apache
scala-lang.org: Apache
julia-lang.org: Github
python.org: nginx
www.cplusplus.com: Apache
perl.org: Apache
developer.mozilla.org: Apache
ruby-lang.org: nginx
swift.org: Apache

... and the last time I checked all of them use the C implementation of git for their source code ;-)

Mike's call for help was about actively _improving_ dlang.org by pointing out

- what is (or could be) confusing for newcomers
- bad written texts
- missing examples
- not user-friendly parts of the documentation
- missing info
- ...

Basically everything that could stop someone from having awesome first five minutes with D!

On Wednesday, 8 June 2016 at 17:34:25 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 8 June 2016 at 17:17:37 UTC, Adam D. Ruppe wrote:
>> bother with a proper setup. There's a reason ALL the other major languages and frameworks use Apache/nginx/IIS on their websites. It's the recommended way to do it.
>
> Sure, you can have vibe.d behind nginx, if you want to, but it would be more impressive if you didn't have to. Scripting languages do of course have to.
>
> The main point is that it isn't visible at all that vibe.d is involved or how it is being used. So you loose out on a showcase opportunity.
>
> What other adopted solutions do is not really relevant as they already _have_ massive amounts of showcases around the web _or_ they are not trying to position themselves in as a web backend langauge. D is not a scripting language, if it wants to compete with Go in the web arena it has to showcase itself where it can.
>
> AFAIK golang.org uses their own stuff, Go on AppEngine.
>
>
>> There's a difference between an application server and a frontend web server.
>
> Well, you should be able to write a proxy in a system level language. If you can showcase that it is easy to get comparable performance then all the better.

vibes website doesn't use a proxy.  But if D wants to compete in web then there are alot of better areas to improve on like ORMs (I know not everyone likes them but they have their use cases and users), DB support, etc.  That will attract more ppl more than some proxy would..  At least as far as people and companies that build applications..  I mean D could also be used to build a database but why when there are already used alternatives..

On Wednesday, 8 June 2016 at 17:34:25 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 8 June 2016 at 17:17:37 UTC, Adam D. Ruppe wrote:
>> bother with a proper setup. There's a reason ALL the other major languages and frameworks use Apache/nginx/IIS on their websites. It's the recommended way to do it.
>
> Sure, you can have vibe.d behind nginx, if you want to, but it would be more impressive if you didn't have to. Scripting languages do of course have to.
>
> The main point is that it isn't visible at all that vibe.d is involved or how it is being used. So you loose out on a showcase opportunity.

How is serving static HTML difficult or even impressive?

I agree that a showcase website for vibed (or another D web framework) would be beneficial, but a real showcase has totally different specs:

- > 1 million visitors per day
- highly dynamic content (high-throughput databases)
- solved technological difficulties (e.g. in-memory caching)
- ...

That being said, we are working on getting a page [1] of organizations using D ready, so that we can link to _real_ showcases ;-)

[1] http://dlang.org/orgs-using-d.html

On Wednesday, 8 June 2016 at 17:43:03 UTC, Seb wrote:
> On Wednesday, 8 June 2016 at 17:05:42 UTC, Jonathan Marler wrote:
>> On Wednesday, 8 June 2016 at 15:51:58 UTC, Adam D. Ruppe wrote:
>>> On Wednesday, 8 June 2016 at 15:05:54 UTC, Ola Fosheim Grøstad wrote:
>>>> The forum-index http header report:
>>>>
>>>> Server:nginx/1.4.6 (Ubuntu)
>>>>
>>>> People check out stuff like that.
>>>
>>> Yeah, and that's an industry-standard production deployment.
>>>
>>> But perhaps we should just change the server line for the people who do look at it. No need to change the deployment, just the apache/nginx config to spit out something different.
>>
>> I can picture the article now:
>>
>>> The D programming language maintains its own web framework called vibe.d, but the official website dlang.org doesn't use it.  Instead they use the Apache framework written in C.  They also decided to modify Apache to make it look like their own vibe.d framework.  Apparently tricking people into thinking they use their own code was easier the actually using it.
>
> Mike's call for help was about actively _improving_ dlang.org by pointing out
>
> - what is (or could be) confusing for newcomers
> - bad written texts
> - missing examples
> - not user-friendly parts of the documentation
> - missing info
> - ...
>
> Basically everything that could stop someone from having awesome first five minutes with D!

Great points to make dlang.org more welcoming.  Where it is now is much further ahead then years past.

I read your post but I don't think we in any disagreement.  I think everyone can agree that it would look better to others if dlang.org used it's own web framework.  Whether or not it makes sense to actually implement it is another question.  Since I'm not intimately familiar with the internals of dlang.org, or the consequences of switching, I don't assert that either way would be better.  I am, however, pointing out that there are going to be poeple trying to share the D language in a negative light, and dlang.org not using vibe is exactly the kind of thing these people will feed off of and possibly use to turn off others from the language.

On Wednesday, 8 June 2016 at 17:43:23 UTC, dewitt wrote:
> vibes website doesn't use a proxy.

Yes, but more people visit dlang.org, and it makes it more official if it is showcased here as a visible part of the website (one way or another).

> But if D wants to compete in web then there are alot of better areas to improve on like ORMs (I know not everyone likes them but they have their use cases and users), DB support, etc.  That will attract more ppl more than some proxy would..

Probably. I don't know.

I can only tell what I am looking out for:

- good memcache client
- good nosql interface
- easy deployment in the cloud (in my case Google, but could be any other vendor)

And optionally:
- fast javascript interpreter/JIT (for precompiling pages)


> I mean D could also be used to build a database but why when there are already used alternatives..

A database is no point as people won't use it unless it is proven rock solid (wait and see for a decade). Interfacing with infrastructure is more important.

Working well without a proxy/frontend is useful, when you start thinking about things like websockets etc.

On Wednesday, 8 June 2016 at 17:50:11 UTC, Seb wrote:
> I agree that a showcase website for vibed (or another D web framework) would be beneficial, but a real showcase has totally different specs:
>
> - > 1 million visitors per day
> - highly dynamic content (high-throughput databases)
> - solved technological difficulties (e.g. in-memory caching)

As a backend developer I don't really care about those, scaling is done by a separate infrastructure and memcache has to be shared (but a good memcache client is necessary, true). I care about:

- my own productivity
- how easy it is to locate failures on a running instance
- interfacing with infrastructure (also logging over network)
- spin up time
- number of concurrent requests on a single instance / memory usage
- full separation between requests
- robustness / uptime (and how close to out-of-memory situations are handled)
- http2 support
- websockets
...

On Wednesday, 8 June 2016 at 17:59:29 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 8 June 2016 at 17:43:23 UTC, dewitt wrote:
>> vibes website doesn't use a proxy.
>
> Yes, but more people visit dlang.org, and it makes it more official if it is showcased here as a visible part of the website (one way or another).
>
>> But if D wants to compete in web then there are alot of better areas to improve on like ORMs (I know not everyone likes them but they have their use cases and users), DB support, etc.  That will attract more ppl more than some proxy would..
>
> Probably. I don't know.

Pretty sure and I hope std.database is coming soon to Phobos (there was quite some buzz at this year's dconf)

http://dconf.org/2016/talks/smith.html
https://github.com/cruisercoder/dstddb

See also Martin Nowak's talk about his idea for ORM in D:

http://dconf.org/2016/talks/nowak.html

> I can only tell what I am looking out for:
>
> - good memcache client

https://github.com/TiberiuGal/memcached4d ?

> - good nosql interface

what's wrong with vibed's mongodb?

> - easy deployment in the cloud (in my case Google, but could be any other vendor)

Just compile & upload? Isn't that the great part about having just one executable?
For better control, I use systemd, but I do agree that there should be more guides & documentation - so go ahead and write them!

> And optionally:
> - fast javascript interpreter/JIT (for precompiling pages)

https://github.com/higgsjs/Higgs?

On Wednesday, 8 June 2016 at 18:15:22 UTC, Seb wrote:
>> - good nosql interface
>
> what's wrong with vibed's mongodb?

Probably nothing for those who use it. I only use:

https://cloud.google.com/datastore/
https://cloud.google.com/storage/
https://cloud.google.com/sql/

Amazon and Microsoft have similar solutions.


> Just compile & upload? Isn't that the great part about having just one executable?

Yes... if it only was that easy. Anyway, if you succeed in attracting enough web developers then at some point it makes sense for consultants to maintain a cloud API layer. Until then it is really an uphill battle, but you can aim for niches (like game servers, text search engines etc).

> https://github.com/higgsjs/Higgs?

Doesn't look production ready at this point in time? Not a big deal, you can use a different server with V8 on it.