On Fri, 27 Mar 2015 22:37:21 +0000, weaselcat wrote:

> On Friday, 27 March 2015 at 22:32:32 UTC, ketmar wrote:
>> On Fri, 27 Mar 2015 16:11:41 +0000, Ola Fosheim Grøstad wrote:
>>
>>> Not a broken design. If I have to run multiple servers just to handle an image upload or generating a PDF then you are driving up the cost of the project and developers would be better off with a different platform?
>>
>> but it is broken! the whole point of async i/o servers is that such
>> servers spend most of their time waiting for i/o. and if you need to do
>> some lengthy calculations, you either spawns a "real thread"
>> and commands it to wake you up when it is finished, or asking external
>> server to do the job (and wake you when it is finished).
>>
>> what moving fibers from thread to thread does is bringing in state copying (we want our threads fairly isolated, aren't we? so either copying, or ownership management).
>>
>> the whole thing of cooperative multitasking is to be... cooperative. in several years some Shiny New Async Framework will use "no transferring fibers between worker threads" as Spectacular Invention.
> 
> as an outsider to the web-scale world,
> this entire thing seems like a half-baked fork reimplementation

the whole "userspace threads" concept is a reimplementation of kernel threads and sheduling. ;-)

the main question is the amount of work required to switch between threads. if we have a little amount of threads that does heavy work, it's ok to use kernel mechanics: the time of context switching is neglible.

but it we have alot of threads that mostly waits for i/o, then does very little amount of work and waits for i/o again, context switching time starts to show itself. so we moving the whole "treading" thing to user application, thus minimising thread context switching time.

all in all this is a half-baked kernel thread reimplementation, yes. but it has it's own pros. and cons, of course: such as unresponsive user thread can block the whole app, like in good old windows 3 times.

On Fri, 27 Mar 2015 12:48:03 +0000, Dejan Lekic wrote:

> That `source.byLine.join.to!(string);`
> line for example, takes...

...almost no time to understand. it's a simple composition, the thing they should learn on their CS courses, along with lambda calculus (or "functional programming", if you want).

On 3/27/2015 2:47 PM, weaselcat wrote:
> On Friday, 27 March 2015 at 20:58:44 UTC, Walter Bright wrote:
>> On 3/27/2015 1:35 PM, weaselcat wrote:
>>> there's a difference between minimalism and blatantly not adopting core advances
>>> in language design over the past 40 years.
>>
>> Yes, and there's also a difference between gratuitous complexity and finding
>> the underlying simplicity.
>>
>> It's a tricky thing finding the sweet spot.
>
> I don't disagree, but Go is definitely not in that sweet spot - it's crippled by
> its benevolent dictators for the sake of being crippled.

I tried to program in Java, and found it went too far in the simplicity department. I haven't programmed in Go, but it has also gone too far for my taste. I just don't want to program that way anymore.

I am not going to claim that D has hit the sweet spot, either, but I'd rather err on the side of having the power I want.

On Thursday, 26 March 2015 at 08:39:14 UTC, Russel Winder wrote:
> On Wed, 2015-03-25 at 14:00 -0700, Andrei Alexandrescu via Digitalmars-d-announce wrote:
>> https://www.reddit.com/r/programming/comments/30ad8b/why_gos_design_is_a_disservice_to_intelligent/
>> 
>> Andrei
>
> The reaction in the Go community to this article has been exactly as
> one would have anticipated. I paraphrase the common theme thus:
>  Go is
> successful in the market, D isn't, therefore Go is a better language
> than D.  Go does indeed have much greater market penetration, but I
> leave it as an exercise for the reader to deduce the sophistry, and
> indeed casuistry, in most of the argumentation.
>

By this standard, Go is much worse than C++, Java, or even C, which they pretend to be a better version of.

>> There are some very interesting psychological dynamics in the reaction to this kind of piece.  For me it was key that although it was clearly written in a humorous tone, and hurriedly, he seemed to speak from the heart - it is refreshing to see such work even when one doesn't agree with it.
>>
>> BTW since when has linking to something been an endorsement of it?
>
> Interesting. Have you read Oscar Wilde? Your comments remind me of him somehow.

Only a few things, and not his writings on aesthetics - but I do think truth, beauty and virtue need to balance each other.  Concentrating on prettiness alone leads to a shallow kind of thing becomes it becomes disconnected from the underlying generative spirit and eventually the life goes out of it.  So I suspect his perspective was rather different.

> I was just thinking yesterday how working with D makes me happy whereas working with other (lower) languages makes me grumpy.

Yes - and this matters so much more than as technical people we give ourselves permission to realize because willpower is a limited resource and modern life often appears as if it is a conspiracy to exhaust it.  When one actually look forward to writing a boring script because "I can do it in D", I take notice.  Moving towards what is generative and away from the wrong kind of pain is a strategy that seems to pay off in life.

> Going down to the punchcard level (PHP, JS etc.) is boring and doesn't do justice to the human mind. Whenever I use D, I am confident that I can map a complicated reality onto a machine, it inspires me and it challenges me. Primitive languages discourage me.

Yes, although I must say I still prefer programming in C to VBA.  Provided the aim is not actually to accomplish something quickly !

> So there's more to productivity than meets the eye when looking at numbers. Numbers are insignificant, they can prove anything you want, and you can tweak them any way you want. "Eat shit, a million flies can't be wrong!", as they say.

Yes.  And worst of all is the self deception from believing analytical objectivity to be something real rather than something that results from unexamined implicit assumptions.  Dr Iain Mcgilchrist at Oxford is excellent on this topic.

That doesn't mean one should throw away the profiler, of course...

> It's one thing to be productive in terms of maintaining and selling apps and another in terms of being innovative. You can sell a million records by sticking to well-trodden paths (dum-dum-dum-di-dum) or you can be a Mozart, a Beethoven, a Miles Davis or a Hendrix and just say "I'm gonna do my own thing!". Sure, it involves what is commonly perceived as "arrogance", but it's not.

Fully agree, although humbler initial aspirations and self conceptions are also compatible with a creative path.   Viz.

"I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones. "

On Friday, 27 March 2015 at 06:49:05 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 27 March 2015 at 04:05:30 UTC, Laeeth Isharc wrote:
>> Programming is - for now - still a human activity, and what is important in human activities may not always be measured, and what may be easily measured is not always important.  That doesn't mean one should throw away the profiler and go back to guessing, but it does suggest caution about adopting the prestigious techniques of the natural sciences and applying them to a domain where they don't necessarily fully belong.
>
> What is almost always important is:
>
> 1. to be able to ship the product in a predictable fashion
>
> 2. not go 300-400% over budget
>
> 3. being able to train new people to maintain it in reasonable time
>
> 4. being able to add new unexpected features to the code base on request
>
> Perl is a very expressive and productive language. And you can write maintainable software in it if you have discipline. In the real world Perl tends to lead to an unmaintainable mess with the average programmer.

Fair points that I wouldn't argue with (although I think predicting when one will finish something entirely new is a mugs game - another reason to favour prototyping and rapid iteration when possible).

But those strike me as practical questions of commercial experience, judgement, and tradecraft, and I don't see what it has to do with D or with a scientific approach, except that D may have some advantages in some cases in these areas.  I don't see any essential resemblance whatsoever between D and Perl - on the contrary.

The data points we have suggest that the scarcity of D programmers is an imaginary problem, because enterprises just hire good people and they pick it up (ask Don at Sociomantic or Dicebot for example).  Modern business has a misplaced emphasis on credentials.  And if you have a large code base it is not like a new guy can just dive in, anyway.  There is a signalling effect at work also, at least for the time being.

I am curious about something, if I might ask.  You seem like you feel let down by something about D.  Ie you give various reasons but I am not sure that's the motivating factor.  What's behind that ?  No need to answer if you prefer not to, of course.


Laeeth.

On Friday, 27 March 2015 at 16:48:26 UTC, Sönke Ludwig wrote:
>> 1. No stack.
>
> That reduces the memory footprint, but doesn't reduce latency.

It removes hard to spot dependencies on thread local storage.

>> 2. Batching.
>
> Can you elaborate?

Using fibers you deal with a single unit. Using events you deal with a request broken down into "atomic parts". You take a group of events by timed priority and sort them by type. Then you process all events of type A, then all events of type B etc. Better cache locality, more fine grained control over scheduling, easier to migrate to other servers etc.

But the fundamental problem with using fibers that are bound to a thread does not depend on long running requests. You get this also for multiple requests with normal workloads, it is rather obvious:

@time tick 0:

Thread 1…N-1:
100 ms workloads

Thread N:
Fiber A: async request from memcache (1ms)
Fiber B: async request from memcache (1ms)
...
Fiber M: async request from memcache…

@time tick 101:

Thread 1...N-1:
free

Thread N:
Fiber A: compute load 100ms

@time tick 201:
Fiber B: compute load 100ms

etc.

Also keep in mind that in a real world setting you deal with spikes, so the load balancer should fire up new instances a long time before your capacity is saturated. That means you need to balance loads over your threads if you want good average latency.

Antyhing less makes fibers a toy language feature IMO.

On Saturday, 28 March 2015 at 02:31:37 UTC, Laeeth Isharc wrote:
> Fair points that I wouldn't argue with (although I think predicting when one will finish something entirely new is a mugs game - another reason to favour prototyping and rapid iteration when possible).

Yet you have to if you are to get a fixed price contract.

> on credentials.  And if you have a large code base it is not like a new guy can just dive in, anyway.  There is a signalling effect at work also, at least for the time being.

But that is what the Go authors claim that they are aiming for. To judge it you will have to look at real projects and how they fare. Some teams claim that they are getting good results with Go, whether that is a result of enthusiasm or language qualities is another issue. But they do appear.

If you are to evaluate a project you have to look at the project goals. To evaluate Go you have to look at what their design goals are.

> I am curious about something, if I might ask.  You seem like you feel let down by something about D.  Ie you give various

D is going too wide, and therefore does not move. ~9 years ago it was announced as a production level language that could be used to replace C++. Last year there was a move to support better memory management, but it has since halted because there is an unwillingness to change the language. Which is ok, if you just say D2 is all about GC.

If you want to excel as a programming language you need to focus on a few areas and be really good in those before you expand into the next one. It is a fairly deep rooted development process issue that needs addressing if D is to reach a wide audience.

On Friday, 27 March 2015 at 16:44:50 UTC, Chris wrote:
> I'd say Go fans are worse in this respect (yes, I know, probably not all of them). People in the D community are here,

But that is just because there is more Go fans... ;)

On Friday, March 27, 2015 16:03:01 Walter Bright via Digitalmars-d-announce wrote:
> On 3/27/2015 2:47 PM, weaselcat wrote:
> > On Friday, 27 March 2015 at 20:58:44 UTC, Walter Bright wrote:
> >> On 3/27/2015 1:35 PM, weaselcat wrote:
> >>> there's a difference between minimalism and blatantly not adopting core advances in language design over the past 40 years.
> >>
> >> Yes, and there's also a difference between gratuitous complexity and finding the underlying simplicity.
> >>
> >> It's a tricky thing finding the sweet spot.
> >
> > I don't disagree, but Go is definitely not in that sweet spot - it's crippled by its benevolent dictators for the sake of being crippled.
>
> I tried to program in Java, and found it went too far in the simplicity department. I haven't programmed in Go, but it has also gone too far for my taste. I just don't want to program that way anymore.
>
> I am not going to claim that D has hit the sweet spot, either, but I'd rather err on the side of having the power I want.

Exactly! I'd _much_ rather have a language be a bit too complicated than too simple - especially way too simple. And if I wanted simple, I'd program in Java, but I don't want to simple - not at the price of power anyway - so I don't program in Java if I can help it. And I have stayed away from Go for the same reason. The more I learn of it, the clearer it is that its design goals and the audience that it targets is at complete odds with what I'm looking for. From what I've seen, I'd expect your average Go programmer to dislike D, and your average D programmer to dislike Go, because they seem to be at completely different ends of the simplicity vs power spectrum.

Of course, it's nice when a language can be powerful without adding a lot of complexity in the process, but I'd much rather have to worry about some extra complexity than not be able to do something in a language. For instance, in the case of Java, it's not even possible to write a swap function in it! And that doesn't even get into the more complex topics like RAII or code generation. I'll take power over simplicity almost every time if that's the tradeoff (though obviously, that can be taken too far if you're not careful).

Personally, I'm not sure that much is gained in pitting Go against D precisely because they're so different that they're likely to appeal to completely different sets of people.

- Jonathan M Davis