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/
Btw, w.r.t. #2:
 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/
Btw, w.r.t. #2:
 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/
Btw, w.r.t. #2:
 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