www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - How I Came to Write D -- by Walter Bright

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
http://www.reddit.com/r/programming/comments/22jwcu/how_i_came_to_write_d/

http://goo.gl/32R36e


Andrei
Apr 08 2014
next sibling parent reply "asman" <lol.themask gmail.com> writes:
On Tuesday, 8 April 2014 at 21:44:24 UTC, Andrei Alexandrescu 
wrote:

 http://www.reddit.com/r/programming/comments/22jwcu/how_i_came_to_write_d/

 http://goo.gl/32R36e


 Andrei


Wait a second. I think there's something wrong here. I've read 
this article several days ago! I claimed this one wasn't in 
http://www.drdobbs.com/authors/Walter-Bright
The single one sane explanation is I actually came from future.
Apr 08 2014
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/8/2014 7:28 PM, asman wrote:

 The single one sane explanation is I actually came from future.


Got any stock tips?
Apr 08 2014
prev sibling next sibling parent "John" <john.joyus gmail.com> writes:
 I've read this article several days ago!


Yes, me too. I thought the AMA is just referring to an existing 
article.. but the date on that article is new! (I was scratching 
my head on that..)
Apr 11 2014
prev sibling parent "John" <john.joyus gmail.com> writes:
On Wednesday, 9 April 2014 at 02:28:16 UTC, asman wrote:

 I've read this article several days ago!


I found where I read it.. I downloaded a PDF version of Languages 
Dr.Dobb's Journal February 2014 edition, and this article was 
published in that.

Anyway, it's a great article, worth reading it twice.
Apr 11 2014
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 4/8/14, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:

 http://www.reddit.com/r/programming/comments/22jwcu/how_i_came_to_write_d/





 W.B.: I've had to learn how to manage a project where people are all
volunteers. Since I don't pay anybody anything, I can't tell anybody to do
anything.


As a contributor I take a different stance here. When Andrei/Walter or
someone from the "higher ranks" asks me about working on a specific
feature or pull I'll be ready to jump on it as soon as possible. To me
the issue was never about finding what to work on, but prioritizing
what's important.

So I wouldn't necessarily say that requesting someone to work on
something would look bad or be perceived as wanting that someone to do
work for free. I think there's plenty of us here who are eager to work
on things.

I know Andrei said he already tried to ask some members of the
community to work on some issues, to no avail. I don't know which
issues they were though, but if I'm involved in any of them just ping
me and I'll jump to work ASAP.
Apr 10 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/10/2014 10:44 AM, Andrej Mitrovic wrote:

 On 4/8/14, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:

 http://www.reddit.com/r/programming/comments/22jwcu/how_i_came_to_write_d/





 W.B.: I've had to learn how to manage a project where people are all
 volunteers. Since I don't pay anybody anything, I can't tell anybody to do
 anything.


 As a contributor I take a different stance here. When Andrei/Walter or
 someone from the "higher ranks" asks me about working on a specific feature
 or pull I'll be ready to jump on it as soon as possible. To me the issue was
 never about finding what to work on, but prioritizing what's important.

 So I wouldn't necessarily say that requesting someone to work on something
 would look bad or be perceived as wanting that someone to do work for free. I
 think there's plenty of us here who are eager to work on things.

 I know Andrei said he already tried to ask some members of the community to
 work on some issues, to no avail. I don't know which issues they were though,
 but if I'm involved in any of them just ping me and I'll jump to work ASAP.


What can I say? This is awesome!
Apr 10 2014
parent reply "Chris" <wendlec tcd.ie> writes:
Walter: "I'll note here that working on stuff that I needed has 
fared quite a bit better than working on stuff that I was told 
others need."

This has also been my experience, that you should do what you 
feel is right, what really makes you happy. Had I heeded all the 
advice I've been given about how "useful" and "useless" this and 
that is, I wouldn't be where I am now. Practically everything I 
went for was considered "useless". I know far too many people who 
did what was once considered useful (i.e. "where the money is"), 
and ended up being completely unhappy. There will always be 
people like the C Guru (he probably wasn't one), but never mind 
them. Go where your heart says.

I would have liked to have a Java native compiler though, but 
hey, now we have D.
Apr 11 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/11/2014 2:06 AM, Chris wrote:

 I would have liked to have a Java native compiler though,


You're probably the only one :-)



 but hey, now we have D.


Yeah, I like D far better than Java.
Apr 11 2014
parent reply Jordi Sayol <g.sayol yahoo.es> writes:
El 11/04/14 12:10, Walter Bright ha escrit:


 but hey, now we have D.


 
 Yeah, I like D far better than Java.


+1000

-- 
Jordi Sayol
Apr 11 2014
parent reply "Bienlein" <jeti789 web.de> writes:
On Tuesday, 15 April 2014 at 19:19:00 UTC, Jordi Sayol wrote:

 El 11/04/14 12:10, Walter Bright ha escrit:


 but hey, now we have D.


 
 Yeah, I like D far better than Java.


 +1000


So do I. But for Java there is Hibernate, Hadoop, Cassandra, DI, 
JSF, JMS, JTA, SOAP, REST, vert.x, Quartz, web servers, 
application servers, various NoSQL-DBs and I don't know what. As 
you most often need some of those things in enterprise computing 
I'm pretty much bound to Java.

There are a number of job adds for Go developers (see 
http://golangprojects.com). Go seems to be a good complement for 
Ruby, Python, PHP which are slow and have bad concurrency. Then 
Go seems to appeal to companies whose product is some server-side 
application (like some cloud offering or PaaS).

I believe D could also play well in this server-side arena like 
Go. Maybe with the FiberScheduler developed by Sean Kelly D can 
also offer "dead-simple" concurrency and be appealing to 
developing cloud solutions or other style of server-side 
applications for which easy concurrency is a big plus.

-- Bienlein
Apr 16 2014
next sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Wednesday, 16 April 2014 at 08:21:37 UTC, Bienlein wrote:

 On Tuesday, 15 April 2014 at 19:19:00 UTC, Jordi Sayol wrote:

 El 11/04/14 12:10, Walter Bright ha escrit:


 but hey, now we have D.


 
 Yeah, I like D far better than Java.


 +1000


 So do I. But for Java there is Hibernate, Hadoop, Cassandra, 
 DI, JSF, JMS, JTA, SOAP, REST, vert.x, Quartz, web servers, 
 application servers, various NoSQL-DBs and I don't know what. 
 As you most often need some of those things in enterprise 
 computing I'm pretty much bound to Java.

 There are a number of job adds for Go developers (see 
 http://golangprojects.com). Go seems to be a good complement 
 for Ruby, Python, PHP which are slow and have bad concurrency. 
 Then Go seems to appeal to companies whose product is some 
 server-side application (like some cloud offering or PaaS).

 I believe D could also play well in this server-side arena like 
 Go. Maybe with the FiberScheduler developed by Sean Kelly D can 
 also offer "dead-simple" concurrency and be appealing to 
 developing cloud solutions or other style of server-side 
 applications for which easy concurrency is a big plus.

 -- Bienlein


I use vibe.d for a small server side application. It's quite 
fast, although we haven't tested it on a larger scale yet. On the 
downside, vibe.d's API is not quite intuitive, so it takes a 
while to get used to it. But that might be down to the fact that 
it's not easy to write an intuitive API for the web with all the 
different bits and pieces that have different logics to them.
Apr 16 2014
next sibling parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org> writes:
Am 16.04.2014 11:05, schrieb Chris:

 On Wednesday, 16 April 2014 at 08:21:37 UTC, Bienlein wrote:

 On Tuesday, 15 April 2014 at 19:19:00 UTC, Jordi Sayol wrote:

 El 11/04/14 12:10, Walter Bright ha escrit:


 but hey, now we have D.


 Yeah, I like D far better than Java.


 +1000


 So do I. But for Java there is Hibernate, Hadoop, Cassandra, DI, JSF,
 JMS, JTA, SOAP, REST, vert.x, Quartz, web servers, application
 servers, various NoSQL-DBs and I don't know what. As you most often
 need some of those things in enterprise computing I'm pretty much
 bound to Java.

 There are a number of job adds for Go developers (see
 http://golangprojects.com). Go seems to be a good complement for Ruby,
 Python, PHP which are slow and have bad concurrency. Then Go seems to
 appeal to companies whose product is some server-side application
 (like some cloud offering or PaaS).

 I believe D could also play well in this server-side arena like Go.
 Maybe with the FiberScheduler developed by Sean Kelly D can also offer
 "dead-simple" concurrency and be appealing to developing cloud
 solutions or other style of server-side applications for which easy
 concurrency is a big plus.

 -- Bienlein


 I use vibe.d for a small server side application. It's quite fast,
 although we haven't tested it on a larger scale yet. On the downside,
 vibe.d's API is not quite intuitive, so it takes a while to get used to
 it. But that might be down to the fact that it's not easy to write an
 intuitive API for the web with all the different bits and pieces that
 have different logics to them.


Are there any particular things that you could list from the top of your 
head? Making thinkgs as clear and simple as possible is one of the prime 
goals, but sometimes there are unfortunately compromises necessary in 
the name of performance or safety.
Apr 16 2014
parent "Chris" <wendlec tcd.ie> writes:
On Wednesday, 16 April 2014 at 09:10:47 UTC, Sönke Ludwig wrote:

 Am 16.04.2014 11:05, schrieb Chris:

 On Wednesday, 16 April 2014 at 08:21:37 UTC, Bienlein wrote:

 On Tuesday, 15 April 2014 at 19:19:00 UTC, Jordi Sayol wrote:

 El 11/04/14 12:10, Walter Bright ha escrit:


 but hey, now we have D.


 Yeah, I like D far better than Java.


 +1000


 So do I. But for Java there is Hibernate, Hadoop, Cassandra, 
 DI, JSF,
 JMS, JTA, SOAP, REST, vert.x, Quartz, web servers, application
 servers, various NoSQL-DBs and I don't know what. As you most 
 often
 need some of those things in enterprise computing I'm pretty 
 much
 bound to Java.

 There are a number of job adds for Go developers (see
 http://golangprojects.com). Go seems to be a good complement 
 for Ruby,
 Python, PHP which are slow and have bad concurrency. Then Go 
 seems to
 appeal to companies whose product is some server-side 
 application
 (like some cloud offering or PaaS).

 I believe D could also play well in this server-side arena 
 like Go.
 Maybe with the FiberScheduler developed by Sean Kelly D can 
 also offer
 "dead-simple" concurrency and be appealing to developing cloud
 solutions or other style of server-side applications for 
 which easy
 concurrency is a big plus.

 -- Bienlein


 I use vibe.d for a small server side application. It's quite 
 fast,
 although we haven't tested it on a larger scale yet. On the 
 downside,
 vibe.d's API is not quite intuitive, so it takes a while to 
 get used to
 it. But that might be down to the fact that it's not easy to 
 write an
 intuitive API for the web with all the different bits and 
 pieces that
 have different logics to them.


 Are there any particular things that you could list from the 
 top of your head? Making thinkgs as clear and simple as 
 possible is one of the prime goals, but sometimes there are 
 unfortunately compromises necessary in the name of performance 
 or safety.


I will report them as soon as I come across one (I'm not working 
with vibe.d at the moment). Off the top of my head I found the 
Json method "get" a bit strange

j["name"].get!string == "Example"

i.e. that you have to convert in this way. I expected string type 
to be the default, i.e.

j["name"].get() or get(j["name"]) without explicit conversion. 
Part of the "difficulties" I encountered was that the user has to 
click his/her way through all the structs etc to get to the 
point. E.g. if you go to

http://vibed.org/api/vibe.data.json/

you hear about "get", and if you want to know more about get, you 
have to go to

http://vibed.org/api/vibe.data.json/Json

to read about it in more detail. And then you have to click on 
"get" if you want to see the method's signature.

If you have to look up many things at the same time (as you 
would, when you build a server infrastructure), you have to go 
back and forth a lot, in many tabs in your browser, and I 
sometimes just lose track of where everything was.
Apr 16 2014
prev sibling parent reply "Bienlein" <jeti789 web.de> writes:
 I use vibe.d for a small server side application. It's quite 
 fast, although we haven't tested it on a larger scale yet. On 
 the downside, vibe.d's API is not quite intuitive, so it takes 
 a while to get used to it. But that might be down to the fact 
 that it's not easy to write an intuitive API for the web with 
 all the different bits and pieces that have different logics to 
 them.


If I see things right vibe.d is distributed. Channels and 
goroutines in Go aren't! It's just concurrency being very simple 
through the use of goroutines and channels that makes Go 
appealing to things that by nature use to be concurrent.

In Java there is vert.x, which is pretty much the same thing as 
vibe.d. But the success in using Go for server-side applications 
comes from plain local concurrency being simple the way it is 

built into the language<.


I don't see any system for Go that comes close to vibe.d or 
vert.x. What makes the difference is that concurrency as such is 
in the language and through the use of CSP has become very easy 
to use. Making concurrency in D very easy >in the D language< is 
what would IMHO make the difference.
Apr 16 2014
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org> writes:
Am 16.04.2014 12:18, schrieb Bienlein:

 I use vibe.d for a small server side application. It's quite fast,
 although we haven't tested it on a larger scale yet. On the downside,
 vibe.d's API is not quite intuitive, so it takes a while to get used
 to it. But that might be down to the fact that it's not easy to write
 an intuitive API for the web with all the different bits and pieces
 that have different logics to them.


 If I see things right vibe.d is distributed. Channels and goroutines in
 Go aren't! It's just concurrency being very simple through the use of
 goroutines and channels that makes Go appealing to things that by nature
 use to be concurrent.


What exactly do you mean exactly by? From what I gather about 
goroutines, the concept is very similar actually.

When talking about the HTTP server component, incoming requests are 
distributed among different "tasks", where a "task" is the equivalent of 
a goroutine (basically a fiber in Druntime terms). Optionally, these 
tasks can also live in different threads to improve performance (at the 
expense of making inter task communication more expensive/complex).

There are currently no channels exposed like they are in Go, but there 
is the concurrency module for inter-task message passing.


 In Java there is vert.x, which is pretty much the same thing as vibe.d.
 But the success in using Go for server-side applications comes from
 plain local concurrency being simple the way it is >built into the
 language<.


Vert.x actually uses a very different approach to dealing with 
concurrency. It basically uses asynchronous I/O only for handling 
incoming connections and then continues to use a thread pool to deal 
with concurrency in a classical thread based approach. Vibe.d always 
uses asynchronous I/O dispatched to any number of quasi-parallel tasks 
that appear to have normal control flow.

On the other hand, I don't think there is a significant difference 
between Go and vibe.d when it comes to language vs. library. The only 
exception that I can think of right now may be that you have to use 
TaskLocal!T for creating task local variables as opposed to having a 
built-in syntax. But AFAIR global variables in Go are always "shared", 
so that doesn't really count either.


 I don't see any system for Go that comes close to vibe.d or vert.x. What
 makes the difference is that concurrency as such is in the language and
 through the use of CSP has become very easy to use. Making concurrency
 in D very easy >in the D language< is what would IMHO make the difference.


Can you give a concrete example of what features would be easier if it 
was built-in?
Apr 16 2014
parent reply "Bienlein" <jeti789 web.de> writes:
 Can you give a concrete example of what features would be 
 easier if it was built-in?


My point is that multi-threading/concurrency should be very 
simple. Go has channels and goroutines and that's it. That does 
not make concurrency simple, but a lot simpler than when using 
locks, semaphores, mutexes, etc. D already has some very nice 
actor-style approach towards concurrency, which also offers a 
very nice simple approach towards concurrency.

What Go can offer is something like "spawn as many thousand 
threads as you like". This is independent of vibe.d, vert.x or 
whatever. At least on my machine I cannot spawn more than 5000 D 
kernel threads as the machine runs out of resources. Being able 
to spawn as many thousand threads as needed without caring about 
it seems to be an impotant aspect for being an interesting 
offering for developing server-side software. As I already said 
the FiberScheduler by Sean Kelly could achieve something in that 
direction. That would make a big difference for using D for 
server-side applications beyond the argument of being more 
productive than C++.

-- Bienlein
Apr 16 2014
parent reply "Chris" <wendlec tcd.ie> writes:
On Wednesday, 16 April 2014 at 13:06:56 UTC, Bienlein wrote:

 Can you give a concrete example of what features would be 
 easier if it was built-in?


 My point is that multi-threading/concurrency should be very 
 simple. Go has channels and goroutines and that's it. That does 
 not make concurrency simple, but a lot simpler than when using 
 locks, semaphores, mutexes, etc. D already has some very nice 
 actor-style approach towards concurrency, which also offers a 
 very nice simple approach towards concurrency.

 What Go can offer is something like "spawn as many thousand 
 threads as you like". This is independent of vibe.d, vert.x or 
 whatever. At least on my machine I cannot spawn more than 5000 
 D kernel threads as the machine runs out of resources. Being 
 able to spawn as many thousand threads as needed without caring 
 about it seems to be an impotant aspect for being an 
 interesting offering for developing server-side software. As I 
 already said the FiberScheduler by Sean Kelly could achieve 
 something in that direction. That would make a big difference 
 for using D for server-side applications beyond the argument of 
 being more productive than C++.

 -- Bienlein


Maybe we should "spawn" a new thread for this discussion. I'm 
sure this is of interest for everyone on this forum.
Apr 16 2014
parent "Bienlein" <jeti789 web.de> writes:
On Wednesday, 16 April 2014 at 13:42:26 UTC, Chris wrote:


 Maybe we should "spawn" a new thread for this discussion. I'm 
 sure this is of interest for everyone on this forum.


All right, here we go:
http://forum.dlang.org/thread/khismekcvlbvvyappyot forum.dlang.org#post-khismekcvlbvvyappyot:40forum.dlang.org
Apr 16 2014
prev sibling parent Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 16/04/2014 09:21, Bienlein wrote:

 There are a number of job adds for Go developers (see
 http://golangprojects.com). Go seems to be a good complement for Ruby,
 Python, PHP which are slow and have bad concurrency.


Whoa, that's quite a few jobs already! (Given how relatively new Go is...)

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
May 09 2014
prev sibling next sibling parent Brad Roberts <braddr puremagic.com> writes:
On 4/10/14, 10:44 AM, Andrej Mitrovic wrote:

 On 4/8/14, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:

 http://www.reddit.com/r/programming/comments/22jwcu/how_i_came_to_write_d/





 W.B.: I've had to learn how to manage a project where people are all
volunteers. Since I don't pay anybody anything, I can't tell anybody to do
anything.


 As a contributor I take a different stance here. When Andrei/Walter or
 someone from the "higher ranks" asks me about working on a specific
 feature or pull I'll be ready to jump on it as soon as possible. To me
 the issue was never about finding what to work on, but prioritizing
 what's important.

 So I wouldn't necessarily say that requesting someone to work on
 something would look bad or be perceived as wanting that someone to do
 work for free. I think there's plenty of us here who are eager to work
 on things.

 I know Andrei said he already tried to ask some members of the
 community to work on some issues, to no avail. I don't know which
 issues they were though, but if I'm involved in any of them just ping
 me and I'll jump to work ASAP.


My request for bug prioritization isn't new:  regressions, blockers, and majors
-- in that order. 
The number of open bugs that fall into those three severity levels is
depressing.
Apr 10 2014
prev sibling next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 8 April 2014 at 21:44:24 UTC, Andrei Alexandrescu 
wrote:

 http://www.reddit.com/r/programming/comments/22jwcu/how_i_came_to_write_d/


Thanks, this was a fun read! :-)
Apr 16 2014
prev sibling parent Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 08/04/2014 22:44, Andrei Alexandrescu wrote:

 http://www.reddit.com/r/programming/comments/22jwcu/how_i_came_to_write_d/


"We were using C because it was the only high-level language we could 
find that actually worked on the PC."

"C" + "high-level"... those where different times indeed! :)

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
May 09 2014