Re: Release D 2.067.0
On Sun, 29 Mar 2015 06:12:26 +, Vladimir Panteleev wrote: > On Sunday, 29 March 2015 at 06:02:55 UTC, ketmar wrote: >> On Sun, 29 Mar 2015 05:57:59 +, Vladimir Panteleev wrote: >> >>> On Thursday, 26 March 2015 at 06:16:59 UTC, ketmar wrote: i told about that, but nobody cares, as usual. >>> >>> Told where? >> >> in "general", as i mentioned before in this thread. > > Ah, I only now understood what you meant by "general". > > Here's the thread: > > http://forum.dlang.org/post/mec4i0$sej$7...@digitalmars.com > > Fair enough, I did miss it (although I could think of a better subject). > > Please file a regression issue with steps to reproduce, and the details > you have already discovered? there is no need to, as Kenji already did that (i'm sorry for being intrusive with my mails to him), and even made a fix. signature.asc Description: PGP signature
Re: Release D 2.067.0
On Sun, 29 Mar 2015 06:04:05 +, Vladimir Panteleev wrote: > On Sunday, 29 March 2015 at 06:01:41 UTC, ketmar wrote: >> On Sun, 29 Mar 2015 05:56:52 +, Vladimir Panteleev wrote: >> >>> 3. Contact me directly for assistance in using DustMite. I'd be happy >>> to help. >> >> can you make my box faster and do my work while it dustmites the big >> codebase? i didn't know that you are such a wizard. > > If I can reproduce the bug, I could have a go at reducing it myself. that's great. but i can't see how "assistance in using dustmite" means "i will do it myself". besides, i can google and read good enough to find and read dustmite wiki by myself. maybe i'm not a genius, but i'm not dumb. dustmite is a great tool, thank you for it. but please, stop accusing me of not doing the things i did a long time before. maybe there were some other reasons beyond illiteracy that forces me to write in NG seeking voluteers to help. signature.asc Description: PGP signature
Re: Release D 2.067.0
On Sunday, 29 March 2015 at 06:02:55 UTC, ketmar wrote: On Sun, 29 Mar 2015 05:57:59 +, Vladimir Panteleev wrote: On Thursday, 26 March 2015 at 06:16:59 UTC, ketmar wrote: i told about that, but nobody cares, as usual. Told where? in "general", as i mentioned before in this thread. Ah, I only now understood what you meant by "general". Here's the thread: http://forum.dlang.org/post/mec4i0$sej$7...@digitalmars.com Fair enough, I did miss it (although I could think of a better subject). Please file a regression issue with steps to reproduce, and the details you have already discovered?
Re: Release D 2.067.0
On Sunday, 29 March 2015 at 06:01:41 UTC, ketmar wrote: On Sun, 29 Mar 2015 05:56:52 +, Vladimir Panteleev wrote: 3. Contact me directly for assistance in using DustMite. I'd be happy to help. can you make my box faster and do my work while it dustmites the big codebase? i didn't know that you are such a wizard. If I can reproduce the bug, I could have a go at reducing it myself.
Re: Release D 2.067.0
On Sun, 29 Mar 2015 05:56:52 +, Vladimir Panteleev wrote: > 3. Contact me directly for assistance in using DustMite. I'd be happy to > help. can you make my box faster and do my work while it dustmites the big codebase? i didn't know that you are such a wizard. signature.asc Description: PGP signature
Re: Release D 2.067.0
On Sun, 29 Mar 2015 05:57:59 +, Vladimir Panteleev wrote: > On Thursday, 26 March 2015 at 06:16:59 UTC, ketmar wrote: >> i told about that, but nobody cares, as usual. > > Told where? in "general", as i mentioned before in this thread. really, the topic is very easy to locate. that nice web interface can even show topicstarter nick! signature.asc Description: PGP signature
Re: Release D 2.067.0
On Thursday, 26 March 2015 at 11:25:50 UTC, ketmar wrote: Was it filed at issues.dlang.org as a regression? nope, it's not. i was asking for help in "general" (building minimised sample), but nobody was interested. Asked where?
Re: Release D 2.067.0
On Sun, 29 Mar 2015 05:58:33 +, Vladimir Panteleev wrote: > On Thursday, 26 March 2015 at 11:25:50 UTC, ketmar wrote: >>> Was it filed at issues.dlang.org as a regression? >> >> nope, it's not. i was asking for help in "general" (building minimised >> sample), but nobody was interested. > > Asked where? there. signature.asc Description: PGP signature
Re: Release D 2.067.0
On Thursday, 26 March 2015 at 06:16:59 UTC, ketmar wrote: i told about that, but nobody cares, as usual. Told where?
Re: Release D 2.067.0
On Sunday, 29 March 2015 at 02:47:42 UTC, lobo wrote: On Saturday, 28 March 2015 at 14:12:19 UTC, Vladimir Panteleev wrote: Do you think your time is more valuable than that of D contributors' or something? This attitude is crap and is becoming more frequent on the forums. The D development team is not interested in listening to their user base unless the user base is willing to contribute back to D language development with PRs. Not sure how this is related to the discussion at hand. Contributors are more likely to have enough experience with the language to make better suggestions, though. I think that from an outside perspective, it's hard to lose sight that D has no well-defined "devteam". Aside Walter and Andrei, there are no cabals or inner circles. D contributors are all D users who also like to spend some time to improve D. Good luck with that because most end-users will not bother even trying to file a bug report, let alone distill it down with some tool in the compiler download. They'll just move on in another language that doesn't require effort fighting compiler/language bugs. Missing the point. Here is what Ketmar could have done: 1. Create a regression issue with the unreduced test case. This is OK. I occasionally check for unreduced regressions, though usually someone beats me to it. 2. Ask for help with the reduction (e.g. digitalmars.D.learn). He said he did, but I don't see where! Posting deep in some thread doesn't count, very few people read the entire forum. 3. Contact me directly for assistance in using DustMite. I'd be happy to help. I don't think these are unreasonable expectations. If you fail or refuse to at least do the above, and then complain how everything and everyone is horrible, I have no sympathy for you.
Re: Release D 2.067.0
On Sun, 29 Mar 2015 02:47:40 +, lobo wrote: > This attitude is crap and is becoming more frequent on the forums. the funny thing is that D devs managed to convert me from loyal adopter to "asshole". and this has nothing to do with rejecting my ideas per se, btw. the situation now is... bizarre: i love D with passion, but i don't like W&A "driving force" almost with the same passion. that doesn't mean that i'm not grateful to W&A for creating this piece of art, though. 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: Release D 2.067.0
On Saturday, 28 March 2015 at 14:12:19 UTC, Vladimir Panteleev wrote: On Saturday, 28 March 2015 at 05:35:57 UTC, ketmar wrote: On Sat, 28 Mar 2015 04:55:47 +, Vladimir Panteleev wrote: But honestly, there already exists so much information on how to use DustMite... ...that people in bugzilla keep asking what it is. Not knowing what something is and not wanting to learn how to use it are different things. ANYONE should be able to use DustMite or Digger to reduce a test case down to reasonable size. having a big codebase that you didn't wrote and never read took 12 hours to dustmite. not that i can just leave it unattended though, as compiler itself segfaults sometimes, and that effectively leaves dustmite frozen. so it not only eats resources of my box (and i have a work to do, and that work involves compiling big codebases too), but it requires my attention. but yes, it's entirely my fault that i cannot afford such resources and asking for help, i know. Honestly, did you even try? https://github.com/CyberShadow/DustMite/wiki/Detecting-a-segfault-in-dmd-itself https://github.com/CyberShadow/DustMite/wiki/Running-commands-with-a-timeout https://github.com/CyberShadow/DustMite/wiki/Useful-test-scripts Or did you just give up after the first difficulty, saying, "well, I tried"? Do you think your time is more valuable than that of D contributors' or something? This attitude is crap and is becoming more frequent on the forums. The D development team is not interested in listening to their user base unless the user base is willing to contribute back to D language development with PRs. Good luck with that because most end-users will not bother even trying to file a bug report, let alone distill it down with some tool in the compiler download. They'll just move on in another language that doesn't require effort fighting compiler/language bugs. bye, lobo
Re: Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"
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. 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!
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 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 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"
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"
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 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 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"
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 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"
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: GtkD 3.1.0 released, GTK+ with D.
On 2015-03-27 16:47, Mike Wey wrote: On 03/27/2015 10:27 PM, captaindet wrote: On 2015-03-26 17:41, Mike Wey wrote: GtkD is a D binding and OO wrapper of Gtk+ and is released on the LGPL license. Shortly after the last release, GtkD has been updated for GTK+ 3.16. GtkD 3.1.0 is now available on gtkd.org: http://gtkd.org/download.html great news - thanks for your efforts! there is a name conflict though. folder \srcgstreamer\gstreamer\ contains GStreamer.d and gstreamer.d this is not supported on windows machines i don't think DMD supports differentiating between them either. /det Fixed in 3.1.1. thanks a bunch! i ran into something else concerning Builder.addFromString in the 1.x versions it was uint addFromString(string buffer, gsize length) (clumsy C style) in the 2.x versions it became uint addFromString(string buffer) (D-ified, made sense) with 3.x it reverted to uint addFromString(string buffer, size_t length) (back to clumsy C style) i don't really like to change my code again and make it incompatible with 2.x versions. and i don't like the clumsy C style either. i'd appreciate if you could add an overload for the D style 2.x version call. cheers, det
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, 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 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 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 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 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 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 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: Release D 2.067.0
On Sat, 28 Mar 2015 14:12:17 +, Vladimir Panteleev wrote: > Honestly, did you even try? how do you think, where that "12 hours" came from? > Do you think your time is more valuable than that of D contributors' or > something? sure. main D developers shown that they have no respect for other's work (see Andrei calling H.S.Teoh's work of splitting std.algorithm "useless", or Walter blaming me that "the project is badly designed" when it wasn't even my project and i didn't wrote a single line there, and have no understanding of codebase at all), so why should i think that my time is less valuable than theirs? signature.asc Description: PGP signature
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"
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"
Am 28.03.2015 um 13:32 schrieb "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ": 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"
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"
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 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 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 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: Release D 2.067.0
On Saturday, 28 March 2015 at 05:35:57 UTC, ketmar wrote: On Sat, 28 Mar 2015 04:55:47 +, Vladimir Panteleev wrote: But honestly, there already exists so much information on how to use DustMite... ...that people in bugzilla keep asking what it is. Not knowing what something is and not wanting to learn how to use it are different things. ANYONE should be able to use DustMite or Digger to reduce a test case down to reasonable size. having a big codebase that you didn't wrote and never read took 12 hours to dustmite. not that i can just leave it unattended though, as compiler itself segfaults sometimes, and that effectively leaves dustmite frozen. so it not only eats resources of my box (and i have a work to do, and that work involves compiling big codebases too), but it requires my attention. but yes, it's entirely my fault that i cannot afford such resources and asking for help, i know. Honestly, did you even try? https://github.com/CyberShadow/DustMite/wiki/Detecting-a-segfault-in-dmd-itself https://github.com/CyberShadow/DustMite/wiki/Running-commands-with-a-timeout https://github.com/CyberShadow/DustMite/wiki/Useful-test-scripts Or did you just give up after the first difficulty, saying, "well, I tried"? Do you think your time is more valuable than that of D contributors' or something?
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 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 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 such servers spend most of their time waiting for i/o. and if you need to do some lengthy calculations, you either spawns a "real thread" and commands it to wake you up when it is finished, or asking external server to do the job (and wake you when it is finished). Nah. The point is to get parallel work done with less complexity, but at some performance cost. A design where you have to accurately predict running time per task in order to get decent latency is basically adding back the complexity in order to get a simplistic language/runtime with no benefits to the programmer. 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. the whole thing of cooperative multitasking is to be... cooperative. 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.
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 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"
Am 28.03.2015 um 10:17 schrieb "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ": 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 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"
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: GtkD 3.1.0 released, GTK+ with D.
On Fri, 2015-03-27 at 16:46 +, via Digitalmars-d-announce wrote: > On Thursday, 26 March 2015 at 22:41:01 UTC, Mike Wey wrote: > > Shortly after the last release, GtkD has been updated for GTK+ > > 3.16. > > Thank you, that's awesome :) > Can't wait for my distro to get updated to start playing with > this. Why wait, compile from source. I have a short shell script that recompiles and installs using DMD, LDC, and GDC. It doesn't take that long to complete. -- 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 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 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 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: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.
