www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - dlang.org using apache?

reply Jonathan Marler <johnnymarler gmail.com> writes:
I've decided to write a web application using vibe and was 
shocked to see that dlang.org was using apache.

Should I be scared that even after this long, the official D 
website doesn't rely on its own web tools?
Jun 08 2016
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 09/06/2016 1:13 AM, Jonathan Marler wrote:

 I've decided to write a web application using vibe and was shocked to
 see that dlang.org was using apache.

 Should I be scared that even after this long, the official D website
 doesn't rely on its own web tools?


Why would we change over when Apache is working quite happily to serve 
up static content?
Jun 08 2016
prev sibling next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Wednesday, 8 June 2016 at 13:13:07 UTC, Jonathan Marler wrote:

 I've decided to write a web application using vibe and was 
 shocked to see that dlang.org was using apache.

 Should I be scared that even after this long, the official D 
 website doesn't rely on its own web tools?


No, you shouldn't. Like everything else, it's a matter of 
priorities and resources. Currently, code.dlang.org and 
tour.dlang.org both run on vibe.d, both of which were put 
together by community members. The forums here is Vladimir's 
DFeed, which he developed with his own web tools. There may yet 
come a time when someone converts dlang.org to a vibe.d web app, 
but it almost certainly isn't going to be any of the core team 
members. They have enough on their plate already.

Hell, if it's ever been brought up in the forums before now, I 
don't remember seeing it. While it would be great in terms of dog 
fooding to see such a project, I personally don't see that it's a 
big deal if dlang.org runs on Apache. Maybe if you've got some 
extra time... :)
Jun 08 2016
next sibling parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Wednesday, 8 June 2016 at 13:32:00 UTC, Mike Parker wrote:

 Why would we change over when Apache is working quite happily 
 to serve up static content?


I've heard that same argument as the reason people don't use the 
D language.  Why would I change over to D when C/C++ is working 
quite happily?

If the official D website doesn't feel like migrating it's own 
infrastructure to use D, why would anyone else?  Of course apache 
works (so does C++), but choosing not to put in the time to 
switch says a lot to the rest of the world.
Jun 08 2016
next sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 6/8/16 10:33 AM, Jonathan Marler wrote:

 On Wednesday, 8 June 2016 at 13:32:00 UTC, Mike Parker wrote:

 Why would we change over when Apache is working quite happily to serve
 up static content?


 I've heard that same argument as the reason people don't use the D
 language.  Why would I change over to D when C/C++ is working quite
 happily?

 If the official D website doesn't feel like migrating it's own
 infrastructure to use D, why would anyone else?  Of course apache works
 (so does C++), but choosing not to put in the time to switch says a lot
 to the rest of the world.


The concern trolling on this forum has been escalating lately. It's good 
that people are noticing D more!

-Steve
Jun 08 2016
prev sibling next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 8 June 2016 at 14:33:50 UTC, Jonathan Marler wrote:

 On Wednesday, 8 June 2016 at 13:32:00 UTC, Mike Parker wrote:

 Why would we change over when Apache is working quite happily 
 to serve up static content?


 I've heard that same argument as the reason people don't use 
 the D language.  Why would I change over to D when C/C++ is 
 working quite happily?

 If the official D website doesn't feel like migrating it's own 
 infrastructure to use D, why would anyone else?  Of course 
 apache works (so does C++), but choosing not to put in the time 
 to switch says a lot to the rest of the world.


Well, if this is the only area where it happens then it's ok.

But DMD also doesn't use the GC because it doesn't perform well 
enough. Stuff like this adds up.

So I agree with you in essence, sending the message that there 
are things to avoid is not good in the long run. It might be 
better to take a slight performance hit and use your own stuff 
and post a list of things you are working on to improve it.

I like the "are we fast yet" websites that various project put 
up, displaying improvements over time.
Jun 08 2016
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Wednesday, 8 June 2016 at 14:41:55 UTC, Ola Fosheim Grøstad 
wrote:


 But DMD also doesn't use the GC because it doesn't perform well 
 enough. Stuff like this adds up.

 So I agree with you in essence, sending the message that there 
 are things to avoid is not good in the long run. It might be 
 better to take a slight performance hit and use your own stuff 
 and post a list of things you are working on to improve it.

 I like the "are we fast yet" websites that various project put 
 up, displaying improvements over time.


What does that have to do with the website? The forum software is 
written in D and has a reputation for performance. This is simply 
a matter of it not popping up on anyone's radar and has nothing 
to do with the GC or performance hits.
Jun 08 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 8 June 2016 at 14:45:58 UTC, Mike Parker wrote:

 What does that have to do with the website? The forum software 
 is written in D and has a reputation for performance. This is 
 simply a matter of it not popping up on anyone's radar and has 
 nothing to do with the GC or performance hits.


Jonathan pointed out that people loose confidence when projects 
don't use their own tech if they have it. If this was just a 
single datapoint it would be a non-issue, but when it is a 
tendency, then it is a marketing issue.

The forum-index http header report:

Server:nginx/1.4.6 (Ubuntu)

People check out stuff like that. The forum backend also use a 
standard NNTP server, not implemented in D? That's ok too as 
there is no D forum software... but having many data-points like 
that is not good if you want to positions yourself as suitable 
for hosting websites.

Just like writing special cased memory management for DMD is not 
good marketing of D's ability to support fast memory management 
out of the box.

It is better to take a performance hit and show statistics of how 
you improve over time. People react more negatively to stagnation 
than absolute numbers.

People do notice. One data-point, ok. Many data-points, bad.
Jun 08 2016
next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Wednesday, 8 June 2016 at 15:05:54 UTC, Ola Fosheim Grøstad 
wrote:

 People check out stuff like that. The forum backend also use a 
 standard NNTP server, not implemented in D? That's ok too as 
 there is no D forum software...


it's even more than that: D servers are using OS which is not 
implemented in D!
Jun 08 2016
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 8 June 2016 at 15:18:27 UTC, ketmar wrote:

 On Wednesday, 8 June 2016 at 15:05:54 UTC, Ola Fosheim Grøstad 
 wrote:

 People check out stuff like that. The forum backend also use a 
 standard NNTP server, not implemented in D? That's ok too as 
 there is no D forum software...


 it's even more than that: D servers are using OS which is not 
 implemented in D!


If D had their own OS then that would have been an issue, yes. 
Just like if Redhat had used Debian on their servers. Oh... you 
were trying to be funny...? ha...
Jun 08 2016
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Wednesday, 8 June 2016 at 15:23:58 UTC, Ola Fosheim Grøstad 
wrote:

 On Wednesday, 8 June 2016 at 15:18:27 UTC, ketmar wrote:

 On Wednesday, 8 June 2016 at 15:05:54 UTC, Ola Fosheim Grøstad 
 wrote:

 People check out stuff like that. The forum backend also use 
 a standard NNTP server, not implemented in D? That's ok too 
 as there is no D forum software...


 it's even more than that: D servers are using OS which is not 
 implemented in D!


 If D had their own OS then that would have been an issue, yes. 
 Just like if Redhat had used Debian on their servers. Oh... you 
 were trying to be funny...? ha...


i'm trying to hint that there is no reason to reimplement 
*everything* in D. bad engineers reinvent, good engineers reuse!
Jun 08 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 8 June 2016 at 15:31:34 UTC, ketmar wrote:

 i'm trying to hint that there is no reason to reimplement 
 *everything* in D. bad engineers reinvent, good engineers reuse!


This is about marketing, not engineering.

Walter is arguing that vibe.d should be distributed with the 
compiler. If it is good enough to get semi-official status it 
makes you wonder why it isn't showcased on dlang.org?

Same thing with memory management. If memory management in D is 
not a problem, why is it then a problem to use the standard 
memory management in the official D compiler, a non-interactive 
batch-application?

Compare this to:
- We are using our own web framework, out-of-the-box, 
compile-and-run.
- We are using our own standard library/runtime, unmodified.

And it works great!
No need to dig deep to get decent performance!
Jun 08 2016
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Wednesday, 8 June 2016 at 15:40:48 UTC, Ola Fosheim Grøstad 
wrote:

 On Wednesday, 8 June 2016 at 15:31:34 UTC, ketmar wrote:

 i'm trying to hint that there is no reason to reimplement 
 *everything* in D. bad engineers reinvent, good engineers 
 reuse!


 This is about marketing, not engineering.


nope, it is about engineering. as long as D is not backed by some 
giant like google or apple, it is about engineering.
Jun 08 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 8 June 2016 at 15:52:06 UTC, ketmar wrote:

 On Wednesday, 8 June 2016 at 15:40:48 UTC, Ola Fosheim Grøstad 
 wrote:

 On Wednesday, 8 June 2016 at 15:31:34 UTC, ketmar wrote:

 i'm trying to hint that there is no reason to reimplement 
 *everything* in D. bad engineers reinvent, good engineers 
 reuse!


 This is about marketing, not engineering.


 nope, it is about engineering. as long as D is not backed by 
 some giant like google or apple, it is about engineering.


Huh? No, as long as D is not backed by some giant like Google or 
Apple it has to do its own marketing and showcase its own stuff 
where it can.

People are not looking for something that takes engineering to 
work well. They are looking for something that just-works and 
that they can build on from the get go.
Jun 08 2016
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Wednesday, 8 June 2016 at 15:57:42 UTC, Ola Fosheim Grøstad 
wrote:

 Huh? No, as long as D is not backed by some giant like Google 
 or Apple it has to do its own marketing and showcase its own 
 stuff where it can.


the key words are "where it can". rewriting already working tools 
(perfectly working) in D is "marketing for the marketing sake". 
if there are money to waste, an engineer can be hired to rewrite 
such tools. otherwise, it is much wiser to reuse existing ones.



 People are not looking for something that takes engineering to 
 work well. They are looking for something that just-works and 
 that they can build on from the get go.


so they should pass-by. D is the language to build tools, not 
some "batteries included" language. this is The Way to market it, 
i believe.
Jun 08 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 8 June 2016 at 16:07:26 UTC, ketmar wrote:

 On Wednesday, 8 June 2016 at 15:57:42 UTC, Ola Fosheim Grøstad 
 wrote:

 Huh? No, as long as D is not backed by some giant like Google 
 or Apple it has to do its own marketing and showcase its own 
 stuff where it can.


 the key words are "where it can". rewriting already working 
 tools (perfectly working) in D is "marketing for the marketing 
 sake". if there are money to waste, an engineer can be hired to 
 rewrite such tools. otherwise, it is much wiser to reuse 
 existing ones.


Yes, no point in writing your own forum software. However, if you 
need nginx to perform on a small scale site like dlang.org then 
you basically say that the D http stack is not yet competitive 
with C++.

Contrast that to:
- Vibe.d is so great that we don't need a front end to perform 
well.


 so they should pass-by. D is the language to build tools, not 
 some "batteries included" language. this is The Way to market 
 it, i believe.


Fair enough, maybe that is more honest, but it doesn't drive the 
project forward to a situation where it can showcase 
"download-compile-install" starting points.

And that is what most people want. Most people want to solve a 
specific problem. If you have something they can make work right 
away and then modify then you are more like to be adopted.
Jun 08 2016
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Wednesday, 8 June 2016 at 16:23:13 UTC, Ola Fosheim Grøstad 
wrote:

 Yes, no point in writing your own forum software.


ah, sure, there was the reason to write DFeed! that's why 
forum.dlang.org is using engine written in D.
Jun 08 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 8 June 2016 at 16:36:50 UTC, ketmar wrote:

 On Wednesday, 8 June 2016 at 16:23:13 UTC, Ola Fosheim Grøstad 
 wrote:

 Yes, no point in writing your own forum software.


 ah, sure, there was the reason to write DFeed! that's why 
 forum.dlang.org is using engine written in D.


DFeed is a NNTP client, not a NNTP server.

(NNTP is pretty much dead, so not much point in it, true. Was 
that your point? Or are you back into zealot-mode? :^)
Jun 08 2016
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Wednesday, 8 June 2016 at 16:40:37 UTC, Ola Fosheim Grøstad 
wrote:

 DFeed is a NNTP client, not a NNTP server.


sure. why should it be an NNTP server? there is task to solve: 
provide web frontend to the existing NNTP server. that task was 
solved. there was no task "waste some time to rewrite already 
working NNTP server software in D in the sake of rewriting".
Jun 08 2016
prev sibling parent reply dewitt <dkdewitt gmail.com> writes:
On Wednesday, 8 June 2016 at 15:18:27 UTC, ketmar wrote:

 On Wednesday, 8 June 2016 at 15:05:54 UTC, Ola Fosheim Grøstad 
 wrote:

 People check out stuff like that. The forum backend also use a 
 standard NNTP server, not implemented in D? That's ok too as 
 there is no D forum software...


 it's even more than that: D servers are using OS which is not 
 implemented in D!


Whats worse is the software running the power stations that power 
the servers that host the website aren't written in D.  Neither 
were the software that run the militaries that protect the 
interests of the locations where the servers live.  Obviously 
this means that D is useless and should die.
Jun 08 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 8 June 2016 at 16:28:54 UTC, dewitt wrote:

 On Wednesday, 8 June 2016 at 15:18:27 UTC, ketmar wrote:

 On Wednesday, 8 June 2016 at 15:05:54 UTC, Ola Fosheim Grøstad 
 wrote:

 People check out stuff like that. The forum backend also use 
 a standard NNTP server, not implemented in D? That's ok too 
 as there is no D forum software...


 it's even more than that: D servers are using OS which is not 
 implemented in D!


 Whats worse is the software running the power stations that 
 power the servers that host the website aren't written in D.  
 Neither were the software that run the militaries that protect 
 the interests of the locations where the servers live.  
 Obviously this means that D is useless and should die.


Yes, indeed, if golang was not showcased as a web server language 
then I would not even consider looking at it for the purpose.

They do of course use golang for their blog and make it available 
as a download.

As they _should_.
Jun 08 2016
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Wednesday, 8 June 2016 at 16:38:02 UTC, Ola Fosheim Grøstad 
wrote:

 They do of course use golang for their blog and make it 
 available as a download.

 As they _should_.


google. money. does that rings the bell?
Jun 08 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 8 June 2016 at 16:44:00 UTC, ketmar wrote:

 On Wednesday, 8 June 2016 at 16:38:02 UTC, Ola Fosheim Grøstad 
 wrote:

 They do of course use golang for their blog and make it 
 available as a download.

 As they _should_.


 google. money. does that rings the bell?


No. The go blog software is very small, <400 lines of code.

If you use vibe.d for development as it has been said then it 
makes people wonder even more why it isn't deployed.

srsly.

Showcase your own stuff, nobody else are likely to do it.
Jun 08 2016
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Wednesday, 8 June 2016 at 16:49:46 UTC, Ola Fosheim Grøstad 
wrote:

 On Wednesday, 8 June 2016 at 16:44:00 UTC, ketmar wrote:

 On Wednesday, 8 June 2016 at 16:38:02 UTC, Ola Fosheim Grøstad 
 wrote:

 They do of course use golang for their blog and make it 
 available as a download.

 As they _should_.


 google. money. does that rings the bell?


 No. The go blog software is very small, <400 lines of code.


go write it! nope? why do you think that D devs should? they have 
other work to do, it would be *stupid* to not reuse existing 
tools.

google. money.
Jun 08 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 8 June 2016 at 16:53:32 UTC, ketmar wrote:

 go write it! nope? why do you think that D devs should? they 
 have other work to do, it would be *stupid* to not reuse 
 existing tools.


If I thought that D was good for the purpose, I would. I have not 
made such claims. I am pointing out that those who claim that D 
is suitable for a particular field should be expected to 
demonstrate it on their own turf.

It _does_ not take a lot of effort, if it is as good as is being 
claimed.
If it takes a lot of effort, then why should I bother with it?

You need to understand that you are contradicting the claims that 
are being made about D by not actually being willing to showcase 
it.

This is very basic marketing 101.

Not expensive.

Belive in something? Showcase it on your own lawn, house, car, 
website...
Jun 08 2016
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Wednesday, 8 June 2016 at 16:58:31 UTC, Ola Fosheim Grøstad 
wrote:

 This is very basic marketing 101.


engineers doesn't do marketing. engineers solving tasks.
Jun 08 2016
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
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.
Jun 08 2016
parent reply Jonathan Marler <johnnymarler gmail.com> writes:
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.
Jun 08 2016
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 8 June 2016 at 17:05:42 UTC, Jonathan Marler wrote:

 I can picture the article now:


I can't. It is an industry-standard deployment with a commonly 
used configuration option - people change that all the time. PHP, 
for example, will modify it to output something like this:

Server: Apache/2.4.6 (Unix) PHP/5.4.20

when you use it - they append their brand to the existing string.


The only articles I have ever seen about this is people saying 
you should blank it out to make script kiddies have a harder time 
figuring out just which version you have installed - people 
SUGGEST that you obscure it!


BTW, when I see a live server running a custom httpd, I tend to 
have a negative reaction: the sysadmin is lazy and didn't 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.

There's a difference between an application server and a frontend 
web server.
Jun 08 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
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.
Jun 08 2016
next sibling parent reply dewitt <dkdewitt gmail.com> writes:
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..
Jun 08 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
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.
Jun 08 2016
parent reply Seb <seb wilzba.ch> writes:
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?
Jun 08 2016
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
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.
Jun 08 2016
prev sibling parent reply Seb <seb wilzba.ch> writes:
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
Jun 08 2016
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
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
...
Jun 08 2016
prev sibling next sibling parent dewitt <dkdewitt gmail.com> writes:
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.





A lot of languages have a web framework that sits behind a server 
written in a different language.  .NET powers a ton of sites and 
applications and usually runs on IIS which is written in C++.  
Also if I were to use vibe then I would prolly run it behind a 
reverse proxy like nginx.  This is actually pretty standard way 
of deploying apps like say a Django, Flask, etc.... Nothing wrong 
with that and that by no means makes Python a useless language 
for the web.  Even Digital Oceans guide for Node and Python apps 
have you setup nginx as a reverse proxy.  Also Plays uguide shows 
how to setup nginx as a proxy.
Jun 08 2016
prev sibling parent reply Seb <seb wilzba.ch> writes:
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!
Jun 08 2016
parent Jonathan Marler <johnnymarler gmail.com> writes:
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.
Jun 08 2016
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Wednesday, 8 June 2016 at 15:05:54 UTC, Ola Fosheim Grøstad 
wrote:

 On Wednesday, 8 June 2016 at 14:45:58 UTC, Mike Parker wrote:

 What does that have to do with the website? The forum software 
 is written in D and has a reputation for performance. This is 
 simply a matter of it not popping up on anyone's radar and has 
 nothing to do with the GC or performance hits.


 Jonathan pointed out that people loose confidence when projects 
 don't use their own tech if they have it. If this was just a 
 single datapoint it would be a non-issue, but when it is a 
 tendency, then it is a marketing issue.


I was specifically referencing the bit you chopped out in the 
quote about GC and bad performance. I understood Jonathan's 
argument just fine (though I disagree with it). I didn't 
understand yours.

At any rate, we *are* using our own tech in several places. And I 
think Seb has shown that in practice, it probably isn't that big 
a deal that the entire website isn't served by a D project.
Jun 08 2016
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 8 June 2016 at 16:58:42 UTC, Mike Parker wrote:

 At any rate, we *are* using our own tech in several places. And 
 I think Seb has shown that in practice, it probably isn't that 
 big a deal that the entire website isn't served by a D project.


If you want to convince me, as a backend web developer, that you 
have something worth looking at you have to showcase the result 
and also provide the source code for it. Ideally I should be able 
to download the source from github and get something similar 
running with little effort. If I have to write lots of code for 
things that are basic, then it isn't interesting to me.

Same thing for the compiler. I look at it in order to find out 
how D can be used in a larger project. If I find that you bypass 
the runtime in order to perform and revert to manual raw-pointer 
memory management, then it isn't interesting to me.

Same thing with standard library. I look at it to see how real 
world programming in D (by language experts) turns out.

The only reason I am starting to adopt Go for backend is that 
they showcase that the things I want to do can done with concise 
source code. Without such real world showcases I would most 
likely not even consider it.
Jun 08 2016
prev sibling parent reply Brad Anderson <eco gnuk.net> writes:
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/
Jun 08 2016
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
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)
Jun 08 2016
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Wednesday, 8 June 2016 at 14:33:50 UTC, Jonathan Marler wrote:

 On Wednesday, 8 June 2016 at 13:32:00 UTC, Mike Parker wrote:

 Why would we change over when Apache is working quite happily 
 to serve up static content?




I didn't say that. Rikki did :)



 If the official D website doesn't feel like migrating it's own 
 infrastructure to use D, why would anyone else?  Of course 
 apache works (so does C++), but choosing not to put in the time 
 to switch says a lot to the rest of the world.


Really? I just don't see it as that big of a deal. Again, three 
subdomains are using D right now. So it's not like it's not being 
used at all. Moving the website to D just hasn't been a priority 
(nor should it be, IMO). Anyone in the community who *does* feel 
it's important is certainly free to put together a prototype and 
pitch it to the core team. I would ask their thoughts about it 
first, though, before embarking on such a project.
Jun 08 2016
parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Wednesday, 8 June 2016 at 14:43:35 UTC, Mike Parker wrote:

 Really? I just don't see it as that big of a deal. Again, three 
 subdomains are using D right now. So it's not like it's not 
 being used at all. Moving the website to D just hasn't been a 
 priority (nor should it be, IMO). Anyone in the community who 
 *does* feel it's important is certainly free to put together a 
 prototype and pitch it to the core team. I would ask their 
 thoughts about it first, though, before embarking on such a 
 project.


I can definitely see and relate to your points.  You're using 
sound arguments when making decisions about software in general.  
However, I think you have to consider the emotional impact of 
this.  If you walked into a printer company and found out they 
didn't use their own printers, what would that say to you?  Since 
dlang.org is the face of the D programming language, it's going 
to be the first thing people use to judge it.  IMO that makes it 
a big deal.
Jun 08 2016
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 8 June 2016 at 14:57:11 UTC, Jonathan Marler wrote:

 However, I think you have to consider the emotional impact of 
 this.


nodejs.org's homepage is served by nginx. D is general purpose, 
node is specifically web.

Nobody seems to care (probably because using nginx is the 
recommended way to do a production deployment anyway!)
Jun 08 2016
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 8 June 2016 at 15:04:24 UTC, Adam D. Ruppe wrote:

 On Wednesday, 8 June 2016 at 14:57:11 UTC, Jonathan Marler 
 wrote:

 However, I think you have to consider the emotional impact of 
 this.


 nodejs.org's homepage is served by nginx. D is general purpose, 
 node is specifically web.

 Nobody seems to care (probably because using nginx is the 
 recommended way to do a production deployment anyway!)


Node.js is widely deployed, they don't need any marketing or 
showcases. Vibe.d and D does.

That is a major difference.
Jun 08 2016
prev sibling parent Seb <seb wilzba.ch> writes:
On Wednesday, 8 June 2016 at 13:32:00 UTC, Mike Parker wrote:

 On Wednesday, 8 June 2016 at 13:13:07 UTC, Jonathan Marler 
 wrote:

 I've decided to write a web application using vibe and was 
 shocked to see that dlang.org was using apache.

 Should I be scared that even after this long, the official D 
 website doesn't rely on its own web tools?


 No, you shouldn't. Like everything else, it's a matter of 
 priorities and resources. Currently, code.dlang.org and 
 tour.dlang.org both run on vibe.d, both of which were put 
 together by community members. The forums here is Vladimir's 
 DFeed, which he developed with his own web tools. There may yet 
 come a time when someone converts dlang.org to a vibe.d web 
 app, but it almost certainly isn't going to be any of the core 
 team members. They have enough on their plate already.


Btw for development dlang.org uses vibed since 2.5 years ;-)

```
make -f posix.mak apidocs-serve
```

It will run ddox on every request.


 Hell, if it's ever been brought up in the forums before now, I 
 don't remember seeing it. While it would be great in terms of 
 dog fooding to see such a project, I personally don't see that 
 it's a big deal if dlang.org runs on Apache. Maybe if you've 
 got some extra time... :)



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!
Jun 08 2016
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 8 June 2016 at 13:13:07 UTC, Jonathan Marler wrote:

 I've decided to write a web application using vibe and was 
 shocked to see that dlang.org was using apache.


It is very common for real world web apps to run behind Apache, 
nginx, IIS, or another major production server.

These servers tend to be very efficient at front end tasks like 
load balancing, static file serving and cache management, 
standards compliance (including automatically up/down grading 
HTTP versions or TLS requirements), management, security 
(including handling horribly malformed requests) - stuff that can 
take megabytes of code to get right and is typically outside the 
scope of an application server.

Of course, they can also serve up different parts of a large 
website to different application servers transparently to the end 
user - e.g. one part in PHP, another part proxied to vibe.


BTW ironically, a lot of people complain that D DOES use its own 
web technology on the website: it is mostly statically generated 
ddoc!
Jun 08 2016
parent Jonathan Marler <johnnymarler gmail.com> writes:
On Wednesday, 8 June 2016 at 14:30:53 UTC, Adam D. Ruppe wrote:

 These servers tend to be very efficient at front end tasks like 
 load balancing, static file serving and cache management, 
 standards compliance (including automatically up/down grading 
 HTTP versions or TLS requirements), management, security 
 (including handling horribly malformed requests) - stuff that 
 can take megabytes of code to get right and is typically 
 outside the scope of an application server.


That's actually the reason I would think dlang.org should use 
vibe.  Those features are critical to the success and viability 
of vibe.  By making dlang.org dependent on vibe, those features 
are much more likely to be flushed out and maintained at a high 
standard.


 BTW ironically, a lot of people complain that D DOES use its 
 own web technology on the website: it is mostly statically 
 generated ddoc!


I saw some discussion on that in the forums when I was searching 
for info on why dlang.org doesn't use vibe.  I personally like 
that dlang uses ddoc, but I don't know too much about the 
realistic pros and cons.  I do like the concept though.
Jun 08 2016