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

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

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.

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.

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.

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! :-)

> 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.

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?

> 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

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.