digitalmars.D.announce - How I Came to Write D -- by Walter Bright
- Andrei Alexandrescu (3/3) Apr 08 2014 http://www.reddit.com/r/programming/comments/22jwcu/how_i_came_to_write_...
- asman (6/9) Apr 08 2014 Wait a second. I think there's something wrong here. I've read
- Walter Bright (2/3) Apr 08 2014 Got any stock tips?
- John (3/4) Apr 11 2014 Yes, me too. I thought the AMA is just referring to an existing
- John (5/6) Apr 11 2014 I found where I read it.. I downloaded a PDF version of Languages
- Andrej Mitrovic (15/17) Apr 10 2014 As a contributor I take a different stance here. When Andrei/Walter or
- Walter Bright (2/18) Apr 10 2014 What can I say? This is awesome!
- Chris (14/14) Apr 11 2014 Walter: "I'll note here that working on stuff that I needed has
- Walter Bright (3/5) Apr 11 2014 Yeah, I like D far better than Java.
- Jordi Sayol (4/7) Apr 11 2014 +1000
- Bienlein (17/22) Apr 16 2014 So do I. But for Java there is Hibernate, Hadoop, Cassandra, DI,
- Chris (7/31) Apr 16 2014 I use vibe.d for a small server side application. It's quite
- =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= (5/40) Apr 16 2014 Are there any particular things that you could list from the top of your...
- Chris (21/77) Apr 16 2014 I will report them as soon as I come across one (I'm not working
- Bienlein (12/20) Apr 16 2014 If I see things right vibe.d is distributed. Channels and
- =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= (24/42) Apr 16 2014 What exactly do you mean exactly by? From what I gather about
- Bruno Medeiros (5/8) May 09 2014 Whoa, that's quite a few jobs already! (Given how relatively new Go is.....
- Brad Roberts (3/20) Apr 10 2014 My request for bug prioritization isn't new: regressions, blockers, and...
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (3/4) Apr 16 2014 Thanks, this was a fun read! :-)
- Bruno Medeiros (7/8) May 09 2014 "We were using C because it was the only high-level language we could
http://www.reddit.com/r/programming/comments/22jwcu/how_i_came_to_write_d/ http://goo.gl/32R36e Andrei
Apr 08 2014
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 AndreiWait 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
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
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
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
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
On 4/10/2014 10:44 AM, Andrej Mitrovic wrote:On 4/8/14, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:What can I say? This is awesome!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
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
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
El 11/04/14 12:10, Walter Bright ha escrit:+1000 -- Jordi Sayolbut hey, now we have D.Yeah, I like D far better than Java.
Apr 11 2014
On Tuesday, 15 April 2014 at 19:19:00 UTC, Jordi Sayol wrote:El 11/04/14 12:10, Walter Bright ha escrit: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+1000but hey, now we have D.Yeah, I like D far better than Java.
Apr 16 2014
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: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.El 11/04/14 12:10, Walter Bright ha escrit: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+1000but hey, now we have D.Yeah, I like D far better than Java.
Apr 16 2014
Am 16.04.2014 11:05, schrieb Chris:On Wednesday, 16 April 2014 at 08:21:37 UTC, Bienlein wrote: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.On Tuesday, 15 April 2014 at 19:19:00 UTC, Jordi Sayol wrote: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.El 11/04/14 12:10, Walter Bright ha escrit: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+1000but hey, now we have D.Yeah, I like D far better than Java.
Apr 16 2014
On Wednesday, 16 April 2014 at 09:10:47 UTC, Sönke Ludwig wrote:Am 16.04.2014 11:05, schrieb Chris: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.On Wednesday, 16 April 2014 at 08:21:37 UTC, Bienlein wrote: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.On Tuesday, 15 April 2014 at 19:19:00 UTC, Jordi Sayol wrote: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.El 11/04/14 12:10, Walter Bright ha escrit: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+1000but hey, now we have D.Yeah, I like D far better than Java.
Apr 16 2014
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 isbuilt 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
Am 16.04.2014 12:18, schrieb Bienlein: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.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<.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
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
On Wednesday, 16 April 2014 at 13:06:56 UTC, Bienlein wrote:Maybe we should "spawn" a new thread for this discussion. I'm sure this is of interest for everyone on this forum.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
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
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
On 4/10/14, 10:44 AM, Andrej Mitrovic wrote:On 4/8/14, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote: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.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
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
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