On Wednesday, 6 November 2013 at 08:22:36 UTC, Bienlein wrote:
> ..
> Lightweight Threads in Go and Rust
>
> What is a *BIG* plus for Go and Rust are lightweight threads. You
> can spawn some thousand of them and it's no problem. I really
> wished D had that kind of threads as well. For nowaydays
> server-side development where applications need to bear heavy
> load and load peaks this is an important thing.
>
> -- Bienlein

Which are also available in many JVM implementations and in .NET as tasks and asynch.

Although, it is nice PR for HN guys that ignore what these platforms offer.

--
Paulo

On Wednesday, 6 November 2013 at 08:22:36 UTC, Bienlein wrote:
> Lightweight Threads in Go and Rust
>
> What is a *BIG* plus for Go and Rust are lightweight threads. You
> can spawn some thousand of them and it's no problem. I really
> wished D had that kind of threads as well. For nowaydays
> server-side development where applications need to bear heavy
> load and load peaks this is an important thing.

Use std.parallelism.Task or core.thread.Fiber. This is also conveniently packaged in Vibe.d. They have some syntactic sugar, though.

> Which are also available in many JVM implementations and in .NET as tasks and asynch.
>
> Although, it is nice PR for HN guys that ignore what these platforms offer.

I'm sure about that. When you block a thread in Java it is no
longer available for the thread pool and increasing the size of
it cannot be done at will, because creating new threads is not
lightweigt on the JVM.

There is a CSP implemention for Java made by some English
university: http://www.cs.kent.ac.uk/projects/ofa/jcsp/ Groovy
CSP makes use of it:
http://www.gpars.org/1.0.0/guide/guide/GroovyCSP.html But I
haven't tried what happens when you block threads.

On Wednesday, 6 November 2013 at 10:10:06 UTC, Bienlein wrote:
>> Which are also available in many JVM implementations and in .NET as tasks and asynch.
>>
>> Although, it is nice PR for HN guys that ignore what these platforms offer.
>
> I'm sure about that. When you block a thread in Java it is no
> longer available for the thread pool and increasing the size of
> it cannot be done at will, because creating new threads is not
> lightweigt on the JVM.

Ah, unhappily Groovy CSP also can't do this: "Some
implementations (e.g. GoLang) can also detach the thread from the
CSP process when blocked on a channel." Source:
http://www.gpars.org/1.0.0/guide/guide/GroovyCSP.html So it's
basically non-blocking IO.

-- Bienlein

Am 05.11.2013 21:33, schrieb Dicebot:
> On Tuesday, 5 November 2013 at 19:57:07 UTC, Walter Bright wrote:
>>> - I ran into another dmd bug (it crashed) at one point if -inline was
>>> used.
>
> At least this one will be fixed in 2.064

Are you sure? There are still 5 open ICE-bugs with -inline

https://d.puremagic.com/issues/buglist.cgi?query_format=advanced&short_desc=-inline%20ICE&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&short_desc_type=allwordssubstr&component=DMD&product=D

-- 
Kind Regards
Benjamin Thaut

On Wednesday, 6 November 2013 at 11:27:04 UTC, Benjamin Thaut wrote:
> Are you sure? There are still 5 open ICE-bugs with -inline
>
> https://d.puremagic.com/issues/buglist.cgi?query_format=advanced&short_desc=-inline%20ICE&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&short_desc_type=allwordssubstr&component=DMD&product=D

Probably not all of them but at least on of "-inline" ICE's I got running vibe.d unittests on 2.063.2 faded away after switching to 2.064 branch

I submitted the -inline bug. The other one with TaskPool.map was a known one, as was one with dub and dmd. I'll look at dub with ldc/gdc and at their bug tracking.


On Tuesday, 5 November 2013 at 19:57:07 UTC, Walter Bright wrote:
> On 11/5/2013 5:05 AM, Atila Neves wrote:
>> - I ran into a dmd bug when I tried to use TaskPool.map with a delegate so I had
>> to give up trying that possible optimisation.
>>
>> - I ran into another dmd bug (it crashed) at one point if -inline was used.
>
> It's very important to file these issues in bugzilla.
>
>
>> - dub build with LDC and GDC failed miserably. I think it was because of vibe.d.
>
> These too in the dub system.

On Tue, 2013-11-05 at 21:38 -0800, Jonathan M Davis wrote: […]
> Go is on the list of languages that I'd like to spend more time becoming familiar with, because I think that it's good to know lots of programming languages, but the more I learn about it, the less I like it. Its design philosophies are just too different from my preferences.

I would suggest that this is the core of the point: programming language is about personal preference as much as it is about language features. There are many dimensions to the scale including language complexity, ability to easily express algorithms, ease of handling errors and exceptions, context of use, problems being addressed, composition of team programming, individual preference, etc., etc.

Go is a very small language, with great data communication mechanisms, a simple build and deploy strategy, a view that DVCS (Git, Mercurial and Bazaar) is all the version management you need, all pivoting around static compilation of executables. I really like it, except for the obsession with error codes and no exceptions (except one which is the "terminate now" exception.

Go is being pushed by Google and now Canonical, so its market penetration and traction in the programming community is assured.

Rust is an interesting language, not least because it is taking many, many lessons from the functional programming community and transporting them into the imperative native code world. cf. the influence of ML and especially OCaml. Like C++ and D, Rust is actually a big language and aimed at the same sort of context and problem. And, of course, Rust has Mozilla pushing it.

Go and Rust are, of course, new languages, C++ and D are old language. For D this is a bad thing. D is always playing "catch up" and has no big influential organization saying "this is the language we use for our developments (in such and such an area)".

Given the current situation, I would advocate creating a new language, call it Brite say, which is an evolution of D2 (where the difference is in reality zero), and push the LDC2 realization of it as the primary implementation, with the GCC version a proud second. This way you get "new", "llvm", and a high quality statically typed native code language out there for people to go "wow" to.





-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Wed, 2013-11-06 at 08:33 +0100, deadalnix wrote:
[…]
> 
> You may want to look at scala then.

Or possibly Ceylon or Kotlin.

Or Groovy.

At least on the JVM

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Wed, 2013-11-06 at 11:10 +0100, Bienlein wrote:
[…]
> I'm sure about that. When you block a thread in Java it is no longer available for the thread pool and increasing the size of it cannot be done at will, because creating new threads is not lightweigt on the JVM.

Anyone using thread management explicitly in Java is doing it wrong. The one thing Go has totally right is "share data by passing messages" (*), even the functional programming community know this one.

Kernel threads are not lightweight on any system, hence threads pools
and fibres (**).

> There is a CSP implemention for Java made by some English university: http://www.cs.kent.ac.uk/projects/ofa/jcsp/ Groovy CSP makes use of it: http://www.gpars.org/1.0.0/guide/guide/GroovyCSP.html But I haven't tried what happens when you block threads.

JCSP has many problems, not least it hasn't been formally released in eons. People are still working on it but their concerns are academic focussed rather than production focussed. Long story elided.

Groovy CSP is an integral part of GPars, but Václav Pech and I have been wanting to create a new CSP realization in GPars directly rather than using JCSP as a delegate. Sadly neither of us have the time these days.

The whole idea of even knowing about threads when using CSP, especially Groovy CSP, and GPars in general, is total anathema. The whole point is that the comutational model is about messages and the events they cause. Threads are a hidden animating infrastructure. Programmers working with CSP should never think about threads.





(*) There are some reasonable exceptions, but they are fewer and further between than most people think.

(**) Which are really just threads from the 1970s and 1980s.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder