Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
Java programmers are having to come to terms with this. Python programmers sort of have, except that BDFL has failed to accept the correct end point and still likes loops. Scala has done it all wrong. (Further opinions available on request :-) Could you provide some sample Scala code to demonstrate what you mean? Just because it is not clear to me what this is about. Thanks.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Monday, 30 March 2015 at 18:20:39 UTC, Walter Bright wrote: Well put. My brain still thinks in terms of loops. Sadly, mine also... ;-P
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Tuesday, 31 March 2015 at 02:05:05 UTC, Andrei Alexandrescu wrote: On 3/30/15 12:29 AM, Jonathan M Davis via Digitalmars-d-announce wrote: On Saturday, March 28, 2015 14:19:46 Walter Bright via Digitalmars-d-announce wrote: Thank you. I need to learn std.algorithm better. Don't we all. Part of the problem with std.algorithm is its power. It's frequently the case that you think that something isn't there when it's either there under a different name, or you just have to look at one of its functions from a different angle to use it for what you're trying to do. It wouldn't surprise me at all if folks who know it quite well get surprised by what it can do at least from time to time. Then we need more examples and tutorials. -- Andrei how are these to appear?
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On 3/31/15 1:19 AM, Laeeth Isharc wrote: On Tuesday, 31 March 2015 at 02:05:05 UTC, Andrei Alexandrescu wrote: On 3/30/15 12:29 AM, Jonathan M Davis via Digitalmars-d-announce wrote: On Saturday, March 28, 2015 14:19:46 Walter Bright via Digitalmars-d-announce wrote: Thank you. I need to learn std.algorithm better. Don't we all. Part of the problem with std.algorithm is its power. It's frequently the case that you think that something isn't there when it's either there under a different name, or you just have to look at one of its functions from a different angle to use it for what you're trying to do. It wouldn't surprise me at all if folks who know it quite well get surprised by what it can do at least from time to time. Then we need more examples and tutorials. -- Andrei how are these to appear? I've offered a number of times to write a slides-like tutorial if anyone wants to do the slides logic. Nobody came about. Probably nobody will, so I'll have to do it myself. It's also disheartening that people in our community say Except for one function, std.algorithm does not allocate memory, or RefCounted works with classes, it just hasn't been implemented yet, however nobody actually fixes these things (not to mention file reading by line is slow which has been fixed after having been wrongly characterized as a fundamental cstdlib issue). This has been going on for YEARS. Only a handful of contributors actually do such work, a lot of which is trivial; everybody else seems content to just talk about it and wait for handouts. We need to do better at empowering people. Andrei
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Tuesday, 31 March 2015 at 08:35:47 UTC, Andrei Alexandrescu wrote: I've offered a number of times to write a slides-like tutorial if anyone wants to do the slides logic. Nobody came about. Probably nobody will, so I'll have to do it myself. What do you mean by slides logic? What are you aiming for? (I missed your earlier posts on that, sorry.) In any case, if this is a you do the content, someone else does the mundane kind of offer, I am all ears. I'd like to help, I'd like to learn and I am not able to do the content myself.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
Then we need more examples and tutorials. -- Andrei how are these to appear? I've offered a number of times to write a slides-like tutorial if anyone wants to do the slides logic. Nobody came about. Probably nobody will, so I'll have to do it myself. Sorry for my denseness, but what is 'slides logic'? What I had in mind was that big projects that are not intrinsically gratifying can be too much to undertake in one bite. So how about we just agree something like 'email p0nce' (if he is willing - he seems to be good at it) when one comes across something cool - like a way to make use of std.algorithm (as several people have mentioned keeps happening) so he can collect them and write them up when there is time. Or someone else, if p0nce cannot or does not wish to do it. I bet that one could find quite a few useful examples just grepping thru one's own code/searching on github. It's also disheartening that people in our community say Except for one function, std.algorithm does not allocate memory Umm that was me... I don't feel confident enough to write at a Phobos standard yet and might be a little while before I am experienced enough. But I see your point. I reckon people do want to help, but don't know how. If I do a search for priorities on the wiki, only the roadmap comes up. I started this page as a placeholder: http://wiki.dlang.org/How_You_Can_Help Laeeth.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Tue, 31 Mar 2015 01:35:47 -0700, Andrei Alexandrescu wrote: We need to do better at empowering people. it's fairly easy: just pay them for the tasks. most people using D to solve *their* task at hand, and if they see something wrong, they report it as an issue (sometimes) and go on with their task, designing workarounds. there is no way you can force people to drop their tasks and do something different. only sometimes, when they continuously hit by something in Phobos, they writing patches. yet that patches will not be widely available until the next compiler release, which means that if people plan to publish their code, they *have* to write workarounds anyway. and if there is workaround written, there is less motivation to write a patch that fixes the thing. for GNU/Linux everything is even worse, as DMD cannot be included in repositories as free software (it isn't), so we have GDC/LDC, which are much slower with releases, and much slower with repo updates. what *can* help here is free DMD (in FSF definition) and monthly releases. this is not a silver bullet, but it's easier to convince maintainers of various distributives to work on free compiler. signature.asc Description: PGP signature
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
Umm that was me... I don't feel confident enough to write at a Phobos standard yet and might be a little while before I am experienced enough. But I see your point. Fastest way to get better is to submit PRs and get reviewed.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On 3/31/15 3:40 AM, Laeeth Isharc wrote: Then we need more examples and tutorials. -- Andrei how are these to appear? I've offered a number of times to write a slides-like tutorial if anyone wants to do the slides logic. Nobody came about. Probably nobody will, so I'll have to do it myself. Sorry for my denseness, but what is 'slides logic'? E.g. http://tour.golang.org/welcome/1 What I had in mind was that big projects that are not intrinsically gratifying can be too much to undertake in one bite. So how about we just agree something like 'email p0nce' (if he is willing - he seems to be good at it) when one comes across something cool - like a way to make use of std.algorithm (as several people have mentioned keeps happening) so he can collect them and write them up when there is time. Or someone else, if p0nce cannot or does not wish to do it. I bet that one could find quite a few useful examples just grepping thru one's own code/searching on github. It's also disheartening that people in our community say Except for one function, std.algorithm does not allocate memory Umm that was me... I don't feel confident enough to write at a Phobos standard yet and might be a little while before I am experienced enough. But I see your point. No worries, it's the pattern not the person. Walter mentioned that as well. It gets mentioned often. I reckon people do want to help, but don't know how. If I do a search for priorities on the wiki, only the roadmap comes up. I started this page as a placeholder: http://wiki.dlang.org/How_You_Can_Help Great, thanks! Andrei
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Saturday, March 28, 2015 14:19:46 Walter Bright via Digitalmars-d-announce wrote: Thank you. I need to learn std.algorithm better. Don't we all. Part of the problem with std.algorithm is its power. It's frequently the case that you think that something isn't there when it's either there under a different name, or you just have to look at one of its functions from a different angle to use it for what you're trying to do. It wouldn't surprise me at all if folks who know it quite well get surprised by what it can do at least from time to time. - Jonathan M Davis
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Sunday, 29 March 2015 at 22:07:40 UTC, Laeeth Isharc wrote: should we add a link to the wiki and ask author if we could mirror there ? This section on wiki looks like it could with a bit of fleshing out! http://wiki.dlang.org/Coming_From/Python I just seen what you did in the wiki, that's great! I don't have much time to invest tonight but I'll definitely do my part of the job in a day or two. Thank you for noticing. It's not very inspired, but I don't have much energy at the moment, and it is the best I can do with what I have. Better an acceptable start than trying to be perfect. The Ruby / Java / Eiffel / C# / and Basic sections also need starting. While not forgetting that Java, Eiffel, C#, Basic have options to compile straight to native code, just like D, so the focus should be on other features and not on native vs VM. -- Paulo
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Monday, 30 March 2015 at 00:20:11 UTC, Laeeth Isharc wrote: https://www.quora.com/Why-didnt-D-language-become-mainstream-comparing-to-Golang Post this on reddit.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Monday, 30 March 2015 at 03:26:14 UTC, deadalnix wrote: On Sunday, 29 March 2015 at 16:32:32 UTC, Idan Arye wrote: Computer science is all about tradeoffs. I used to love Ruby, but then a Rails project got out of hand... Nowadays I use it mainly as a bash replacement - Hundredfolds more expressive, only a tiny tiny bit syntax overhead, and for things that bash's safety would be enough Ruby's certainly suffices. This is pretty much the recurring story with ruby. The first 10 000 lines are a lot of fun, and then it gets out of hands. Just like any other language with dynamic typing.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Sunday, 29 March 2015 at 19:03:06 UTC, Laeeth Isharc wrote: On Sunday, 29 March 2015 at 15:34:35 UTC, Ola Fosheim Grøstad wrote: Actually, there is quite a large overlap if you look beyond the syntax. Dart is completely unexciting, but I also find it very productive when used with the IDE. Glad to hear this - I haven't yet got very far with Dart, but it seems like a toss-up between Dart and Livescript for a passable language to run on the client (for my little use case). I don't know the future of Dart, but if you have time to wait for it you might consider atscript/Angular 2.0. Knuth is also right that people think in different ways, and it's an entirely natural thing to see a multiplicity of languages emerging that are adapted to these different ways (and of course the particular challenges people face are also different). That's why religious wars about these things have I think most imperative languages are just variations over the same theme. I pick them based on what they+ecosystem is good at, not the language by itself. So basically, you have to be best at one particular application area to do well. Go is aiming to have a good runtime for building smaller web-services, and they are getting there. Because they focus.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Mon, 30 Mar 2015 00:29:46 -0700, Jonathan M Davis via Digitalmars-d-announce wrote: On Saturday, March 28, 2015 14:19:46 Walter Bright via Digitalmars-d-announce wrote: Thank you. I need to learn std.algorithm better. Don't we all. Part of the problem with std.algorithm is its power. It's frequently the case that you think that something isn't there when it's either there under a different name, or you just have to look at one of its functions from a different angle to use it for what you're trying to do. It wouldn't surprise me at all if folks who know it quite well get surprised by what it can do at least from time to time. and those who doesn't (like me) keep finding various gems there. ;-) signature.asc Description: PGP signature
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Monday, 30 March 2015 at 08:53:15 UTC, Ola Fosheim Grøstad wrote: On Sunday, 29 March 2015 at 19:03:06 UTC, Laeeth Isharc wrote: On Sunday, 29 March 2015 at 15:34:35 UTC, Ola Fosheim Grøstad wrote: Actually, there is quite a large overlap if you look beyond the syntax. Dart is completely unexciting, but I also find it very productive when used with the IDE. Glad to hear this - I haven't yet got very far with Dart, but it seems like a toss-up between Dart and Livescript for a passable language to run on the client (for my little use case). I don't know the future of Dart, but if you have time to wait for it you might consider atscript/Angular 2.0. Very dark as Angular team decided to look for Typescript instead[0]. http://blogs.msdn.com/b/typescript/archive/2015/03/05/angular-2-0-built-on-typescript.aspx Now with Dart team giving up on their VM, Dart becomes just yet another language that transpiles to JavaScript. http://news.dartlang.org/2015/03/dart-for-entire-web.html So, it will just fade way in the sea of JavaScript wannabe replacements. -- Paulo
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Monday, 30 March 2015 at 07:45:50 UTC, Paulo Pinto wrote: On Monday, 30 March 2015 at 03:26:14 UTC, deadalnix wrote: On Sunday, 29 March 2015 at 16:32:32 UTC, Idan Arye wrote: Computer science is all about tradeoffs. I used to love Ruby, but then a Rails project got out of hand... Nowadays I use it mainly as a bash replacement - Hundredfolds more expressive, only a tiny tiny bit syntax overhead, and for things that bash's safety would be enough Ruby's certainly suffices. This is pretty much the recurring story with ruby. The first 10 000 lines are a lot of fun, and then it gets out of hands. Just like any other language with dynamic typing. This has more to do with the module system than with the typing. In Ruby, the `require` function reads a source file and interprets it in the global namespace. This means that from that point on, all symbols declared in that source file(and the source files it `require`s) are now part of the global namespace and accessible from anywhere(even from places that didn't `require` it), and that all monkey-patching done in that source file from now on applies *everywhere*. Compare it to Python, that has a module system that handles namespacing and forces you to `import` a module in each scope you want to use it. This means that if foo.py uses stuff from bar.py it must `import` it directly and can't rely on some other baz.py that might dropt it's `import` to bar.py because it no longer needs it without knowing that foo.py was using it. Note that Ruby does has `module`s that can be used for namespacing(or for mixins...) but using them is a hassle, because you either have to always use fully qualified names or to `mixin` them into the current namespace(which propagates to other scopes that want to use stuff from YOUR namespace...) Also note that Python also has ways to mess with the gloabl context - but you have to actually dig in to do this, compared to Ruby where messing up the global context is the standard way of doing things.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Monday, 30 March 2015 at 07:29:56 UTC, Jonathan M Davis wrote: On Saturday, March 28, 2015 14:19:46 Walter Bright via Digitalmars-d-announce wrote: Thank you. I need to learn std.algorithm better. Don't we all. Part of the problem with std.algorithm is its power. It's frequently the case that you think that something isn't there when it's either there under a different name, or you just have to look at one of its functions from a different angle to use it for what you're trying to do. It wouldn't surprise me at all if folks who know it quite well get surprised by what it can do at least from time to time. - Jonathan M Davis when this happens, it would be great if the person could post to the group a few lines about it so someone (possibly someone else) can collate into a future series on gems in phobos. maybe give subject some consistent name so it is easy to find them later.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Monday, 30 March 2015 at 08:53:15 UTC, Ola Fosheim Grøstad wrote: same theme. I pick them based on what they+ecosystem is good at, not the language by itself. So basically, you have to be best at one particular application area to do well. Go is aiming to have a good runtime for building smaller web-services, and they are getting there. Because they focus. It is necessary to be appealing to Ola by Ola's standards for a language to appeal to other people? I think how it actually works is that you have to find a small but focused group of people to love you lots. Then they tell other people and over time you get better at appealing to those for whom you weren't ready before. So that's similar to what you suggest in one sense, except that the chicken and egg problem is smaller. Sociomantic didn't consider the ecosystem when selecting D (or at least were not put off by its immaturity). But if in five years time their competitors realize the possibilities for doing things better, they will certainly benefit from the work Sociomantic has done on improving D (even purely as a demanding use case, but it's more than that). [And Sociomantic won't lose, in my uninformed estimation, because edge is dynamic]. Similarly in the tiniest of ways, I didn't weight the library situation very heavily in picking D. I have written a couple of bindings (painfully, before I got Dstep to work or knew the language very well!) and wrappers and if anyone like me arrives subsequently then it will be that little bit easier. So that's one more reason why it can take a couple of decades for something to be an overnight success - it takes time for paths and habits to be formed, and there are threshold effects, beyond which there is a phase change. So D's long-term prospects will be shaped by how it responds to the challenges of growth. Looks good to me right now. Laeeth.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
Ola Fosheim Grøstad: So, it will just fade way in the sea of JavaScript wannabe replacements. Maybe, but Google is using it for Google Ads. Which is their primary business? Still, a bit early to say what happens next. Perhaps next some kind of blend of Typescript and Dart will become part of a next JavaScript update :-) Bye, bearophile
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Monday, 30 March 2015 at 10:04:11 UTC, Paulo Pinto wrote: Very dark as Angular team decided to look for Typescript instead[0]. It isn't very dark though, they cooperate with MS to build atscript features into Typescript instead. The two dialect were always meant to be merged at some point. So they decided to merge early. A good idea, actually. http://blogs.msdn.com/b/typescript/archive/2015/03/05/angular-2-0-built-on-typescript.aspx Now with Dart team giving up on their VM, Dart becomes just yet another language that transpiles to JavaScript. Yes, although you can run the dartvm outside the browser, not sure how much love it will receive though. So, it will just fade way in the sea of JavaScript wannabe replacements. Maybe, but Google is using it for Google Ads. Which is their primary business? Still, a bit early to say what happens next.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Monday, 30 March 2015 at 10:45:50 UTC, bearophile wrote: Ola Fosheim Grøstad: So, it will just fade way in the sea of JavaScript wannabe replacements. Maybe, but Google is using it for Google Ads. Which is their primary business? Still, a bit early to say what happens next. Perhaps next some kind of blend of Typescript and Dart will become part of a next JavaScript update :-) Yeah, I think both Microsoft and Google see this as an effort to prototype what Ecmascript6+ should be like.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On 3/30/2015 12:29 AM, Jonathan M Davis via Digitalmars-d-announce wrote: On Saturday, March 28, 2015 14:19:46 Walter Bright via Digitalmars-d-announce wrote: Thank you. I need to learn std.algorithm better. Don't we all. Part of the problem with std.algorithm is its power. It's frequently the case that you think that something isn't there when it's either there under a different name, or you just have to look at one of its functions from a different angle to use it for what you're trying to do. It wouldn't surprise me at all if folks who know it quite well get surprised by what it can do at least from time to time. Well put. My brain still thinks in terms of loops.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Monday, 30 March 2015 at 12:04:22 UTC, Laeeth Isharc wrote: On Monday, 30 March 2015 at 07:29:56 UTC, Jonathan M Davis wrote: On Saturday, March 28, 2015 14:19:46 Walter Bright via Digitalmars-d-announce wrote: Thank you. I need to learn std.algorithm better. Don't we all. Part of the problem with std.algorithm is its power. It's frequently the case that you think that something isn't there when it's either there under a different name, or you just have to look at one of its functions from a different angle to use it for what you're trying to do. It wouldn't surprise me at all if folks who know it quite well get surprised by what it can do at least from time to time. - Jonathan M Davis when this happens, it would be great if the person could post to the group a few lines about it so someone (possibly someone else) can collate into a future series on gems in phobos. maybe give subject some consistent name so it is easy to find them later. I regularly review std.algorithm just because I'm not used to functional programming, it has so many useful things.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On 3/30/2015 11:53 AM, weaselcat wrote: speaking of optimization, are there any guarantees(documented?) on the kind of optimizations you should expect from range programming in D(i.e, function chaining) similar to Haskell's stream fusion? No. It's a QoI issue.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On 3/30/2015 11:41 AM, Russel Winder via Digitalmars-d-announce wrote: Java programmers are having to come to terms with this. Python programmers sort of have, except that BDFL has failed to accept the correct end point and still likes loops. Scala has done it all wrong. (Further opinions available on request :-) I always enjoy your posts, Russel! ... opinionated posts backed by experience.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Mon, 2015-03-30 at 11:20 -0700, Walter Bright via Digitalmars-d-announce wrote: […] Even Andrei, who wrote most of std.algorithm, posted here recently how he was surprised at how powerful it was. An indicator of plagiarism? ;-) -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Monday, 30 March 2015 at 18:41:17 UTC, Russel Winder wrote: On Mon, 2015-03-30 at 11:19 -0700, Walter Bright via Digitalmars-d-announce wrote: […] My brain still thinks in terms of loops. The excellent influence of functional programming on imperative programming is implicit iteration and higher-order functions. Any explicit for/while loop in a modern imperative language code should *necessarily* involve a side-effect or it is coded wrongly. Even then it can almost certainly be recast to preserve the side- effect and remove the loop – unless you are implementing the implicit iteration function. This has nothing to do with tail recursion optimization and all that Lambda Calculus stuff, this is to do with correct levels of abstraction that allow the tool chain to maximize support for the programmer. Java programmers are having to come to terms with this. Python programmers sort of have, except that BDFL has failed to accept the correct end point and still likes loops. Scala has done it all wrong. (Further opinions available on request :-) speaking of optimization, are there any guarantees(documented?) on the kind of optimizations you should expect from range programming in D(i.e, function chaining) similar to Haskell's stream fusion?
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Mon, 2015-03-30 at 11:19 -0700, Walter Bright via Digitalmars-d-announce wrote: […] My brain still thinks in terms of loops. The excellent influence of functional programming on imperative programming is implicit iteration and higher-order functions. Any explicit for/while loop in a modern imperative language code should *necessarily* involve a side-effect or it is coded wrongly. Even then it can almost certainly be recast to preserve the side- effect and remove the loop – unless you are implementing the implicit iteration function. This has nothing to do with tail recursion optimization and all that Lambda Calculus stuff, this is to do with correct levels of abstraction that allow the tool chain to maximize support for the programmer. Java programmers are having to come to terms with this. Python programmers sort of have, except that BDFL has failed to accept the correct end point and still likes loops. Scala has done it all wrong. (Further opinions available on request :-) -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On 3/30/15 12:29 AM, Jonathan M Davis via Digitalmars-d-announce wrote: On Saturday, March 28, 2015 14:19:46 Walter Bright via Digitalmars-d-announce wrote: Thank you. I need to learn std.algorithm better. Don't we all. Part of the problem with std.algorithm is its power. It's frequently the case that you think that something isn't there when it's either there under a different name, or you just have to look at one of its functions from a different angle to use it for what you're trying to do. It wouldn't surprise me at all if folks who know it quite well get surprised by what it can do at least from time to time. Then we need more examples and tutorials. -- Andrei
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Sunday, 29 March 2015 at 16:32:32 UTC, Idan Arye wrote: Computer science is all about tradeoffs. I used to love Ruby, but then a Rails project got out of hand... Nowadays I use it mainly as a bash replacement - Hundredfolds more expressive, only a tiny tiny bit syntax overhead, and for things that bash's safety would be enough Ruby's certainly suffices. This is pretty much the recurring story with ruby. The first 10 000 lines are a lot of fun, and then it gets out of hands.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Sunday, 29 March 2015 at 21:43:21 UTC, Walter Bright wrote: On 3/28/2015 5:34 PM, ketmar wrote: on the other side of the spectrum was Chuck Moore, for example, who imagines modern computers filled with many cheap and average RISC processors, and using parallel multiprocessor execution to achieve great performance. Isn't that what a GPU is? This is exactly what a GPU is.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Thursday, 26 March 2015 at 08:44:20 UTC, Gary Willoughby wrote: I wrote the article in a rush last night (girlfriend calling me to bed) and as a result it has a few spelling/grammar errors which I've hopefully corrected. The article is a total rant about Go after using it over the last month or so for a project. I honestly was getting so bored with Go and the article that I was literally falling asleep writing it. lol! Is started liking Go but after a while I found it increasing difficult trying to change me way of working to shoehorn solutions into such a simple language. I know it's a bit unfair in places and it's got a click bait title but who cares? I got my point across and I think people understand where i'm coming from. It seems to have got really popular and I've been swamped with mail, etc. I think it's the most read article i've ever written. ha! :o) https://www.quora.com/Why-didnt-D-language-become-mainstream-comparing-to-Golang fwiw
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Sunday, 29 March 2015 at 08:37:54 UTC, Idan Arye wrote: On Saturday, 28 March 2015 at 18:47:04 UTC, Walter Bright wrote: On 3/28/2015 3:20 AM, Jonathan M Davis via Digitalmars-d-announce wrote: 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. I also do not regard Go as a competitor to D. It's more of a competitor to Java and Ruby. How is Go a competitor to Ruby? I cannot think of a single parameter where Go and Ruby don't take the exact opposite approach!(other than the obvious ones like both use require the programmer to write code) They appeal to programmer that prefers fashionable technology rather than technologies that solve problems.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Monday, 30 March 2015 at 00:20:11 UTC, Laeeth Isharc wrote: https://www.quora.com/Why-didnt-D-language-become-mainstream-comparing-to-Golang fwiw Nice, well-written answer, enjoyed reading it.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Saturday, 28 March 2015 at 14:33:14 UTC, Russel Winder wrote: On Sat, 2015-03-28 at 12:52 +0100, Sönke Ludwig via Digitalmars-d-announce wrote: […] You can access TLS from an event callback just as easy as from a fiber. […] TLS is the evil here. Anyone working with TLS is either writing an operating system or doing it wrong. Or, you know, doing it safe. Unlike Go.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Monday, 30 March 2015 at 03:47:45 UTC, Joakim wrote: On Monday, 30 March 2015 at 00:20:11 UTC, Laeeth Isharc wrote: https://www.quora.com/Why-didnt-D-language-become-mainstream-comparing-to-Golang fwiw Nice, well-written answer, enjoyed reading it. Thank you.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Sun, 29 Mar 2015 14:43:14 -0700, Walter Bright wrote: On 3/28/2015 5:34 PM, ketmar wrote: on the other side of the spectrum was Chuck Moore, for example, who imagines modern computers filled with many cheap and average RISC processors, and using parallel multiprocessor execution to achieve great performance. Isn't that what a GPU is? yes, GPU is a good example of that. signature.asc Description: PGP signature
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On 3/29/15 4:43 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net wrote: On Sunday, 29 March 2015 at 08:37:54 UTC, Idan Arye wrote: On Saturday, 28 March 2015 at 18:47:04 UTC, Walter Bright wrote: On 3/28/2015 3:20 AM, Jonathan M Davis via Digitalmars-d-announce wrote: 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. I also do not regard Go as a competitor to D. It's more of a competitor to Java and Ruby. How is Go a competitor to Ruby? I cannot think of a single parameter where Go and Ruby don't take the exact opposite approach!(other than the obvious ones like both use require the programmer to write code) I think it's more of a competitor to Rails. Ruby as a language is as you say very different from Go. Incidentally, it shows that it is possible to make a language simple without crippling it. ... but efficiency. Ruby is 50 times slower than all languages, including itself. Andrei
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Sunday, 29 March 2015 at 12:21:01 UTC, Ola Fosheim Grøstad wrote: On Sunday, 29 March 2015 at 02:15:38 UTC, cym13 wrote: Moreover, it is possible to reach a good expressiveness (maybe not as good as python, but that's the whole goal of python so there's no shame in not matching it). There are many alternatives to Python. Like Nim or Dart: https://www.dartlang.org/articles/beyond-async/ https://www.dartlang.org/articles/await-async/ Nim seems quite interesting indeed, even if I'm not sure how well it scales. It looks like a language that is prowd of a heavy use of macros and DSL definition à la lisp. I know lisp enough to know that it's not a problem in itself, but that it should be developed wisely. It may look at first as a better alternative than D for a pure python developer, but I'll stick with D. However, I can't see a pythonista being excited in Dart at all, at least not for what he finds in python. More restricted in any way, no clear functional orientation possible, a clear lack of expressiveness... D clearely has the advantage there.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Sunday, 29 March 2015 at 02:15:38 UTC, cym13 wrote: Moreover, it is possible to reach a good expressiveness (maybe not as good as python, but that's the whole goal of python so there's no shame in not matching it). There are many alternatives to Python. Like Nim or Dart: https://www.dartlang.org/articles/beyond-async/ https://www.dartlang.org/articles/await-async/
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Sunday, 29 March 2015 at 15:57:18 UTC, Andrei Alexandrescu wrote: On 3/29/15 4:43 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net wrote: On Sunday, 29 March 2015 at 08:37:54 UTC, Idan Arye wrote: On Saturday, 28 March 2015 at 18:47:04 UTC, Walter Bright wrote: On 3/28/2015 3:20 AM, Jonathan M Davis via Digitalmars-d-announce wrote: 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. I also do not regard Go as a competitor to D. It's more of a competitor to Java and Ruby. How is Go a competitor to Ruby? I cannot think of a single parameter where Go and Ruby don't take the exact opposite approach!(other than the obvious ones like both use require the programmer to write code) I think it's more of a competitor to Rails. Ruby as a language is as you say very different from Go. Incidentally, it shows that it is possible to make a language simple without crippling it. ... but efficiency. Ruby is 50 times slower than all languages, including itself. Andrei Not to mention orthogonal safety. Even for a dynamically typed scripting language Ruby sacrifices a lot of safety. Not memory-wise but orthogonality-wise - it's design is very hackish, and you can remove an import(require) to foo.rb from bar.rb thus causing a bug in baz.rb that was importing bar.rb and thus indirectly importing qux.rb because foo.rb was importing it, and qux.rb is monkey-patching class Qux to override some method to return a different value. Have fun trying to debug this! Computer science is all about tradeoffs. I used to love Ruby, but then a Rails project got out of hand... Nowadays I use it mainly as a bash replacement - Hundredfolds more expressive, only a tiny tiny bit syntax overhead, and for things that bash's safety would be enough Ruby's certainly suffices.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Saturday, 28 March 2015 at 18:47:04 UTC, Walter Bright wrote: On 3/28/2015 3:20 AM, Jonathan M Davis via Digitalmars-d-announce wrote: 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. I also do not regard Go as a competitor to D. It's more of a competitor to Java and Ruby. How is Go a competitor to Ruby? I cannot think of a single parameter where Go and Ruby don't take the exact opposite approach!(other than the obvious ones like both use require the programmer to write code)
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Sunday, 29 March 2015 at 02:15:38 UTC, cym13 wrote: Urr As an active Python developer, I find that one pretty harsh. It's not that we need to enforce good style, it's that we take good style as granted and choose to lighten it consequently. On the contrary I think that D has everything to attract a pythonista. Most new, trendy languages like Go or Rust are to down a level to easily suit a python's formated mind, and I guess that if most python developers come to switch language for performance issues (like myself) D's code safety system is definitely very appealing because python's safety is... well... ^^ Moreover, it is possible to reach a good expressiveness (maybe not as good as python, but that's the whole goal of python so there's no shame in not matching it). UFCS FTW! As an active Python developer, what would you add to or change about the following: http://bitbashing.io/2015/01/26/d-is-like-native-python.html
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Sunday, 29 March 2015 at 19:09:52 UTC, Laeeth Isharc wrote: On Sunday, 29 March 2015 at 02:15:38 UTC, cym13 wrote: Urr As an active Python developer, I find that one pretty harsh. It's not that we need to enforce good style, it's that we take good style as granted and choose to lighten it consequently. On the contrary I think that D has everything to attract a pythonista. Most new, trendy languages like Go or Rust are to down a level to easily suit a python's formated mind, and I guess that if most python developers come to switch language for performance issues (like myself) D's code safety system is definitely very appealing because python's safety is... well... ^^ Moreover, it is possible to reach a good expressiveness (maybe not as good as python, but that's the whole goal of python so there's no shame in not matching it). UFCS FTW! As an active Python developer, what would you add to or change about the following: http://bitbashing.io/2015/01/26/d-is-like-native-python.html while it mentions concurrency/parallel, a quick example of showing how easy it is to do parallel operations in D would probably benefit considering python's current state of parallelism.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Sunday, 29 March 2015 at 15:34:35 UTC, Ola Fosheim Grøstad wrote: Actually, there is quite a large overlap if you look beyond the syntax. Dart is completely unexciting, but I also find it very productive when used with the IDE. Glad to hear this - I haven't yet got very far with Dart, but it seems like a toss-up between Dart and Livescript for a passable language to run on the client (for my little use case). Anyway, my point was more that making Python a target means you have to compete with a large set of other languages in the same vein. In the system language area you only have C++/Rust so it is an easier target. Unfortunately C++ still has a lot of advantages over other languages for real world projects, so it will remain my system level language until a better language starts polishing their low level stuff... :-/ Peter Thiel is right. Competition is overrated, and it is much better to have a monopoly in a small domain and build out from there - one shouldn't think in terms of acquiring market share if one is not already one of the dominant players (and even then to do so is often counterproductive). D isn't a product marketed by Proctor and Gamble. So nobody is going to make Python a target, as best I can tell. But one can surely learn from what they do right, to the extent that it applies to new conditions of the future. The obvious things are documentation, libraries, and having a nice, easy-to-install, and low-friction set of choices in development stacks organised and available. Knuth is also right that people think in different ways, and it's an entirely natural thing to see a multiplicity of languages emerging that are adapted to these different ways (and of course the particular challenges people face are also different). That's why religious wars about these things have a bad name. That doesn't mean people shouldn't have a perspective and argue for it when such discussions are generative. D will continue to gather success if it keeps getting better and confronting the painful challenges of growth, as seems to me to be happening in my short time here. Naysayers are an asset if one doesn't get discouraged, because it is difficult to buy good criticism at any price.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Sunday, 29 March 2015 at 19:09:52 UTC, Laeeth Isharc wrote: As an active Python developer, what would you add to or change about the following: http://bitbashing.io/2015/01/26/d-is-like-native-python.html I like this article very much. IMO python's generators and list comprehensions are the two things that are the most difficult to replace when switching to another language. Hence I would explicitely make a link with list comprehensions in the UFCS paragraph because it is not obvious. I would also add a little paragraph about ranges to make the link from generators (but maybe not with an example as it may be scarier than it really is). In the same way of making the parallel with python, many developers seem to use python for web serveurs nowadays. It would be great to include a link to vibe.d in the article. Something simple like or web server developments with vibe.d thrown in a sentence. Also, but this one would be a sensible addition, I'm sorry to see that nothing is said about purity or safety. I definitely think that it can be a good selling argument, even if it goes beyond the goal Writting Python in D. Otherwise, I find the article very good. It emphasis the good points, even those that are often forgotten like dub (because pypi is so important in python). I'll try giving it to some friends to see what they think about it :)
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Sunday, 29 March 2015 at 19:44:01 UTC, cym13 wrote: On Sunday, 29 March 2015 at 19:09:52 UTC, Laeeth Isharc wrote: As an active Python developer, what would you add to or change about the following: http://bitbashing.io/2015/01/26/d-is-like-native-python.html I like this article very much. IMO python's generators and list comprehensions are the two things that are the most difficult to replace when switching to another language. Hence I would explicitely make a link with list comprehensions in the UFCS paragraph because it is not obvious. I would also add a little paragraph about ranges to make the link from generators (but maybe not with an example as it may be scarier than it really is). In the same way of making the parallel with python, many developers seem to use python for web serveurs nowadays. It would be great to include a link to vibe.d in the article. Something simple like or web server developments with vibe.d thrown in a sentence. Also, but this one would be a sensible addition, I'm sorry to see that nothing is said about purity or safety. I definitely think that it can be a good selling argument, even if it goes beyond the goal Writting Python in D. Otherwise, I find the article very good. It emphasis the good points, even those that are often forgotten like dub (because pypi is so important in python). I'll try giving it to some friends to see what they think about it :) should we add a link to the wiki and ask author if we could mirror there ? This section on wiki looks like it could with a bit of fleshing out! http://wiki.dlang.org/Coming_From/Python
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On 3/29/2015 12:09 PM, Laeeth Isharc wrote: As an active Python developer, what would you add to or change about the following: http://bitbashing.io/2015/01/26/d-is-like-native-python.html Has someone reddit-ized it?
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Sunday, 29 March 2015 at 21:45:23 UTC, Walter Bright wrote: On 3/29/2015 12:09 PM, Laeeth Isharc wrote: As an active Python developer, what would you add to or change about the following: http://bitbashing.io/2015/01/26/d-is-like-native-python.html Has someone reddit-ized it? It seems so: http://www.reddit.com/r/programming/comments/2tqiaj/d_is_like_native_python/?submit_url=http%3A%2F%2Fbitbashing.io%2F2015%2F01%2F26%2Fd-is-like-native-python.htmlalready_submitted=true
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On 3/29/2015 2:46 PM, cym13 wrote: On Sunday, 29 March 2015 at 21:45:23 UTC, Walter Bright wrote: On 3/29/2015 12:09 PM, Laeeth Isharc wrote: As an active Python developer, what would you add to or change about the following: http://bitbashing.io/2015/01/26/d-is-like-native-python.html Has someone reddit-ized it? It seems so: http://www.reddit.com/r/programming/comments/2tqiaj/d_is_like_native_python/?submit_url=http%3A%2F%2Fbitbashing.io%2F2015%2F01%2F26%2Fd-is-like-native-python.htmlalready_submitted=true Ah, thanks!
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Sunday, 29 March 2015 at 21:06:28 UTC, Laeeth Isharc wrote: On Sunday, 29 March 2015 at 19:44:01 UTC, cym13 wrote: On Sunday, 29 March 2015 at 19:09:52 UTC, Laeeth Isharc wrote: As an active Python developer, what would you add to or change about the following: http://bitbashing.io/2015/01/26/d-is-like-native-python.html I like this article very much. IMO python's generators and list comprehensions are the two things that are the most difficult to replace when switching to another language. Hence I would explicitely make a link with list comprehensions in the UFCS paragraph because it is not obvious. I would also add a little paragraph about ranges to make the link from generators (but maybe not with an example as it may be scarier than it really is). In the same way of making the parallel with python, many developers seem to use python for web serveurs nowadays. It would be great to include a link to vibe.d in the article. Something simple like or web server developments with vibe.d thrown in a sentence. Also, but this one would be a sensible addition, I'm sorry to see that nothing is said about purity or safety. I definitely think that it can be a good selling argument, even if it goes beyond the goal Writting Python in D. Otherwise, I find the article very good. It emphasis the good points, even those that are often forgotten like dub (because pypi is so important in python). I'll try giving it to some friends to see what they think about it :) should we add a link to the wiki and ask author if we could mirror there ? This section on wiki looks like it could with a bit of fleshing out! http://wiki.dlang.org/Coming_From/Python I just seen what you did in the wiki, that's great! I don't have much time to invest tonight but I'll definitely do my part of the job in a day or two.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
should we add a link to the wiki and ask author if we could mirror there ? This section on wiki looks like it could with a bit of fleshing out! http://wiki.dlang.org/Coming_From/Python I just seen what you did in the wiki, that's great! I don't have much time to invest tonight but I'll definitely do my part of the job in a day or two. Thank you for noticing. It's not very inspired, but I don't have much energy at the moment, and it is the best I can do with what I have. Better an acceptable start than trying to be perfect. The Ruby / Java / Eiffel / C# / and Basic sections also need starting.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On 3/27/2015 12:34 PM, w0rp wrote: Sean Parent's advice for no raw loops comes to mind. https://channel9.msdn.com/Events/GoingNative/2013/Cpp-Seasoning With that rule, basically a one-line body for foreach becomes acceptable. This really is a great video. Which leads me to wonder why std.algorithm doesn't have a 'rotate'.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Sat, 28 Mar 2015 18:39:34 +, Russel Winder via Digitalmars-d-announce wrote: yet current CPUs are still the same as 50 years before, that is the problem. ;-) I'd suggest that a Intel x86_64 of 2015 bears only a passing relationship to an IBM 360 of the 1960s. but core principles are still there. it's implementation that is changed, not high-level design. With all the transistors available per mm² these days, it is about time we investigated alternate, implicitly parallel ways of working. Intel had a go a few years ago with various alternative dataflow based architectures, but they were told by the software people that they had no future because software inertia was more important than innovation. yes. computers are huge industry now, and industry resists to innovations that requires industry players to change their processes. on the other side of the spectrum was Chuck Moore, for example, who imagines modern computers filled with many cheap and average RISC processors, and using parallel multiprocessor execution to achieve great performance. and people with expirience on 8-bit Atari, NES or C64 knows by their hearts that having specialized processors can greatly help (and it's a great PITA too ;-). signature.asc Description: PGP signature
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Saturday, 28 March 2015 at 19:16:32 UTC, Russel Winder wrote: If you write your software to fit a particular platform, including hardware features, then you are writing an operating system dedicated to that one specific platform and no other. Yes and I believe writing dedicated specialized operating systems for certain network services (OS as a library) is the future of high load server programming - at least in domains where you can afford the investment. If the idea is to write portable applications then: portable and fast network service aren't really best friends :( I have to encounter a single project that even tries to achieve portability of server code.. The very fact that people are writing in D (or C++, Java, C#,…) means you have accepted some abstraction – otherwise you would be writing in assembly language. Having made the jump to high-level languages why baulk at a small overhead to abstract concurrency and parallelism? 1) some abstractions != any abstractions. One of reasons to use D as opposed to Java or C# is exactly because latter force you into overly expensive abstractions. D in its current state is closer to C++ in this context and this is huge selling point. 2) So far my experience has shown that overhead is not small at all. It depends on type of application of course. Making tasks lightweight processes rather than maintaining shared memory, and using channels to move data around rather than using shared memory and locks, makes applications' concurrency and parallelism easier to construct and manage (*). This comment makes me wonder if we really speak about the same things. Concurrency model based on pinned fibers/threads is not the same thing as getting back to 90s shared memory multi-threading madness. lightweight processes - yes, pinned fibers are very lightweight channels to move data around - message passing between worker threads At no point I have proposed to use shared memory and locks, there is no objection here. If we are prepared to accept overhead for stack and heap management, we must accept the overhead of processor management via thread pooling with work stealing. Custom allocators exist pretty much for the very reason that in certain cases heap management overhead cannot be accepted. For concurrency primitives stakes are much higher.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Sat, 28 Mar 2015 19:17:23 +, Russel Winder via Digitalmars-d-announce wrote: It is a pity that D is not pitching as a Python replacement. D can't: it doesn't dumb enough to attract people that requires compiler enforcements on whitespace to correctly format their code. signature.asc Description: PGP signature
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
Am 28.03.2015 um 19:51 schrieb Walter Bright: On 3/28/2015 8:41 AM, Sönke Ludwig wrote: Am 28.03.2015 um 15:33 schrieb Russel Winder via Digitalmars-d-announce: TLS is the evil here. Anyone working with TLS is either writing an operating system or doing it wrong. As long as we are talking about a closed system that works exclusively on this fiber based concurrency model, I completely agree with you (fiber local storage would be fine, though). But we have the unfortunate situation that the language is not an isolated ecosystem. There are many C libraries that do thread-specific things in one way or another, or worse, make use of ordinary global variables without any protection against data races, and we simply cannot ignore that. One solution (that seems entirely reasonable to me) is to make the droutines (i.e. goroutines) pure. Then the TLS problem goes away. Of course, then I/O isn't possible either, but perhaps a solution can be found for that. I/O is crucial of course, but there are also a lot of other important and inherently impure things such as message passing. I think such a restriction would go way too far. Both fiber and task local storage can also be very useful at times, so it would be a pity to rule them out completely. You'd also usually have the whole application running on droutines and not simply use them as a local tool for occasional parallelism needs. This is especially true for any kind of server application. So effectively such a limitation may in practice end up as a limitation of the entire language.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On 3/28/2015 3:20 AM, Jonathan M Davis via Digitalmars-d-announce wrote: 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. I also do not regard Go as a competitor to D. It's more of a competitor to Java and Ruby.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Saturday, 28 March 2015 at 18:47:04 UTC, Walter Bright wrote: On 3/28/2015 3:20 AM, Jonathan M Davis via Digitalmars-d-announce wrote: 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. I also do not regard Go as a competitor to D. It's more of a competitor to Java and Ruby. I find most people I know using Go are from the python camp and either wanted static typing or faster runtime execution.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On 3/28/2015 8:41 AM, Sönke Ludwig wrote: Am 28.03.2015 um 15:33 schrieb Russel Winder via Digitalmars-d-announce: TLS is the evil here. Anyone working with TLS is either writing an operating system or doing it wrong. As long as we are talking about a closed system that works exclusively on this fiber based concurrency model, I completely agree with you (fiber local storage would be fine, though). But we have the unfortunate situation that the language is not an isolated ecosystem. There are many C libraries that do thread-specific things in one way or another, or worse, make use of ordinary global variables without any protection against data races, and we simply cannot ignore that. One solution (that seems entirely reasonable to me) is to make the droutines (i.e. goroutines) pure. Then the TLS problem goes away. Of course, then I/O isn't possible either, but perhaps a solution can be found for that.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Sat, 2015-03-28 at 18:55 +, Dicebot via Digitalmars-d-announce wrote: […] I don't think it is that simple. From the purist academical parallelism POV - most likely. In practice it often can be quite the contrary, TLS is your best friend (depending on how efficient platfrom implementation is). I suggest it really is that simple even for non-academic applications… To get best high-load performance best strategy is to actually design applications with specific hardware traits in mind, including pre-defined amount of CPU cores and their task affinity. Computation parallelism is relatively easy, it is memory parallelism that remains a challenging task as long as you try to get rid of locking overhead, costly synchronizations and optimize cache loads. Something like moving fibers between threads is absolute disaster in this sense even if it looks like a tempting abstraction on paper. But if you prohibit that by design and maintain strict affinity between fibers and threads, using TLS allows for very nice optimizations (as it is effectively limited sharing without locking / atomics). It can be complicated to design (which is why Go choice makes sense for their target audience) but benefits are also very good. If you write your software to fit a particular platform, including hardware features, then you are writing an operating system dedicated to that one specific platform and no other. If the idea is to write portable applications then: a. you must abstract away from a specific platform; b. you must accept some overhead. The very fact that people are writing in D (or C++, Java, C#,…) means you have accepted some abstraction – otherwise you would be writing in assembly language. Having made the jump to high-level languages why baulk at a small overhead to abstract concurrency and parallelism? Making tasks lightweight processes rather than maintaining shared memory, and using channels to move data around rather than using shared memory and locks, makes applications' concurrency and parallelism easier to construct and manage (*). If we are prepared to accept overhead for stack and heap management, we must accept the overhead of processor management via thread pooling with work stealing. (*) Andrei, this is something of a claim really just now, since although there is anecdotal evidence, I haven't managed to get the psychology of programming people to do statistically significant experiments. I will be trying again at PPIG 2015 to motivate the experiments. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Sat, 2015-03-28 at 18:51 +, weaselcat via Digitalmars-d-announce wrote: On Saturday, 28 March 2015 at 18:47:04 UTC, Walter Bright wrote: On 3/28/2015 3:20 AM, Jonathan M Davis via Digitalmars-d-announce wrote: 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. I also do not regard Go as a competitor to D. It's more of a competitor to Java and Ruby. I find most people I know using Go are from the python camp and either wanted static typing or faster runtime execution. It is a pity that D is not pitching as a Python replacement. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Saturday, 28 March 2015 at 20:35:07 UTC, Walter Bright wrote: On 3/27/2015 12:34 PM, w0rp wrote: Sean Parent's advice for no raw loops comes to mind. https://channel9.msdn.com/Events/GoingNative/2013/Cpp-Seasoning With that rule, basically a one-line body for foreach becomes acceptable. This really is a great video. Which leads me to wonder why std.algorithm doesn't have a 'rotate'. Three iterator algorithms don't really work well with ranges. We have bringToFront instead, which is more general. http://dlang.org/phobos/std_algorithm_mutation.html#.bringToFront
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
Am 28.03.2015 um 21:51 schrieb Walter Bright: On 3/28/2015 1:32 PM, Sönke Ludwig wrote: I/O is crucial of course, but there are also a lot of other important and inherently impure things such as message passing. If the message channel is passed as a parameter to the droutine, then the droutine can still be pure. Only if the methods of the channel are also pure. But they potentially have to interact with the system event loop, which involves impure system API calls. I think such a restriction would go way too far. Both fiber and task local storage can also be very useful at times, so it would be a pity to rule them out completely. You'd also usually have the whole application running on droutines and not simply use them as a local tool for occasional parallelism needs. This is especially true for any kind of server application. So effectively such a limitation may in practice end up as a limitation of the entire language. On the other hand, if purity can make droutines much more practical, the tradeoff might be worth it. If you ask me, they are very practical as they are - in fact much more practical than if they could move between threads, not just because of purity or not. I'm for example heavily using vibe.d's tasks for all kinds of UI, 3D graphics, sound and physics related things. All of these require calling various C libraries that are not be compatible with such a scheme. We could of course add an optional pure+moving mode for those that absolutely need it, but IMHO we should first have hard evidence for practical performance improvements before going such a route.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On 3/28/2015 3:24 PM, Sönke Ludwig wrote: If you ask me, they are very practical as they are - in fact much more practical than if they could move between threads, not just because of purity or not. I'm for example heavily using vibe.d's tasks for all kinds of UI, 3D graphics, sound and physics related things. All of these require calling various C libraries that are not be compatible with such a scheme. We could of course add an optional pure+moving mode for those that absolutely need it, but IMHO we should first have hard evidence for practical performance improvements before going such a route. Sounds very sensible. When can we get it into Phobos? :-)
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Saturday, 28 March 2015 at 14:33:14 UTC, Russel Winder wrote: On Sat, 2015-03-28 at 12:52 +0100, Sönke Ludwig via Digitalmars-d-announce wrote: […] You can access TLS from an event callback just as easy as from a fiber. […] TLS is the evil here. Anyone working with TLS is either writing an operating system or doing it wrong. I don't think it is that simple. From the purist academical parallelism POV - most likely. In practice it often can be quite the contrary, TLS is your best friend (depending on how efficient platfrom implementation is). To get best high-load performance best strategy is to actually design applications with specific hardware traits in mind, including pre-defined amount of CPU cores and their task affinity. Computation parallelism is relatively easy, it is memory parallelism that remains a challenging task as long as you try to get rid of locking overhead, costly synchronizations and optimize cache loads. Something like moving fibers between threads is absolute disaster in this sense even if it looks like a tempting abstraction on paper. But if you prohibit that by design and maintain strict affinity between fibers and threads, using TLS allows for very nice optimizations (as it is effectively limited sharing without locking / atomics). It can be complicated to design (which is why Go choice makes sense for their target audience) but benefits are also very good.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On 3/28/2015 2:01 PM, Peter Alexander wrote: On Saturday, 28 March 2015 at 20:35:07 UTC, Walter Bright wrote: On 3/27/2015 12:34 PM, w0rp wrote: Sean Parent's advice for no raw loops comes to mind. https://channel9.msdn.com/Events/GoingNative/2013/Cpp-Seasoning With that rule, basically a one-line body for foreach becomes acceptable. This really is a great video. Which leads me to wonder why std.algorithm doesn't have a 'rotate'. Three iterator algorithms don't really work well with ranges. We have bringToFront instead, which is more general. http://dlang.org/phobos/std_algorithm_mutation.html#.bringToFront Thank you. I need to learn std.algorithm better.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Sat, 28 Mar 2015 18:41:04 +, weaselcat wrote: On Saturday, 28 March 2015 at 17:57:35 UTC, ketmar wrote: On Sat, 28 Mar 2015 14:28:00 +, Russel Winder via Digitalmars-d-announce wrote: It could be argued that it is all just co-routines underneath, but I think that would be missing the point that we have 55 years more experience of doing these things since that single processor operating system model was created. We really should be doing this all a lot better these days. yet current CPUs are still the same as 50 years before, that is the problem. ;-) heavily disagree it's still good old me dumb computer bip bip with all that low-level register crap and so on. it doesn't matter how much advanced current designs are in their cores, 'cause we -- as users -- see the same old bip- bip shit. signature.asc Description: PGP signature
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Sun, 29 Mar 2015 02:15:38 +, cym13 wrote: On Sunday, 29 March 2015 at 00:24:36 UTC, ketmar wrote: On Sat, 28 Mar 2015 19:17:23 +, Russel Winder via Digitalmars-d-announce wrote: It is a pity that D is not pitching as a Python replacement. D can't: it doesn't dumb enough to attract people that requires compiler enforcements on whitespace to correctly format their code. Urr As an active Python developer, I find that one pretty harsh. It's not that we need to enforce good style, it's that we take good style as granted and choose to lighten it consequently. it was a joke... at least it was almost a joke. signature.asc Description: PGP signature
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On 3/28/2015 1:32 PM, Sönke Ludwig wrote: I/O is crucial of course, but there are also a lot of other important and inherently impure things such as message passing. If the message channel is passed as a parameter to the droutine, then the droutine can still be pure. I think such a restriction would go way too far. Both fiber and task local storage can also be very useful at times, so it would be a pity to rule them out completely. You'd also usually have the whole application running on droutines and not simply use them as a local tool for occasional parallelism needs. This is especially true for any kind of server application. So effectively such a limitation may in practice end up as a limitation of the entire language. On the other hand, if purity can make droutines much more practical, the tradeoff might be worth it.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Saturday, 28 March 2015 at 02:31:37 UTC, Laeeth Isharc wrote: 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. +1 /P
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
Am 28.03.2015 um 10:17 schrieb Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com: 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. You can access TLS from an event callback just as easy as from a fiber. 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. And why can't you do the same with fibers and schedule the fibers accordingly? There is no difference between the two models, except that fibers provide additional persistent state in the form of a stack. 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. It's you who brought up the randomization argument. Tasks are assigned to a more or less random thread that is currently in the scheduling phase, so that your constructed situation is simply *highly* unlikely. 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. They *do* get balanced over threads, just like requests get balanced over instances by the load balancer, even if requests are not moved between instances. But IMO it doesn't make sense to go further with this argument with some actual benchmarks. It's not at all as clear as you'd like what the effects on overall performance and on average/~maximum latency are in practice for different applications. Antyhing less makes fibers a toy language feature IMO.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Sat, 28 Mar 2015 13:27:55 +, Ola Fosheim Grøstad wrote: In essence, you should ideally be able to break a task into all it's independent parts and run them in parallel (i.e.. futures, events etc). Preferably batch them to get better performance, and sort them based on when they have to complete. Then have a mechanism that exerts back-pressure if deadlines are in danger, telling the load balancer to back off. How you go about it depends on the application, but that ought to be the ideal for anything that resembles a modern soft realtime platform. then you have to switch to some functional language, preferably one that does cps transformations in the compiler. as you told somewhere else, D is too broad to be restricted to this. signature.asc Description: PGP signature
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Sat, 2015-03-28 at 11:16 +, ketmar via Digitalmars-d-announce wrote: […] hm. yes, that was coroutines on steroids. But that's the point isn't it: 1. Processes are too heavyweight, invent threads. 2. We have masses of cores, let's map threads to cores via the kernel. 3. Processes and threads are too heavyweight, invent lightweight threads (aka fibres, sort of). It could be argued that it is all just co-routines underneath, but I think that would be missing the point that we have 55 years more experience of doing these things since that single processor operating system model was created. We really should be doing this all a lot better these days. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Fri, 2015-03-27 at 22:48 +, ketmar via Digitalmars-d-announce wrote: […] the whole userspace threads concept is a reimplementation of kernel threads and sheduling. ;-) And kernel threads are a reimplementation of user space threads. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Sat, 28 Mar 2015 11:02:23 +, Russel Winder via Digitalmars-d-announce wrote: On Fri, 2015-03-27 at 22:48 +, ketmar via Digitalmars-d-announce wrote: [â¦] the whole userspace threads concept is a reimplementation of kernel threads and sheduling. ;-) And kernel threads are a reimplementation of user space threads. hm. yes, that was coroutines on steroids. signature.asc Description: PGP signature
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Saturday, 28 March 2015 at 13:27:56 UTC, Ola Fosheim Grøstad wrote: On Friday, 27 March 2015 at 22:32:32 UTC, ketmar wrote: but it is broken! the whole point of async i/o servers is that Note: I presume that you meant servers and no OS-level async i/o (the limitations of unix select() is a different story).
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Sat, 2015-03-28 at 13:27 +, via Digitalmars-d-announce wrote: […] Nah. Cooperative multitasking is a sorry excuse that belongs to the 80s. This should be as transparent as possible. You cannot insert yield into an external library. 1960s. Software developers have spent 50+ years trying to use 1960s operating system concurrency techniques for all of software development. It's time there was some innovation and less conservatism in software concurrency and parallelism. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Saturday, 28 March 2015 at 11:52:34 UTC, Sönke Ludwig wrote: You can access TLS from an event callback just as easy as from a fiber. Yes, but it is much easier to verify that you don't hold onto references to TLS if get rid of arbitrary call stacks when moving to a new thread. And why can't you do the same with fibers and schedule the fibers accordingly? You could, but that's even more work since you then need to encode progress in a way the scheduler can use to estimate when the task can complete and when it must complete. It's you who brought up the randomization argument. Tasks are assigned to a more or less random thread that is currently in the scheduling phase, so that your constructed situation is simply *highly* unlikely. I don't understand how randomization can help you here. They *do* get balanced over threads, just like requests get balanced over instances by the load balancer, even if requests A good load balancer measure back-pressure (load information from the instance) and fire up new instances. are not moved between instances. But IMO it doesn't make sense to go further with this argument with some actual benchmarks. It's not at all as clear as you'd like what the effects on overall performance and on average/~maximum latency are in practice for different applications. This is something you can do on paper. A language feature should support a wide set of applications.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Sat, 2015-03-28 at 12:58 +, Atila Neves via Digitalmars-d-announce wrote: […] It does, and it should. In fact, I'd consider it massive selling point for D if it were; you want easy Go-like concurrency? D has that too. Right now, it's available easily for writing servers: just use vibe.d. But it'd be great if the concurrency was available without depending on the rest of the library. I see no difference between go func and runTask(). select might be a different matter, though, I don't know. I need to be convinced that the concurrency and parallelism model of vibe.d is in fact equivalent to that of goroutines, currently I would say they are very, very different. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Sat, 2015-03-28 at 12:52 +0100, Sönke Ludwig via Digitalmars-d-announce wrote: […] You can access TLS from an event callback just as easy as from a fiber. […] TLS is the evil here. Anyone working with TLS is either writing an operating system or doing it wrong. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Friday, 27 March 2015 at 04:24:52 UTC, Walter Bright wrote: On 3/26/2015 7:06 PM, weaselcat wrote: vibe has (experimental?) green threads, doesn't it? I don't keep up with vibe, so I may be wrong. I don't know, but if it does have good 'uns they should be moved into Phobos! It does, and it should. In fact, I'd consider it massive selling point for D if it were; you want easy Go-like concurrency? D has that too. Right now, it's available easily for writing servers: just use vibe.d. But it'd be great if the concurrency was available without depending on the rest of the library. I see no difference between go func and runTask(). select might be a different matter, though, I don't know. Atila
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Saturday, 28 March 2015 at 13:52:54 UTC, ketmar wrote: then you have to switch to some functional language, preferably one that does cps transformations in the compiler. as you told somewhere else, D is too broad to be restricted to this. Fibers is really not a system level thing. So I don't think D MUST have them as it is claimed that D is meant to be a system level language. I rate D against C/C++/Rust, but not Go per se. I see that Bearophile sometimes express that D should be be pitted with Java/C# rather than C/C++/Rust, but that does not fit for what is claimed for D… The bottom line is: if you decide to make fibers a language/runtime feature you have to make them work well across the board because you are evaluated against other languages that provide them. If it is just an extras library features, then you can make do with basic features, nobody expects more.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
Am 28.03.2015 um 13:32 schrieb Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com: On Saturday, 28 March 2015 at 11:52:34 UTC, Sönke Ludwig wrote: You can access TLS from an event callback just as easy as from a fiber. Yes, but it is much easier to verify that you don't hold onto references to TLS if get rid of arbitrary call stacks when moving to a new thread. It's not mainly about holding references to TLS data, but about program correctness. You store something in a TLS variable and the next time you read it, there is something different in it. This is not only an issue for your own code, but also for external libraries that you have no control or even insight of. Apart from that, what is stopping you to hold such references implicitly in a callback closure? And why can't you do the same with fibers and schedule the fibers accordingly? You could, but that's even more work since you then need to encode progress in a way the scheduler can use to estimate when the task can complete and when it must complete. The fiber part is purely additive. Anything you can to to schedule events in an event based programming model, you can do in a fiber backed one, too. You just have the additional state of the fiber that gets carried around, nothing more. It's you who brought up the randomization argument. Tasks are assigned to a more or less random thread that is currently in the scheduling phase, so that your constructed situation is simply *highly* unlikely. I don't understand how randomization can help you here. Your constructed case will simply not happen in practice. They *do* get balanced over threads, just like requests get balanced over instances by the load balancer, even if requests A good load balancer measure back-pressure (load information from the instance) and fire up new instances. That depends a lot on your infrastructure, but is irrelevant to the point. Tasks get distributed among threads with a sufficiently large number of tasks (like it would happen for a busy web service), you'll have a high load on all threads, so it simply doesn't matter if you move tasks between threads. If you have a low number of requests you may be able to avoid some bad corner cases, but only if you did something stupid in the first place, like mixing long CPU computations without any yield() calls with I/O processing tasks in the same thread (since you seem like a smart person I'll leave it up to you construct cases where moving between threads doesn't help either). are not moved between instances. But IMO it doesn't make sense to go further with this argument with some actual benchmarks. It's not at all as clear as you'd like what the effects on overall performance and on average/~maximum latency are in practice for different applications. This is something you can do on paper. A language feature should support a wide set of applications. *I* can't do that on paper. I invite you to do it and then we can verify your claims with actual measurements. If you don't, this is nothing more than hot air.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
Am 28.03.2015 um 15:33 schrieb Russel Winder via Digitalmars-d-announce: On Sat, 2015-03-28 at 12:52 +0100, Sönke Ludwig via Digitalmars-d-announce wrote: […] You can access TLS from an event callback just as easy as from a fiber. […] TLS is the evil here. Anyone working with TLS is either writing an operating system or doing it wrong. As long as we are talking about a closed system that works exclusively on this fiber based concurrency model, I completely agree with you (fiber local storage would be fine, though). But we have the unfortunate situation that the language is not an isolated ecosystem. There are many C libraries that do thread-specific things in one way or another, or worse, make use of ordinary global variables without any protection against data races, and we simply cannot ignore that.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Sat, 28 Mar 2015 14:28:00 +, Russel Winder via Digitalmars-d-announce wrote: It could be argued that it is all just co-routines underneath, but I think that would be missing the point that we have 55 years more experience of doing these things since that single processor operating system model was created. We really should be doing this all a lot better these days. yet current CPUs are still the same as 50 years before, that is the problem. ;-) signature.asc Description: PGP signature
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Sat, 2015-03-28 at 17:57 +, ketmar via Digitalmars-d-announce wrote: On Sat, 28 Mar 2015 14:28:00 +, Russel Winder via Digitalmars-d-announce wrote: It could be argued that it is all just co-routines underneath, but I think that would be missing the point that we have 55 years more experience of doing these things since that single processor operating system model was created. We really should be doing this all a lot better these days. yet current CPUs are still the same as 50 years before, that is the problem. ;-) I'd suggest that a Intel x86_64 of 2015 bears only a passing relationship to an IBM 360 of the 1960s. It is true that hardware design has been constrained by a weird constraint that no-one has investigated alternative architectures to the register/CPU that software people insist is the only way forward. With all the transistors available per mm² these days, it is about time we investigated alternate, implicitly parallel ways of working. Intel had a go a few years ago with various alternative dataflow based architectures, but they were told by the software people that they had no future because software inertia was more important than innovation. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Saturday, 28 March 2015 at 17:57:35 UTC, ketmar wrote: On Sat, 28 Mar 2015 14:28:00 +, Russel Winder via Digitalmars-d-announce wrote: It could be argued that it is all just co-routines underneath, but I think that would be missing the point that we have 55 years more experience of doing these things since that single processor operating system model was created. We really should be doing this all a lot better these days. yet current CPUs are still the same as 50 years before, that is the problem. ;-) heavily disagree
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Saturday, 28 March 2015 at 18:39:47 UTC, Russel Winder wrote: On Sat, 2015-03-28 at 17:57 +, ketmar via Digitalmars-d-announce wrote: On Sat, 28 Mar 2015 14:28:00 +, Russel Winder via Digitalmars-d-announce wrote: It could be argued that it is all just co-routines underneath, but I think that would be missing the point that we have 55 years more experience of doing these things since that single processor operating system model was created. We really should be doing this all a lot better these days. yet current CPUs are still the same as 50 years before, that is the problem. ;-) I'd suggest that a Intel x86_64 of 2015 bears only a passing relationship to an IBM 360 of the 1960s. It is true that hardware design has been constrained by a weird constraint that no-one has investigated alternative architectures to the register/CPU that software people insist is the only way forward. With all the transistors available per mm² these days, it is about time we investigated alternate, implicitly parallel ways of working. Intel had a go a few years ago with various alternative dataflow based architectures, but they were told by the software people that they had no future because software inertia was more important than innovation. Thoughts on mill architecture?
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
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.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
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
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
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.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
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... ;)
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Friday, 27 March 2015 at 01:47:57 UTC, Walter Bright wrote: The one difference was Go's support for green threads. There's no technical reason why D can't have green threads, it's just that nobody has written the library code to do it. Go can move stacks and extend them. Go is closer to having a low latency GC. These are not small language issues for D.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
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.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On 3/26/2015 11:40 PM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: Go can move stacks and extend them. That has no value on 64 bit systems, and is not a language issue (it's an implementation issue). Go is closer to having a low latency GC. I.e. it doesn't have one. These are not small language issues for D. GC issues are library issues, not language issues.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On 3/27/2015 2:57 AM, Russel Winder via Digitalmars-d-announce wrote: I think the way go handles interfaces and their composition would require a few tricks in D and C++, but I am sure it can be done. Interfaces can be done with D templates. It'll be compile time polymorphism rather than run time, but the same effect will result (and of course it'll be faster). It's pretty much how Ranges work in D. Aren't green threads now given the label fibres? My understanding of fibers is they are all in one thread. Go's green threads can be in multiple threads, the same thread, and even moved from one thread to another. And I think Vibe.d has an implementation for these – but I do not know for certain. I don't know, either. D needs to corral all the bits, which I think are there, to create a good offering. Yes. However, I cannot see this happening purely on volunteer, hobbyist resource. We need to find an organization or three willing to resource this activity. I don't think it's that hard of a problem.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Friday, 27 March 2015 at 09:44:27 UTC, Walter Bright wrote: On 3/27/2015 1:41 AM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: On Friday, 27 March 2015 at 08:25:26 UTC, Walter Bright wrote: The MMU makes it pointless. The virtual address space allows for 4 billion goroutines with 4 billion bytes each of stack. If you fragment the memory space you cannot use recursive page tables? If you want to address more than 512GB you need to move to 1MiB pages. http://wiki.osdev.org/Page_Tables So what? The point is there is PLENTY of virtual address space. You can allocate absurd amounts of address space for each goroutine, and still have plenty without physically moving anything. If you don't care about performance, bloated page tables and laying waste to memory: 1. Page tables are hierarchical, to save space nodes can point back to themselves. IFF the node is similar. Throwing shit all over the memory space makes this impossible. So you get BLOATed page tables. 2. All dirty pages maps to physical memory. So one recursion chain on a fiber will create a big physical mem allocation. To get rid of it you would have make a slow syscall. 3. You have no way to go below the page size for a stack. 4. Operating system calls like mmap are slow. 5. Trapped pages are slow and so are modifying page tables. 6. You cannot expect to get more than 47-53 bits of address space from the OS. It's not like 64 bits CPUs provide 64 bits address space. There is a big hole in the middle. Have you actually thought about these issues or done performance tests?
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Fri, 2015-03-27 at 03:11 -0700, Walter Bright via Digitalmars-d-announce wrote: On 3/27/2015 2:57 AM, Russel Winder via Digitalmars-d-announce wrote: […] However, I cannot see this happening purely on volunteer, hobbyist resource. We need to find an organization or three willing to resource this activity. I don't think it's that hard of a problem. If no-one is resourced to write the code, it will not get written. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
