Re: I have a plan.. I really DO
On Monday, 16 July 2018 at 07:49:33 UTC, Kagamin wrote: On Friday, 13 July 2018 at 19:30:07 UTC, RhyS wrote: If there is a language out there that gaps that C/Java/dynamic fast and easy feel, and offers the ability to compile down with ease. I have not seen it. There's no silver bullet, you can choose from what exists or create your own. If D could be used with automatic reference counting (with native weak references with OPTIONAL automatic cycle collection), while remaining easy to interoperate with C++, that could be a good candidate... I mean having something like that : T* pointer on any type (scalar, struct, class) T strong reference on a class T^ weak reference on a class And have --arc and --acc as compiler options. PS: I know this won't happen unless I implement it myself, I got the message... ;)
Re: I have a plan.. I really DO
On Friday, 13 July 2018 at 19:30:07 UTC, RhyS wrote: If there is a language out there that gaps that C/Java/dynamic fast and easy feel, and offers the ability to compile down with ease. I have not seen it. There's no silver bullet, you can choose from what exists or create your own. Recently we got a CI service that tests some packages from dub, that should deal with regressions.
Re: I have a plan.. I really DO
On Thursday, 12 July 2018 at 14:49:14 UTC, bachmeier wrote: AFAICT, the money goes to internal compiler work to add new features to the language in order to appeal to C++ users. Well, there's also the redesign of the Phobos collections. I don't know if attracting C++ users is currently a specific goal of the D Foundation, but if it is, I suggest listening to the complaints that C++ users make (about C++, not D), e.g. [1]. Ironically, some of the common complaints, like incomprehensible error messages (for templates, anyway), are also common complaints about D. [1] https://www.reddit.com/r/cpp/comments/7lvteh/what_are_the_weakest_points_of_c_in_your_opinion/
Re: I have a plan.. I really DO
On Friday, 13 July 2018 at 19:30:07 UTC, RhyS wrote: On Friday, 13 July 2018 at 13:15:07 UTC, Ecstatic Coder wrote: At the moment, developing in Rust can be quite painful because of too much focus on its borrow checker, as the reference counting system is just a side feature, which is not deeply integrated into the language. And Go suffers from its own problems, mainly related to the excessive limitation of the language features (no genericity, "fake" class inheritance, etc). Those are are big items but its the small stuff that more frustrates. Just deal with some database result fetching. In dynamic languages that is maybe a 5 line of code, Go makes it 4 or 5 times as big. Its just a bit too unwieldy. De facto they are already making room for another language to ultimately fill those gaps... This may be Crystal, D or another yet to come language... Crystal maybe ... but the link Ruby / RoR does create a bit of a artificial barrier. I do notice that Ruby ( not Rails ) is getting more recognition these days. D ... i am being honest but i do not see it. D really has a lot going for it but frankly, the missing default HTTP server is just silly these days. And no, again, Vibe.D is not a good alternative when it breaks on just about every D release or does not perform multi thread correctly ( look up the documentation. Out of date and full of unused information ). What i personally miss is a compile language that simply gets the job done. Take PHP for instance, horrible issues ( a lot less as they cleaned up a lot over the years ) but its most redeeming feature is it gets the job done. It does not force you into a specific pattern, its fast go get visual results, its backward compatability is impressive ( hint hint D ), it just works out of the box with ease. Javascript ( the newer ES version + Node ) also match this more. D looks usable at first for people coming from dynamic languages but they are quickly overwhelmed with the whole C/C++ focus. Crystal is bridging that gap but its still more or less Ruby. So it needs to deal with some of the reputation issues. Where is our Java / C like alternative. Swift? Unfortunately Apple has no interest outside of its own platform and Linux support is spotty. Kotlin/Native? Its moving fast and most people do not realize this. But a long time from finished. Zig? Kind of a C alternative. If there is a language out there that gaps that C/Java/dynamic fast and easy feel, and offers the ability to compile down with ease. I have not seen it. Indeed Kotlin/Native is becoming VERY impressive these days, as it will be usable both for server-side and client-side development, including to develop mobile applications for iOS and Android. https://github.com/jetbrains/kotlinconf-spinner One other very promising language, which almost nobody knows, is Crack, as it's quite performant and could be used to implement practically anything (web servers, games, etc), as it uses automatic reference counting instead of garbage collection. Sad it has absolutely no community (45 Github stars, including mine), and thus will probably stagnate in its current unfinished state (no weak references, fibers, channels, etc).
Re: I have a plan.. I really DO
On Friday, 13 July 2018 at 13:15:07 UTC, Ecstatic Coder wrote: At the moment, developing in Rust can be quite painful because of too much focus on its borrow checker, as the reference counting system is just a side feature, which is not deeply integrated into the language. And Go suffers from its own problems, mainly related to the excessive limitation of the language features (no genericity, "fake" class inheritance, etc). Those are are big items but its the small stuff that more frustrates. Just deal with some database result fetching. In dynamic languages that is maybe a 5 line of code, Go makes it 4 or 5 times as big. Its just a bit too unwieldy. De facto they are already making room for another language to ultimately fill those gaps... This may be Crystal, D or another yet to come language... Crystal maybe ... but the link Ruby / RoR does create a bit of a artificial barrier. I do notice that Ruby ( not Rails ) is getting more recognition these days. D ... i am being honest but i do not see it. D really has a lot going for it but frankly, the missing default HTTP server is just silly these days. And no, again, Vibe.D is not a good alternative when it breaks on just about every D release or does not perform multi thread correctly ( look up the documentation. Out of date and full of unused information ). What i personally miss is a compile language that simply gets the job done. Take PHP for instance, horrible issues ( a lot less as they cleaned up a lot over the years ) but its most redeeming feature is it gets the job done. It does not force you into a specific pattern, its fast go get visual results, its backward compatability is impressive ( hint hint D ), it just works out of the box with ease. Javascript ( the newer ES version + Node ) also match this more. D looks usable at first for people coming from dynamic languages but they are quickly overwhelmed with the whole C/C++ focus. Crystal is bridging that gap but its still more or less Ruby. So it needs to deal with some of the reputation issues. Where is our Java / C like alternative. Swift? Unfortunately Apple has no interest outside of its own platform and Linux support is spotty. Kotlin/Native? Its moving fast and most people do not realize this. But a long time from finished. Zig? Kind of a C alternative. If there is a language out there that gaps that C/Java/dynamic fast and easy feel, and offers the ability to compile down with ease. I have not seen it.
Re: I have a plan.. I really DO
On Thursday, 12 July 2018 at 12:07:55 UTC, wjoe wrote: On Tuesday, 10 July 2018 at 17:25:11 UTC, Yuxuan Shui wrote: Whether or not rust, go, etc. are just as or more popular than C++ or Java in 30 years remains to be seen. Rust and Go have their strengths, but also suffer from serious usability flaws, so I'm not sure they can become as predominant as C++ in the years to come. At the moment, developing in Rust can be quite painful because of too much focus on its borrow checker, as the reference counting system is just a side feature, which is not deeply integrated into the language. And Go suffers from its own problems, mainly related to the excessive limitation of the language features (no genericity, "fake" class inheritance, etc). De facto they are already making room for another language to ultimately fill those gaps... This may be Crystal, D or another yet to come language...
Re: I have a plan.. I really DO
On Thursday, 12 July 2018 at 11:36:15 UTC, RhyS wrote: Its the same with the donations. I stated before that D as a organisation with its financing feels very mysterious. You do not see where the money goes I've raised this issue elsewhere. I think there would be more incentive to donate if the money were used to do the boring things that are needed to make the language more usable. AFAICT, the money goes to internal compiler work to add new features to the language in order to appeal to C++ users. The work is done in secret (well, unless you want to go through Github threads) and there is not much communication even after it's done. I think a larger issue is that a lot of older community members have been with the D language for years upon years and they are tired of people complaining on issues. Actually, they are the ones that do most of the complaining. They do get upset when others make false arguments though. Part of that is simply that people come to D looking for a easy language and discover the over focus on C/C++ and run into the issues. True. Lately all official communications about D are about memory management, making the language as complicated and boring as Rust. That's not the fault of the D leadership though. It reflects the lack of effort on the part of others that want to use the language for something other than a C++ replacement. There is nothing stopping anyone from building up a community that is not connected to the core language developers. That is actually how it works with any successful language. If you think you could do a better job dealing with the rough edges, just go ahead and do it. You don't need permission. That's how open source works, and indeed, the fact that you don't need permission is the point of open source.
Re: I have a plan.. I really DO
On Tuesday, 10 July 2018 at 17:25:11 UTC, Yuxuan Shui wrote: (Although I don't quite agree with you. Some people DO resist change, that's why some decades old languages are still popular. But look at the popularity of new languages like Go, and Rust, and the ever-change landscape of front-end development. There're tons of people who adapt certain technology just because it is new, why can't that happen to D?) Because they are humans. Because the masses fly to hip stuff like moths to light. Because people make decisions out of a mood or because of peer pressure and based on opinion rather than facts. Because a lot of people use it so it can't be bad !? You can see that phenomenon in Hardware and end user software and really every other aspect of life, too, by the way. It's almost always the hyped shh-stuff that gets wide spread use. How many of these people are using it because they want to ? How many are happy with the language, rather than just being part of the flock ? To be able to call oneself hip ? To be part of the group ? Whether or not rust, go, etc. are just as or more popular than C++ or Java in 30 years remains to be seen.
Re: I have a plan.. I really DO
On Wednesday, 11 July 2018 at 21:19:18 UTC, Ecstatic Coder wrote: I agree. And I must admit that from that point of view I'm indeed part of the problem... Its a problem every open source project faces. No matter if its D or Crystal or ... The main issue is that many people in those open source project forget, that the people who come to their project/language are only looking to use it for their work. They are not looking to spend x amount of time on open source development because they have their own projects or work. Is it unfair that the mass benefits from the work of the few. Sure. But putting the blame on the people who use the tools and see them as problems is kind of ironic. If the goal is to get a successful language, those type of blame attitudes are only counter productive. For most people its easy to switch languages when they have little invested and complain about issues. Its the same with the donations. I stated before that D as a organisation with its financing feels very mysterious. You do not see where the money goes and people are not motivated to donate to a organisation when they feel their complains are not taken serious. A lot of open source project simply forget that its all about marketing and community creation. If you fail at one of them, like being semi aggressive when new users complain, it simply cuts into your own pockets. D has a massive increased in downloads but has a hard time actually keeping the people interested who download the D compiler. That normally needs to be a wake up call for any community. I think a larger issue is that a lot of older community members have been with the D language for years upon years and they are tired of people complaining on issues. It also does not help that D simply keeps getting more features that few people care about outside a very small group of programmers. BetterC ... your not going to convert a lot of C developers. D as a C++ replacement, C++ 14/17 keeps improving, why change over to D with less resources. In my personal opinion Crystal is gaining more momentum then D despite that D has a much more active blog/communication. Part of that is simply that people come to D looking for a easy language and discover the over focus on C/C++ and run into the issues. Add a bit of semi-aggressive forum members when complains show up and there goes your new user looking at Go or another language.
Re: I have a plan.. I really DO
On Tuesday, 10 July 2018 at 10:48:30 UTC, bauss wrote: On Friday, 6 July 2018 at 23:27:57 UTC, RhyS wrote: Total 1336 packages found. 3359 total shards D has had a major release. Crystal has had a minor release. Total 1339 packages 3382 total shards This is a really weak point, because it doesn't show the quality of the packages. Just look at npm. That is a straw man argument. I challenge you to see the packages and compare: https://crystalshards.xyz/?sort=updated=1 https://code.dlang.org/?sort=updated And then tell about the quality.
Re: I have a plan.. I really DO
This is one of the things about open source / volunteer projects that may or may not be a good thing (it can be argued both ways). Since people aren't getting paid to do grunt work, if nobody steps up to the plate to fix an issue, it will either just sit there forever, or it will fall upon Walter and Andrei to get to it, which, given how much is already on their plate, will take a very, very long time. And people will just work on whatever interests them. Happy D users who don't find any problems (for THEIR use case) won't have much motivation to contribute to something that doesn't directly benefit them (or they don't even use it). Unhappy D users who *do* find a problem will either step up and fix it and contribute it so that the rest of the community benefits, or they will choose not to participate, in which case nothing happens. I'm not trying to justify this situation, but having observed how things work around here for the past many years, that's just the way things work. Either somebody gets ticked off enough to actually do something about an issue, resulting in all-round benefits, or they just do nothing, and nothing happens. (Complaining in the forums doesn't count, since it has been proven time and time again that this almost never leads to any actual change.) This is unlike how most commercially driven projects work, for obvious reasons, and for better or for worse, that's what we have to deal with. (Personally I think this is actually a good thing, but I'm guessing many people will disagree.) So saying "wouldn't it be much more effective that the D experts of this forum simply fix the open source code" ultimately won't lead to much change, for better or for worse. *Somebody* has to step up to do it. Expecting somebody else to spend their unpaid volunteer time to work on something that may not really interest them is, to say the least, unrealistic. The solution, as Walter says, is to "be the change you want to see". I agree. And I must admit that from that point of view I'm indeed part of the problem...
Re: I have a plan.. I really DO
On Wed, Jul 11, 2018 at 09:36:25AM +, Ecstatic Coder via Digitalmars-d-announce wrote: [...] > Except for Crystal, I think that D is superior to many languages in > *ease of use* and *expressivity*, and I really like it a lot for that. > > But for technical aspect like performance, very honestly I'm still not > sure of its technical superiority over similar languages. > > For instance, I'm personally convinced that a Go web server can often > beat its vibe.d equivalent in technical aspects like raw performance, > memory consumption, multi-core usage, etc. Recently, it has been openly acknowledged that vibe.d is not the most efficient for certain use cases. I don't know if the problem has been solved yet, but I assume somebody's working on it. > And even if benchmarks are always to be interpreted cautiously, when > several of them lead to exactly the same conclusion as my own tests, > and with such big margins, it's very hard to completely ignore them. It's true that benchmarks results should always be taken with a grain of salt, but that doesn't mean D is already flawless and we don't need to improve things. On the contrary, I think there's lots of room for improvement, which is one of the things that draws me to D, because here's a chance to contribute something meaningful to a powerful, easy to use language. That's the advantage of a true open source project, where money isn't the driving factor, but people solving real problems and honing it to be something excellent -- and anyone can participate if they choose to. [...] > But in terms of communication, wouldn't it be much more effective that > the D experts of this forum simply fix the open source code of those > benchmarks to make D's technical superiority much more obvious, so > that the decision makers of software development companies, which > stupidly use the informations of such benchmarks when investigating > alternative technologies, can more easily suggest to their leadership > to switch to D ? This is one of the things about open source / volunteer projects that may or may not be a good thing (it can be argued both ways). Since people aren't getting paid to do grunt work, if nobody steps up to the plate to fix an issue, it will either just sit there forever, or it will fall upon Walter and Andrei to get to it, which, given how much is already on their plate, will take a very, very long time. And people will just work on whatever interests them. Happy D users who don't find any problems (for THEIR use case) won't have much motivation to contribute to something that doesn't directly benefit them (or they don't even use it). Unhappy D users who *do* find a problem will either step up and fix it and contribute it so that the rest of the community benefits, or they will choose not to participate, in which case nothing happens. I'm not trying to justify this situation, but having observed how things work around here for the past many years, that's just the way things work. Either somebody gets ticked off enough to actually do something about an issue, resulting in all-round benefits, or they just do nothing, and nothing happens. (Complaining in the forums doesn't count, since it has been proven time and time again that this almost never leads to any actual change.) This is unlike how most commercially driven projects work, for obvious reasons, and for better or for worse, that's what we have to deal with. (Personally I think this is actually a good thing, but I'm guessing many people will disagree.) So saying "wouldn't it be much more effective that the D experts of this forum simply fix the open source code" ultimately won't lead to much change, for better or for worse. *Somebody* has to step up to do it. Expecting somebody else to spend their unpaid volunteer time to work on something that may not really interest them is, to say the least, unrealistic. The solution, as Walter says, is to "be the change you want to see". T -- When solving a problem, take care that you do not become part of the problem.
Re: I have a plan.. I really DO
On Wednesday, 11 July 2018 at 13:57:45 UTC, SrMordred wrote: But for technical aspect like performance, very honestly I'm still not sure of its technical superiority over similar languages. Just have a look at this one, which is quite famous : https://www.techempower.com/benchmarks/ I know that many people here will simply tell me that all those personal et external benchmarks are all wrong, etc. Maybe you are right. But in terms of communication, wouldn't it be much more effective that the D experts of this forum simply fix the open source code of those benchmarks to make D's technical superiority much more obvious, so that the decision makers of software development companies, which stupidly use the informations of such benchmarks when investigating alternative technologies, can more easily suggest to their leadership to switch to D ? I' quite sure that D can achieve performance equivalence with any other language. I don´t see any reason not to. About that specific benchmark, not sure vibe.d had some updates since the first time I saw because I remembered people arguing here about why it was not that good on performance. Maybe now it will make better results. And I agree about the communication part. Altough i like to see benchmarks and like to see the competition part of it their objective is just to point out that "we can do as much as these other guys can". When benchmarks go slow people say that "benchmark is not everything or are wrong somehow". But then when D get the fastest regex parser of the world, is all proud :) But again, I believe that D can be performance competitive in any case. Sincerely speaking D language does not merit all these criticism. The magnitude of criticism on D language does not really make sense to me. I am yet to see a language so user friendly as D with such power and strength.I trust one day the world will see and know that D is a language build for programmers for great productivity and not just another money making machine
Re: I have a plan.. I really DO
But for technical aspect like performance, very honestly I'm still not sure of its technical superiority over similar languages. Just have a look at this one, which is quite famous : https://www.techempower.com/benchmarks/ I know that many people here will simply tell me that all those personal et external benchmarks are all wrong, etc. Maybe you are right. But in terms of communication, wouldn't it be much more effective that the D experts of this forum simply fix the open source code of those benchmarks to make D's technical superiority much more obvious, so that the decision makers of software development companies, which stupidly use the informations of such benchmarks when investigating alternative technologies, can more easily suggest to their leadership to switch to D ? I' quite sure that D can achieve performance equivalence with any other language. I don´t see any reason not to. About that specific benchmark, not sure vibe.d had some updates since the first time I saw because I remembered people arguing here about why it was not that good on performance. Maybe now it will make better results. And I agree about the communication part. Altough i like to see benchmarks and like to see the competition part of it their objective is just to point out that "we can do as much as these other guys can". When benchmarks go slow people say that "benchmark is not everything or are wrong somehow". But then when D get the fastest regex parser of the world, is all proud :) But again, I believe that D can be performance competitive in any case.
Re: I have a plan.. I really DO
On Friday, 6 July 2018 at 15:19:33 UTC, Ecstatic Coder wrote: Actually you answer was right even if the point count was not stored as an integer ;) For C++, the answer is : never. Two small memory blocks will have to be allocated from the memory pool, which is not smart, obviously, but apart of that, nothing to worry about. Because there is no garbage collector in C++, memory has to be allocated and deallocated in a continuous manner... Recently it got somewhat pushed by Electron applications :)
Re: I have a plan.. I really DO
On Tuesday, 10 July 2018 at 18:20:27 UTC, H. S. Teoh wrote: On Tue, Jul 10, 2018 at 05:25:11PM +, Yuxuan Shui via Digitalmars-d-announce wrote: On Friday, 6 July 2018 at 21:15:46 UTC, H. S. Teoh wrote: [...] > Of course, for someone looking for an excuse not to use D, > they will always find another reason why this is not > sufficient. But that only strengthens the point that the GC > is just a convenient excuse not to use D. Not a good excuse to not fix GC, though. Of course. The current GC, while decent, does leave lots of room for improvement. Unfortunately, while much talked about, not many people are willing to actually put in the work to improve it. So I'm not really interested in generating more talk, as opposed to action. > Solve that problem, and they will just move on to the next > excuse, because the GC is not the real reason; the real > reason is probably non-technical. Like good ole inertia: > people are lazy and set in their ways, and resist changing > what they've grown comfortable with. But actually admitting > this would make them look bad, so it is easier to find a > convenient excuse like the GC (or whatever else is different > from the status quo). If that's the case, then we are doom. We might just as well forget about getting popular, and instead spend time making the language better. I have always been skeptical of popularity. It is neither a necessary nor sufficient condition for improved language quality. That's not to say we should not invest effort in marketing D... but popularity does not imply technical superiority, and the only reason I'm here is because of D's technical superiority. Like fixing the GC. Nobody argues *against* fixing the GC. But, who will actually do it? As opposed to the crowds who are very willing to only talk about it. (Although I don't quite agree with you. Some people DO resist change, that's why some decades old languages are still popular. But look at the popularity of new languages like Go, and Rust, and the ever-change landscape of front-end development. There're tons of people who adapt certain technology just because it is new, why can't that happen to D?) [...] Those who adapt technology merely because it's new, are what I call the bandwagon jumpers. They will flock to the next brand new thing, and then just as readily leave in droves once the novelty has worn off. They are unreliable customers, and I wouldn't build a business based on their continuing support. Again, popularity is orthogonal to technical excellence. T Except for Crystal, I think that D is superior to many languages in *ease of use* and *expressivity*, and I really like it a lot for that. But for technical aspect like performance, very honestly I'm still not sure of its technical superiority over similar languages. For instance, I'm personally convinced that a Go web server can often beat its vibe.d equivalent in technical aspects like raw performance, memory consumption, multi-core usage, etc. And even if benchmarks are always to be interpreted cautiously, when several of them lead to exactly the same conclusion as my own tests, and with such big margins, it's very hard to completely ignore them. Just have a look at this one, which is quite famous : https://www.techempower.com/benchmarks/ I know that many people here will simply tell me that all those personal et external benchmarks are all wrong, etc. Maybe you are right. But in terms of communication, wouldn't it be much more effective that the D experts of this forum simply fix the open source code of those benchmarks to make D's technical superiority much more obvious, so that the decision makers of software development companies, which stupidly use the informations of such benchmarks when investigating alternative technologies, can more easily suggest to their leadership to switch to D ?
Re: I have a plan.. I really DO
On Tue, Jul 10, 2018 at 05:25:11PM +, Yuxuan Shui via Digitalmars-d-announce wrote: > On Friday, 6 July 2018 at 21:15:46 UTC, H. S. Teoh wrote: [...] > > Of course, for someone looking for an excuse not to use D, they will > > always find another reason why this is not sufficient. But that only > > strengthens the point that the GC is just a convenient excuse not to > > use D. > > Not a good excuse to not fix GC, though. Of course. The current GC, while decent, does leave lots of room for improvement. Unfortunately, while much talked about, not many people are willing to actually put in the work to improve it. So I'm not really interested in generating more talk, as opposed to action. > > Solve that problem, and they will just move on to the next excuse, > > because the GC is not the real reason; the real reason is probably > > non-technical. Like good ole inertia: people are lazy and set in > > their ways, and resist changing what they've grown comfortable with. > > But actually admitting this would make them look bad, so it is > > easier to find a convenient excuse like the GC (or whatever else is > > different from the status quo). > > If that's the case, then we are doom. We might just as well forget > about getting popular, and instead spend time making the language > better. I have always been skeptical of popularity. It is neither a necessary nor sufficient condition for improved language quality. That's not to say we should not invest effort in marketing D... but popularity does not imply technical superiority, and the only reason I'm here is because of D's technical superiority. > Like fixing the GC. Nobody argues *against* fixing the GC. But, who will actually do it? As opposed to the crowds who are very willing to only talk about it. > (Although I don't quite agree with you. Some people DO resist change, > that's why some decades old languages are still popular. But look at > the popularity of new languages like Go, and Rust, and the ever-change > landscape of front-end development. There're tons of people who adapt > certain technology just because it is new, why can't that happen to > D?) [...] Those who adapt technology merely because it's new, are what I call the bandwagon jumpers. They will flock to the next brand new thing, and then just as readily leave in droves once the novelty has worn off. They are unreliable customers, and I wouldn't build a business based on their continuing support. Again, popularity is orthogonal to technical excellence. T -- "I'm not childish; I'm just in touch with the child within!" - RL
Re: I have a plan.. I really DO
On Tuesday, 10 July 2018 at 17:44:59 UTC, Adam D. Ruppe wrote: On Tuesday, 10 July 2018 at 17:39:06 UTC, SrMordred wrote: After the GC.collect you now get 1GB of memory usage. http://dpldocs.info/experimental-docs/core.memory.GC.minimize.html yeah I was looking to this right now on the docs, thks :) But still, all this knowledge about GC and all this calls to put the memory where you want, will happen automatically most of the time with the old scoped resources/RAII(and unique_ptr/shared_ptr, that D also have). GC tradeoffs never really paid well for me. (or my mindset is very stuck in the old ways :P)
Re: I have a plan.. I really DO
On Tuesday, 10 July 2018 at 17:39:06 UTC, SrMordred wrote: After the GC.collect you now get 1GB of memory usage. http://dpldocs.info/experimental-docs/core.memory.GC.minimize.html
Re: I have a plan.. I really DO
On Tuesday, 10 July 2018 at 17:03:01 UTC, H. S. Teoh wrote: AFAIK, the current GC does not release memory back to the OS. So you won't see the memory footprint decrease. However, it does free up memory for subsequent allocations. T if you put another int[] x; x.length = 1024 * 1024 * 128; After the GC.collect you now get 1GB of memory usage. My point is, this type of control is not enough control for anyone coming from a non-GC language, so they will point out GC as a problem. And in my opinion with reason. I´m using my own lib on D with nogc container and other utilities to avoid completly the GC. Altought I know that is completly possible to use GC and have good performance, I dont think the arguments for it are enough to convince most people. I find D awesome (and probably will never look at C++ again), but for me you can remove GC completly from the language and it will continue to be aswesome. (For me, i'm hoping to compile everything that I have with -betterC in the future. Waiting for some bugs related to betterC to be solved)
Re: I have a plan.. I really DO
On Friday, 6 July 2018 at 21:15:46 UTC, H. S. Teoh wrote: On Fri, Jul 06, 2018 at 08:16:36PM +, Ecstatic Coder via Digitalmars-d-announce wrote: [...] I've never said that this is something smart to do. I'm just saying that this code can perfectly be executed once in a C++ game frame without having to worry for a game freeze, because the string buffer deallocation is done once per frame too. While with many GC languages, you actually DON'T KNOW when all those unused string buffers will be claimed. [...] Of course, for someone looking for an excuse not to use D, they will always find another reason why this is not sufficient. But that only strengthens the point that the GC is just a convenient excuse not to use D. Not a good excuse to not fix GC, though. Solve that problem, and they will just move on to the next excuse, because the GC is not the real reason; the real reason is probably non-technical. Like good ole inertia: people are lazy and set in their ways, and resist changing what they've grown comfortable with. But actually admitting this would make them look bad, so it is easier to find a convenient excuse like the GC (or whatever else is different from the status quo). If that's the case, then we are doom. We might just as well forget about getting popular, and instead spend time making the language better. Like fixing the GC. (Although I don't quite agree with you. Some people DO resist change, that's why some decades old languages are still popular. But look at the popularity of new languages like Go, and Rust, and the ever-change landscape of front-end development. There're tons of people who adapt certain technology just because it is new, why can't that happen to D?) T
Re: I have a plan.. I really DO
On Tue, Jul 10, 2018 at 04:07:01PM +, SrMordred via Digitalmars-d-announce
wrote:
> > As I've already repeated twice, this is not true in D. You *can*
> > predict precisely when the GC runs a collection cycle by calling
> > GC.disable and then calling GC.collect according to *your* own
> > schedule. This is not just a theoretical thing. I have actually
> > done this in my own projects, and it does work.
>
> Sorry, can you help me with this?
>
> Eg.
> void doit()
> {
> int[] x;
> x.length = 1024 * 1024 * 128;
> }
>
> void main()
> {
> import core.memory : GC;
> import core.thread;
> GC.disable;
>
> doit; //alloc +- 500mb inside the func.
> Thread.sleep(5.seconds); //500mb still in use.
> GC.collect; //hmmm still there
> Thread.sleep(5.seconds); //same
> }
[...]
AFAIK, the current GC does not release memory back to the OS. So you
won't see the memory footprint decrease. However, it does free up
memory for subsequent allocations.
T
--
It is of the new things that men tire --- of fashions and proposals and
improvements and change. It is the old things that startle and intoxicate. It
is the old things that are young. -- G.K. Chesterton
Re: I have a plan.. I really DO
As I've already repeated twice, this is not true in D. You
*can* predict precisely when the GC runs a collection cycle by
calling GC.disable and then calling GC.collect according to
*your* own schedule. This is not just a theoretical thing. I
have actually done this in my own projects, and it does work.
Sorry, can you help me with this?
Eg.
void doit()
{
int[] x;
x.length = 1024 * 1024 * 128;
}
void main()
{
import core.memory : GC;
import core.thread;
GC.disable;
doit; //alloc +- 500mb inside the func.
Thread.sleep(5.seconds); //500mb still in use.
GC.collect; //hmmm still there
Thread.sleep(5.seconds); //same
}
Re: I have a plan.. I really DO
On Friday, 6 July 2018 at 23:27:57 UTC, RhyS wrote: Total 1336 packages found. 3359 total shards D has had a major release. Crystal has had a minor release. Total 1339 packages 3382 total shards This is a really weak point, because it doesn't show the quality of the packages. Just look at npm.
Re: I have a plan.. I really DO
On Friday, 6 July 2018 at 20:16:36 UTC, Ecstatic Coder wrote: Pfff, it was just an EXAMPLE of how some insignificant string concatenation code may eventually be a problem in any GC language even if it's done only once per frame. It does not matter that your point is a example. People will rip it apart a dozen times. "the only winning move is not to play." D will never be a industry accepted game engine replacement language ( beyond the few hard core people ). The whole GC is irrelevant from the start. Without GC D is barely a better C. With GC your forced to do more work to avoid the GC issues ( compared to C++ ). D has almost no resources for game developer. Few qualified D developers. Let alone the resource that are required. And the issues. No company in their right mind will ever pick D for developing a **high performance** game engine. D barely keeps up with there own internal issues. So this idea that D has any hope as a Game Engine language ( beyond hobby projects and the oneof company with some D die hards ), is just ridiculous. There is simply more change for a new language with more public traction to be picked for game engines in the future if C++ dies out, then D. That is a fact. And a person does not need to be a troll to dare say this. D has a limited growth and its easy to see... Just 6 days ago i posted this here: Total 1336 packages found. 3359 total shards D has had a major release. Crystal has had a minor release. Total 1339 packages 3382 total shards D has gained 3 packages. Crystal has gained 23 packages. Lets trow from a different angle. Updates: Crystal has 37 shard updates in 24 hours. D has 7 packages updates in the same time. If a 16 year old language that pushes itself as a C++ replacement language can not keep up with a newcomer like language. And dare i mention Go, Rust, ... I see a lot of people talking on the D forum. But few actually do a lot. I see few people talking on Crystal forums but a lot of people actually busy coding. Different mindset? If i can be frank, even if the D community magically solves a lot of their internal issues, its hard to make a comeback in this industry. Its like Pascal has a change to become popular again. And i am sure that Pascal people will defend their languages just as much as the D people, pointing out more downloads and more activity.
Re: I have a plan.. I really DO
Friday, 6 July 2018 at 21:15:46 UTC, H. S. Teoh wrote: On Fri, Jul 06, 2018 at 08:16:36PM +, Ecstatic Coder via Digitalmars-d-announce wrote: [...] I've never said that this is something smart to do. I'm just saying that this code can perfectly be executed once in a C++ game frame without having to worry for a game freeze, because the string buffer deallocation is done once per frame too. While with many GC languages, you actually DON'T KNOW when all those unused string buffers will be claimed. [...] As I've already repeated twice, this is not true in D. You *can* predict precisely when the GC runs a collection cycle by calling GC.disable and then calling GC.collect according to *your* own schedule. This is not just a theoretical thing. I have actually done this in my own projects, and it does work. Of course, for someone looking for an excuse not to use D, they will always find another reason why this is not sufficient. But that only strengthens the point that the GC is just a convenient excuse not to use D. Solve that problem, and they will just move on to the next excuse, because the GC is not the real reason; the real reason is probably non-technical. Like good ole inertia: people are lazy and set in their ways, and resist changing what they've grown comfortable with. But actually admitting this would make them look bad, so it is easier to find a convenient excuse like the GC (or whatever else is different from the status quo). T +1
Re: I have a plan.. I really DO
On Fri, Jul 06, 2018 at 08:16:36PM +, Ecstatic Coder via Digitalmars-d-announce wrote: [...] > I've never said that this is something smart to do. I'm just saying > that this code can perfectly be executed once in a C++ game frame > without having to worry for a game freeze, because the string buffer > deallocation is done once per frame too. > > While with many GC languages, you actually DON'T KNOW when all those > unused string buffers will be claimed. [...] As I've already repeated twice, this is not true in D. You *can* predict precisely when the GC runs a collection cycle by calling GC.disable and then calling GC.collect according to *your* own schedule. This is not just a theoretical thing. I have actually done this in my own projects, and it does work. Of course, for someone looking for an excuse not to use D, they will always find another reason why this is not sufficient. But that only strengthens the point that the GC is just a convenient excuse not to use D. Solve that problem, and they will just move on to the next excuse, because the GC is not the real reason; the real reason is probably non-technical. Like good ole inertia: people are lazy and set in their ways, and resist changing what they've grown comfortable with. But actually admitting this would make them look bad, so it is easier to find a convenient excuse like the GC (or whatever else is different from the status quo). T -- Knowledge is that area of ignorance that we arrange and classify. -- Ambrose Bierce
Re: I have a plan.. I really DO
On Friday, 6 July 2018 at 19:22:13 UTC, 12345swordy wrote: On Friday, 6 July 2018 at 17:59:27 UTC, Ecstatic Coder wrote: While ANY C++ game can make ANY number of allocations/allocations inside a game loop and still run without a risking any freeze. You are doing something very wrong if you are doing this. -Alexander Just try it. For what rhyme or reason!? You shouldn't be allocating and deallocating inside a critical loop in the first place! Regardless people have shown you solutions regarding string concatenation. Are you going to address that or you just going to ignore them? -Alexander Pfff, it was just an EXAMPLE of how some insignificant string concatenation code may eventually be a problem in any GC language even if it's done only once per frame. I've never said that this is something smart to do. I'm just saying that this code can perfectly be executed once in a C++ game frame without having to worry for a game freeze, because the string buffer deallocation is done once per frame too. While with many GC languages, you actually DON'T KNOW when all those unused string buffers will be claimed. This ignorance is, in my opinion, the root of this "phoebia". If you disagree with me, fine. No problem. Maybe I'm wrong. But this is my opinion. Please feel free to ignore it.
Re: I have a plan.. I really DO
On Friday, 6 July 2018 at 19:27:51 UTC, 12345swordy wrote: On Friday, 6 July 2018 at 19:22:13 UTC, 12345swordy wrote: On Friday, 6 July 2018 at 17:59:27 UTC, Ecstatic Coder wrote: While ANY C++ game can make ANY number of allocations/allocations inside a game loop and still run without a risking any freeze. You are doing something very wrong if you are doing this. -Alexander Just try it. For what rhyme or reason!? You shouldn't be allocating and deallocating inside a critical loop in the first place! Regardless people have shown you solutions regarding string concatenation. Are you going to address that or you just going to ignore them? -Alexander Also when I used the word phobia I was pretty sure that I was referring to irrational fear of things. Big emphasis on the word "irrational". -Aleaxander Irrational would mean this would be impossible to have a GC freeze because of just one string concatenation during the game loop of a garbage collected language.
Re: I have a plan.. I really DO
On Friday, 6 July 2018 at 19:56:23 UTC, JN wrote: On Friday, 6 July 2018 at 18:19:08 UTC, Ecstatic Coder wrote: Because in C++, smart pointers and collections will make sure to free unused memory block as soon as they need to, and no later. I bet if D was reference counted from the start, C++ programmers would complain about "smart pointer overhead" and how ref counting is too slow for games/real time and you should be able to manage your memory yourself. Probably ;)
Re: I have a plan.. I really DO
On Friday, 6 July 2018 at 18:19:08 UTC, Ecstatic Coder wrote: Because in C++, smart pointers and collections will make sure to free unused memory block as soon as they need to, and no later. I bet if D was reference counted from the start, C++ programmers would complain about "smart pointer overhead" and how ref counting is too slow for games/real time and you should be able to manage your memory yourself.
Re: I have a plan.. I really DO
On Friday, 6 July 2018 at 19:22:13 UTC, 12345swordy wrote: On Friday, 6 July 2018 at 17:59:27 UTC, Ecstatic Coder wrote: While ANY C++ game can make ANY number of allocations/allocations inside a game loop and still run without a risking any freeze. You are doing something very wrong if you are doing this. -Alexander Just try it. For what rhyme or reason!? You shouldn't be allocating and deallocating inside a critical loop in the first place! Regardless people have shown you solutions regarding string concatenation. Are you going to address that or you just going to ignore them? -Alexander Also when I used the word phobia I was pretty sure that I was referring to irrational fear of things. Big emphasis on the word "irrational". -Aleaxander
Re: I have a plan.. I really DO
On Friday, 6 July 2018 at 17:59:27 UTC, Ecstatic Coder wrote: While ANY C++ game can make ANY number of allocations/allocations inside a game loop and still run without a risking any freeze. You are doing something very wrong if you are doing this. -Alexander Just try it. For what rhyme or reason!? You shouldn't be allocating and deallocating inside a critical loop in the first place! Regardless people have shown you solutions regarding string concatenation. Are you going to address that or you just going to ignore them? -Alexander
Re: I have a plan.. I really DO
On Friday, 6 July 2018 at 17:58:46 UTC, bachmeier wrote:
On Friday, 6 July 2018 at 15:53:56 UTC, Ecstatic Coder wrote:
With D, ANY forgotten allocation during the game loop (and I
really mean even JUST ONE hidden allocation somewhere in the
whole game or engine), may cause the game to regularly freeze
at the wrong time, because of an unwanted GC. Hence the phobia.
This program
import std.conv, std.stdio;
@nogc void main() {
int point_count = 3;
string score = point_count.to!string() ~ " POINTS";
writeln(score);
}
provides this compiler output
nogc.d(5): Error: @nogc function 'D main' cannot call non-@nogc
function 'std.conv.to!string.to!int.to'
nogc.d(5): Error: cannot use operator ~ in @nogc function 'D
main'
nogc.d(6): Error: @nogc function 'D main' cannot call non-@nogc
function 'std.stdio.writeln!string.writeln'
Are you saying there are bugs in the @nogc implementation?
Otherwise I don't see how you will end up with a forgotten
allocation.
I agree.
But that feature is not something present in all the garbage
collected language.
The problem with my "naive" text score code is that you can trust
the C++ version to deallocate the destroyed string buffers "on
the fly".
Because in C++, smart pointers and collections will make sure to
free unused memory block as soon as they need to, and no later.
For the garbage collected language version, it's up to the
garbage collector to decide when and how this memory will be
claimed. So sometimes this may happen at the wrong time too...
So I'm not saying that D can't work with the GC disabled, etc.
I'm saying that you will find it hard to convince many C++ game
developers that they can make a few allocations within a game
loop in a garbage collected language like Java, C#, etc, and not
have to worry about that.
And by saying, "just disable the garbage collector", you are
convincing them still more of that, instead of the contrary.
Re: I have a plan.. I really DO
On Friday, 6 July 2018 at 17:43:29 UTC, JN wrote: On Friday, 6 July 2018 at 17:26:26 UTC, wjoe wrote: On Friday, 6 July 2018 at 15:53:56 UTC, Ecstatic Coder wrote: With D, ANY forgotten allocation during the game loop (and I really mean even JUST ONE hidden allocation somewhere in the whole game or engine), may cause the game to regularly freeze at the wrong time, because of an unwanted GC. Hence the phobia. You make it sound like a C++ game codes, debugs, profiles and optimizes itself. And like there are no gotchas with C++. Anyway, I know I'm on a D forum here, so "those who don't want to understand won't, and those who want will", to paraphrase a former poster here. Well, it appears that you don't. And since you point out the D forum folks, I know game developers are a very special lot, too, with ther mantra like repetition of GC is the devil, acting like it's 1985 and the need to count clock cycles and top-of-the-food-chain I-never-make-mistakes arrogance like nobody else knows how to write fast code, yet most games of those clever guys are bug ridden pieces of poor quality even years after release, including top AAA titles *cough* TES. Despite - or more likely because - being made in C++. Maybe performance aware game developers would do well to also adopt the idea of code quality and D offers a lot in that regard. Plus C++ish performance on top of that. Yeah. There are plenty of games done in GC languages. C++ folks want to use C++. The ones that wanted to switched, switched already. Even if nogc gets more mature, they will find another excuse. Probably something like "yeah but now I don't know which parts of the language and library I can use and it's awkward to put nogc everywhere". I do some free time game development work in various languages, even GC ones and the existence of GC was never a big issue for me. Sure, I am not a super mighty C++ programmer, so I don't know much, but for me it's more important as a gamedev to have features such as operator overloading, value types/be able to cast Vector3f[] to float[] without copying (something C/C++/D can do, for example Java can't do, C# can partially do that with LayoutKind.Sequential), accessibility of C bindings for popular libraries like SDL, SFML, ODE. nogc, betterC, interfacing to C++, at most they get a "hmm, that's interesting", but I haven't really seen them bring people to D. And I'll take a fun and convenient language over performant one any day. As I said, I wanted to explain the roots of the GC phobia for some C++ developers. If you don't agree when I said that one allocation during a C++ game loop is no problem, which one allocation during a GC language game loop MAY eventually become a problem, that's fine by me. But as many people here told me to "disable the GC" to completely avoid this potential risk of game freeze, I guess that all those D experts are also wrong in giving me this advice.
Re: I have a plan.. I really DO
On Wednesday, 4 July 2018 at 20:17:59 UTC, Maksim Fomin wrote: I am from area of economic, financial and scientific calculations used in decision making. So am I. It is hard for me to provide arguments for using D (meaning from professional area view) because c++ can be used for performance and D is poor in statistical libraries. Because it is applied area nobody cares whether exceptions have root class or whether virtual is default. What statistical libraries do you need? I can embed an R interpreter inside a D program, so D provides all R functionality. Furthermore, any compiled code for which there is an R interface also has a D interface. There are various C libraries that are easy enough to call from D. At least for the things I do, I have not run into any constraints librarywise, though sometimes I have to do a little work to call into existing libraries.
Re: I have a plan.. I really DO
On Friday, 6 July 2018 at 15:53:56 UTC, Ecstatic Coder wrote:
With D, ANY forgotten allocation during the game loop (and I
really mean even JUST ONE hidden allocation somewhere in the
whole game or engine), may cause the game to regularly freeze
at the wrong time, because of an unwanted GC. Hence the phobia.
This program
import std.conv, std.stdio;
@nogc void main() {
int point_count = 3;
string score = point_count.to!string() ~ " POINTS";
writeln(score);
}
provides this compiler output
nogc.d(5): Error: @nogc function 'D main' cannot call non-@nogc
function 'std.conv.to!string.to!int.to'
nogc.d(5): Error: cannot use operator ~ in @nogc function 'D main'
nogc.d(6): Error: @nogc function 'D main' cannot call non-@nogc
function 'std.stdio.writeln!string.writeln'
Are you saying there are bugs in the @nogc implementation?
Otherwise I don't see how you will end up with a forgotten
allocation.
Re: I have a plan.. I really DO
On Friday, 6 July 2018 at 17:22:15 UTC, 12345swordy wrote: On Friday, 6 July 2018 at 17:16:54 UTC, Ecstatic Coder wrote: Are you seriously going to ignore video games that are entirely implemented in GC focus language such as C#/java?! The GC is NOT AN ISSUE IF YOU KNOW WHAT YOU ARE DOING! -Alexander +1 You are start reminding me of another person who pull these type of stunts. Which is not a good thing btw, as that guy is a notorious troll. So if I agree with you, then I'm a troll ? While ANY C++ game can make ANY number of allocations/allocations inside a game loop and still run without a risking any freeze. You are doing something very wrong if you are doing this. -Alexander Just try it. Inside the game loop, add a for loop which evaluates the score text 100 times as explained above. Or even 1000 times. This means roughly 2000 allocations and 1999 deallocations. Your frame rate suffer will suffer from this, which is bad (and as such should absolutely avoided) but zero risk of garbage collection freeze. Then add ONE time the "naive" text score concatenation in the game loop of a garbage collected loop, and you expose yourself to a RISK of a garbage collection freeze. Just because of ONE string concatenation, executed only once per frame, which is something that could be tolerated in a C++ game.
Re: I have a plan.. I really DO
On Friday, 6 July 2018 at 17:26:26 UTC, wjoe wrote: On Friday, 6 July 2018 at 15:53:56 UTC, Ecstatic Coder wrote: With D, ANY forgotten allocation during the game loop (and I really mean even JUST ONE hidden allocation somewhere in the whole game or engine), may cause the game to regularly freeze at the wrong time, because of an unwanted GC. Hence the phobia. You make it sound like a C++ game codes, debugs, profiles and optimizes itself. And like there are no gotchas with C++. Anyway, I know I'm on a D forum here, so "those who don't want to understand won't, and those who want will", to paraphrase a former poster here. Well, it appears that you don't. And since you point out the D forum folks, I know game developers are a very special lot, too, with ther mantra like repetition of GC is the devil, acting like it's 1985 and the need to count clock cycles and top-of-the-food-chain I-never-make-mistakes arrogance like nobody else knows how to write fast code, yet most games of those clever guys are bug ridden pieces of poor quality even years after release, including top AAA titles *cough* TES. Despite - or more likely because - being made in C++. Maybe performance aware game developers would do well to also adopt the idea of code quality and D offers a lot in that regard. Plus C++ish performance on top of that. Yeah. There are plenty of games done in GC languages. C++ folks want to use C++. The ones that wanted to switched, switched already. Even if nogc gets more mature, they will find another excuse. Probably something like "yeah but now I don't know which parts of the language and library I can use and it's awkward to put nogc everywhere". I do some free time game development work in various languages, even GC ones and the existence of GC was never a big issue for me. Sure, I am not a super mighty C++ programmer, so I don't know much, but for me it's more important as a gamedev to have features such as operator overloading, value types/be able to cast Vector3f[] to float[] without copying (something C/C++/D can do, for example Java can't do, C# can partially do that with LayoutKind.Sequential), accessibility of C bindings for popular libraries like SDL, SFML, ODE. nogc, betterC, interfacing to C++, at most they get a "hmm, that's interesting", but I haven't really seen them bring people to D. And I'll take a fun and convenient language over performant one any day.
Re: I have a plan.. I really DO
On Friday, 6 July 2018 at 17:26:26 UTC, wjoe wrote: And since you point out the D forum folks, I know game developers are a very special lot, too ... Edit: This should read: I know game developers who are a very special lot My point was to only refer to the people I know, not game developers in general.
Re: I have a plan.. I really DO
On Friday, 6 July 2018 at 15:53:56 UTC, Ecstatic Coder wrote: With D, ANY forgotten allocation during the game loop (and I really mean even JUST ONE hidden allocation somewhere in the whole game or engine), may cause the game to regularly freeze at the wrong time, because of an unwanted GC. Hence the phobia. You make it sound like a C++ game codes, debugs, profiles and optimizes itself. And like there are no gotchas with C++. Anyway, I know I'm on a D forum here, so "those who don't want to understand won't, and those who want will", to paraphrase a former poster here. Well, it appears that you don't. And since you point out the D forum folks, I know game developers are a very special lot, too, with ther mantra like repetition of GC is the devil, acting like it's 1985 and the need to count clock cycles and top-of-the-food-chain I-never-make-mistakes arrogance like nobody else knows how to write fast code, yet most games of those clever guys are bug ridden pieces of poor quality even years after release, including top AAA titles *cough* TES. Despite - or more likely because - being made in C++. Maybe performance aware game developers would do well to also adopt the idea of code quality and D offers a lot in that regard. Plus C++ish performance on top of that.
Re: I have a plan.. I really DO
On Fri, Jul 06, 2018 at 05:16:54PM +, Ecstatic Coder via
Digitalmars-d-announce wrote:
> > Are you seriously going to ignore video games that are entirely
> > implemented in GC focus language such as C#/java?! The GC is NOT AN
> > ISSUE IF YOU KNOW WHAT YOU ARE DOING!
> >
> > -Alexander
>
> +1
>
> Indeed ABSOLUTELY NO garbage collection will happen during the game
> loop is 100% of your GC-language code doesn't make any string
> concatenation, object allocation, etc.
[...]
import core.memory;
GC.disable();
string s;
foreach (i; 0 .. 1_000_000) {
s ~= "look ma! no GC collection happens!";
}
...
GC.collect(); // GC collection happens here
...
GC.enable();// go back to "default" GC behaviour
T
--
Three out of two people have difficulties with fractions. -- Dirk Eddelbuettel
Re: I have a plan.. I really DO
On Friday, 6 July 2018 at 17:16:54 UTC, Ecstatic Coder wrote: Are you seriously going to ignore video games that are entirely implemented in GC focus language such as C#/java?! The GC is NOT AN ISSUE IF YOU KNOW WHAT YOU ARE DOING! -Alexander +1 You are start reminding me of another person who pull these type of stunts. Which is not a good thing btw, as that guy is a notorious troll. While ANY C++ game can make ANY number of allocations/allocations inside a game loop and still run without a risking any freeze. You are doing something very wrong if you are doing this. -Alexander
Re: I have a plan.. I really DO
On Friday, 6 July 2018 at 17:04:37 UTC, Ecstatic Coder wrote: Also if your concatenate string in a loop in c# then you use the https://www.dotnetperls.com/string-join function as it simpler and faster. There is no reason why we can't have the function equivalent in D. -Alexander Yeah I know, this code was DELIBERATLY naive. That was the whole point of it. Misuse of tools is not an argument against the tools themselves. Blaming the GC for your "naive" code, is equivalent to a carpenter blaming his hammer for his error when the hammer is in fine shape. As I said before, the GC is not an issue if you know what you are doing. -Alexander
Re: I have a plan.. I really DO
Are you seriously going to ignore video games that are entirely implemented in GC focus language such as C#/java?! The GC is NOT AN ISSUE IF YOU KNOW WHAT YOU ARE DOING! -Alexander +1 Indeed ABSOLUTELY NO garbage collection will happen during the game loop is 100% of your GC-language code doesn't make any string concatenation, object allocation, etc. While ANY C++ game can make ANY number of allocations/allocations inside a game loop and still run without a risking any freeze. I will probably slower than it should, so you'd better don't make too much of them ;) But the game won't freeze. C++ is allocation/deallocation tolerant to a reasonable extent. GC language aren't. You eventually have to reach the ZERO allocation limit, or you expose yourself to unwanted game freezes.
Re: I have a plan.. I really DO
On Friday, 6 July 2018 at 17:00:49 UTC, Ecstatic Coder wrote: On Friday, 6 July 2018 at 16:48:17 UTC, 12345swordy wrote: On Friday, 6 July 2018 at 16:45:41 UTC, Ecstatic Coder wrote: On Friday, 6 July 2018 at 16:33:19 UTC, 12345swordy wrote: [...] LOL Unless you implement your game in managed-C++, I don't think there is much to worry about that though... Your comparison is logical fallacious to begin with. -Alex I was just trying to explain why C++ developers have GC phobia through a very simple example. Even the simplest string concatenation in any garbage collected language (like Java, etc) can be the cause of of serious game freeze, which most players (including me) won't tolerate for long. Even one tiny allocation which is hidden deep somewhere in an external library of some sort... But it was obviously pointless to try to explain it on this D forum. I understand it now. Are you seriously going to ignore video games that are entirely implemented in GC focus language such as C#/java?! The GC is NOT AN ISSUE IF YOU KNOW WHAT YOU ARE DOING! -Alexander
Re: I have a plan.. I really DO
On Friday, 6 July 2018 at 16:48:17 UTC, 12345swordy wrote: On Friday, 6 July 2018 at 16:45:41 UTC, Ecstatic Coder wrote: On Friday, 6 July 2018 at 16:33:19 UTC, 12345swordy wrote: On Friday, 6 July 2018 at 15:19:33 UTC, Ecstatic Coder wrote: For C++, the answer is : never. ...Yeah I had already figure out what your aiming at. For C++ the correct answer is "I do not know as I don't know how it is implemented". You act like there isn't any GC libraries for C++. -Alex LOL Unless you implement your game in managed-C++, I don't think there is much to worry about that though... Your comparison is logical fallacious to begin with. -Alex I was just trying to explain why C++ developers have GC phobia through a very simple example. Even the simplest string concatenation in any garbage collected language (like Java, etc) can be the cause of of serious game freeze, which most players (including me) won't tolerate for long. Even one tiny allocation which is hidden deep somewhere in an external library of some sort... But it was obviously pointless to try to explain it on this D forum. I understand it now.
Re: I have a plan.. I really DO
Also if your concatenate string in a loop in c# then you use the https://www.dotnetperls.com/string-join function as it simpler and faster. There is no reason why we can't have the function equivalent in D. -Alexander Yeah I know, this code was DELIBERATLY naive. That was the whole point of it.
Re: I have a plan.. I really DO
On Friday, 6 July 2018 at 15:30:22 UTC, Ecstatic Coder wrote: On Friday, 6 July 2018 at 15:07:41 UTC, wjoe wrote: [...] Actually, as I said, even today many game engines are still written in a C-inspired manner, i.e. C + classes, templates and polymorphism, mainly for performance reasons (cache friendly data oriented designs, etc). You can do that in D.
Re: I have a plan.. I really DO
On Friday, 6 July 2018 at 15:19:33 UTC, Ecstatic Coder wrote: On Friday, 6 July 2018 at 14:52:46 UTC, 12345swordy wrote: On Friday, 6 July 2018 at 14:11:05 UTC, Ecstatic Coder wrote: On Friday, 6 July 2018 at 13:50:37 UTC, 12345swordy wrote: [...] +1 Just one silly question. Can the following "naive" D code trigger a garbage collection stall ? score.Text = point_count.to!string() ~ " POINTS"; The correct answer is: I don't know, as I don't know what "point_count" is in the first place, as it never been defined. -Alex Actually you answer was right even if the point count was not stored as an integer ;) For C++, the answer is : never. Two small memory blocks will have to be allocated from the memory pool, which is not smart, obviously, but apart of that, nothing to worry about. Because there is no garbage collector in C++, memory has to be allocated and deallocated in a continuous manner... Also if your concatenate string in a loop in c# then you use the https://www.dotnetperls.com/string-join function as it simpler and faster. There is no reason why we can't have the function equivalent in D. -Alexander
Re: I have a plan.. I really DO
On Friday, 6 July 2018 at 16:10:04 UTC, Ecstatic Coder wrote: [...] With D, I CAN'T use the language and its standard library as usual, just because of the GC "phobia". Which would be the #1 problem for me, because "standard" D is perfect to me, as much as "standard" C++ is nice to me. That's my point. Uhm... have you actually *tried* to do this in D? I have a project where, for various reasons, I need to control exactly when the GC runs a collection cycle. The code is not @nogc; in fact there are array allocations and AA allocations all over the place. And it's idiomatic D code with heavy Phobos use. But all I need to do is: import core.memory; GC.disable(); ... // tons of code, including allocating code, Phobos calls, etc. if (okToCollect) GC.collect(); ... // more allocating code GC.enable(); No collection cycles will run in the code marked "...", because the GC has been disabled. That means you can happily allocate stuff away and there will NOT be any GC stop-the-world pauses. Of course, I don't want memory to leak away freely either, so at strategic points in the code, I call GC.collect() to clean up. IOW, I can predict, and *control*, when exactly I want to spend time to clean up my memory. Then when I'm in a less-critical part of the code, I just re-enable the GC and let it do its job. I know what you're going to say next. There are cases where this level of control is not fine enough. That's true, and that's where things like @nogc will help you. But the blanket statement that you "can't use the language and its standard library as usual" just because of GC-phobia is, at best, inaccurate.
Re: I have a plan.. I really DO
On Friday, 6 July 2018 at 16:45:41 UTC, Ecstatic Coder wrote: On Friday, 6 July 2018 at 16:33:19 UTC, 12345swordy wrote: On Friday, 6 July 2018 at 15:19:33 UTC, Ecstatic Coder wrote: For C++, the answer is : never. ...Yeah I had already figure out what your aiming at. For C++ the correct answer is "I do not know as I don't know how it is implemented". You act like there isn't any GC libraries for C++. -Alex LOL Unless you implement your game in managed-C++, I don't think there is much to worry about that though... Your comparison is logical fallacious to begin with. -Alex
Re: I have a plan.. I really DO
On Friday, 6 July 2018 at 16:33:19 UTC, 12345swordy wrote: On Friday, 6 July 2018 at 15:19:33 UTC, Ecstatic Coder wrote: For C++, the answer is : never. ...Yeah I had already figure out what your aiming at. For C++ the correct answer is "I do not know as I don't know how it is implemented". You act like there isn't any GC libraries for C++. -Alex LOL Unless you implement your game in managed-C++, I don't think there is much to worry about that though...
Re: I have a plan.. I really DO
But then of course, you need to avoid a lot of D niceties. Unfortunately, in my case this is the exact moment where D looses a LOT of its shininess compared to C++. The balance is no more that much in favor of D as it was before, because it's "standard" D code which is so much more convenient than C++ in many situations, especially when implementing file processing scripts. This is why I think that even C++ developers who use D as a file processing language (like me) will still stick to C++ for their game engine, even if they would probably be more than happy to be able to use *STANDARD* D code instead...
Re: I have a plan.. I really DO
On Friday, 6 July 2018 at 15:19:33 UTC, Ecstatic Coder wrote: For C++, the answer is : never. ...Yeah I had already figure out what your aiming at. For C++ the correct answer is "I do not know as I don't know how it is implemented". You act like there isn't any GC libraries for C++. -Alex
Re: I have a plan.. I really DO
On 7/6/18 11:53 AM, Ecstatic Coder wrote: Of course, the answer in C++ is that it won't compile, this is D code! ;) Seriously ? No, not seriously! I realized what you meant. I wrote : "And what about the same code in C++ ?" I thought people on this forum were smart enough to understand "the C++ port of this D code". It was a point that we are delving into the absurd, saying "it depends on what type point_value is". I'm sorry to have been wrong on this. Sorry I made it seem like I was serious, my humor can be very dry sometimes. Anyway, what nobody here *wants* to understand, is that such "NAIVE" C++ string code may not be performant, but in C++, even if you make allocations/deallocations during the game loop, this won't be good for the game performance, but that's all. This is the reason why most game people shy away from D code. Because the GC is so inherent in the language, it's difficult to prove that you can call any function without incurring a possible GC cycle. The two ways around this are to use @nogc, or to turn off the GC when you don't want it to run. The blog has a whole series on working with and without the GC in D. With D, ANY forgotten allocation during the game loop (and I really mean even JUST ONE hidden allocation somewhere in the whole game or engine), may cause the game to regularly freeze at the wrong time, because of an unwanted GC. Hence the phobia. This is why you use @nogc. You then can't forget such things. But then of course, you need to avoid a lot of D niceties. -Steve
Re: I have a plan.. I really DO
On Friday, 6 July 2018 at 14:14:27 UTC, rikki cattermole wrote: On 07/07/2018 2:11 AM, Ecstatic Coder wrote: On Friday, 6 July 2018 at 13:50:37 UTC, 12345swordy wrote: On Friday, 6 July 2018 at 13:15:43 UTC, Ecstatic Coder wrote: LOL Ok, if I'm wrong, then this means D is already a perfect replacement to C++, especially for game development. Just by curiosity, can you tell me how many successful commercial games based on a D game engine are released each year ? Or just this year maybe... No triple AAA engine is going to switch to D for the following reasons: 1.)Cost vs benefit from converting C++ to D. 2.)Gamers do not care how things are implemented, they want results. 3.)There are high abundance of c++ programmers for employees to hired. I can't say the same thing for D. 4.)GC phobia.(The notorious culprit) -Alex +1 Just one silly question. Can the following "naive" D code trigger a garbage collection stall ? score.Text = point_count.to!string() ~ " POINTS"; If the GC has been disabled (which any sane performance caring application should do) no. Yeah, I know, I'm not silly. I meant, "if you use standard D code in a game (i.e. with GC enabled), the game may stole, but if you use standard C++ code in a game, the game may be a bit less performant". In C++ you don't have to disable anything, and you can still use the standard C++ library to make your game if you want to. With D, I CAN'T use the language and its standard library as usual, just because of the GC "phobia". Which would be the #1 problem for me, because "standard" D is perfect to me, as much as "standard" C++ is nice to me. That's my point.
Re: I have a plan.. I really DO
On 07/07/2018 3:53 AM, Ecstatic Coder wrote: With D, ANY forgotten allocation during the game loop (and I really mean even JUST ONE hidden allocation somewhere in the whole game or engine), may cause the game to regularly freeze at the wrong time, because of an unwanted GC. Hence the phobia. Disable the GC, boom! Done. No risk at all.
Re: I have a plan.. I really DO
Of course, the answer in C++ is that it won't compile, this is D code! ;) Seriously ? I wrote : "And what about the same code in C++ ?" I thought people on this forum were smart enough to understand "the C++ port of this D code". I'm sorry to have been wrong on this. Anyway, what nobody here *wants* to understand, is that such "NAIVE" C++ string code may not be performant, but in C++, even if you make allocations/deallocations during the game loop, this won't be good for the game performance, but that's all. With D, ANY forgotten allocation during the game loop (and I really mean even JUST ONE hidden allocation somewhere in the whole game or engine), may cause the game to regularly freeze at the wrong time, because of an unwanted GC. Hence the phobia. Anyway, I know I'm on a D forum here, so "those who don't want to understand won't, and those who want will", to paraphrase a former poster here.
Re: I have a plan.. I really DO
On 7/6/18 11:19 AM, Ecstatic Coder wrote: On Friday, 6 July 2018 at 14:52:46 UTC, 12345swordy wrote: On Friday, 6 July 2018 at 14:11:05 UTC, Ecstatic Coder wrote: Just one silly question. Can the following "naive" D code trigger a garbage collection stall ? score.Text = point_count.to!string() ~ " POINTS"; The correct answer is: I don't know, as I don't know what "point_count" is in the first place, as it never been defined. Actually you answer was right even if the point count was not stored as an integer ;) The real answer is what rikki says. Note that what point_count is is irrelevant, the concatenation operator is going to trigger a GC allocation. We could go further and say "Well, you haven't defined `to` or `string`" and then we can say we have no idea what this means at all! For C++, the answer is : never. Of course, the answer in C++ is that it won't compile, this is D code! ;) And yes, you can have @nogc code in D, and it's less pleasant than normal D code, but still WAY more pleasant that most C++ code. So will people put up with this who want to just write games? Given the current state of the landscape, probably not. At some point, someone is going to make a fantastic game engine in D, and then we will have a ballgame. Maybe it happens after D gets better support for reference counting, maybe before. Nothing inherent in D makes it impossible or unlikely. But people aren't going to switch "just because", there needs to be a compelling reason that causes someone to champion it. -Steve
Re: I have a plan.. I really DO
On Friday, 6 July 2018 at 15:07:41 UTC, wjoe wrote: On Friday, 6 July 2018 at 13:15:43 UTC, Ecstatic Coder wrote: Just by curiosity, can you tell me how many successful commercial games based on a D game engine are released each year ? Just out of curiosity, how many games have been released based on a C++ game engine in 1998 ? The original Unreal engine was almost completely written in asm, back in the late 90ies. The first C++ game engine I found was the Object Oriented Graphical Redering Engine, started some time around 2001. Carmack resisted C++ for a longer time and I believe I read something about the engine was ported to C++ when they developed Id Tech 4 around 2004. Actually, as I said, even today many game engines are still written in a C-inspired manner, i.e. C + classes, templates and polymorphism, mainly for performance reasons (cache friendly data oriented designs, etc).
Re: I have a plan.. I really DO
On Friday, 6 July 2018 at 14:52:46 UTC, 12345swordy wrote: On Friday, 6 July 2018 at 14:11:05 UTC, Ecstatic Coder wrote: On Friday, 6 July 2018 at 13:50:37 UTC, 12345swordy wrote: On Friday, 6 July 2018 at 13:15:43 UTC, Ecstatic Coder wrote: [...] No triple AAA engine is going to switch to D for the following reasons: 1.)Cost vs benefit from converting C++ to D. 2.)Gamers do not care how things are implemented, they want results. 3.)There are high abundance of c++ programmers for employees to hired. I can't say the same thing for D. 4.)GC phobia.(The notorious culprit) -Alex +1 Just one silly question. Can the following "naive" D code trigger a garbage collection stall ? score.Text = point_count.to!string() ~ " POINTS"; The correct answer is: I don't know, as I don't know what "point_count" is in the first place, as it never been defined. -Alex Actually you answer was right even if the point count was not stored as an integer ;) For C++, the answer is : never. Two small memory blocks will have to be allocated from the memory pool, which is not smart, obviously, but apart of that, nothing to worry about. Because there is no garbage collector in C++, memory has to be allocated and deallocated in a continuous manner...
Re: I have a plan.. I really DO
On Friday, 6 July 2018 at 13:15:43 UTC, Ecstatic Coder wrote: Just by curiosity, can you tell me how many successful commercial games based on a D game engine are released each year ? Just out of curiosity, how many games have been released based on a C++ game engine in 1998 ? The original Unreal engine was almost completely written in asm, back in the late 90ies. The first C++ game engine I found was the Object Oriented Graphical Redering Engine, started some time around 2001. Carmack resisted C++ for a longer time and I believe I read something about the engine was ported to C++ when they developed Id Tech 4 around 2004.
Re: I have a plan.. I really DO
On Friday, 6 July 2018 at 14:11:05 UTC, Ecstatic Coder wrote: On Friday, 6 July 2018 at 13:50:37 UTC, 12345swordy wrote: On Friday, 6 July 2018 at 13:15:43 UTC, Ecstatic Coder wrote: [...] No triple AAA engine is going to switch to D for the following reasons: 1.)Cost vs benefit from converting C++ to D. 2.)Gamers do not care how things are implemented, they want results. 3.)There are high abundance of c++ programmers for employees to hired. I can't say the same thing for D. 4.)GC phobia.(The notorious culprit) -Alex +1 Just one silly question. Can the following "naive" D code trigger a garbage collection stall ? score.Text = point_count.to!string() ~ " POINTS"; The correct answer is: I don't know, as I don't know what "point_count" is in the first place, as it never been defined. -Alex
Re: I have a plan.. I really DO
On Friday, 6 July 2018 at 13:50:37 UTC, 12345swordy wrote: On Friday, 6 July 2018 at 13:15:43 UTC, Ecstatic Coder wrote: LOL Ok, if I'm wrong, then this means D is already a perfect replacement to C++, especially for game development. Just by curiosity, can you tell me how many successful commercial games based on a D game engine are released each year ? Or just this year maybe... No triple AAA engine is going to switch to D for the following reasons: 1.)Cost vs benefit from converting C++ to D. 2.)Gamers do not care how things are implemented, they want results. 3.)There are high abundance of c++ programmers for employees to hired. I can't say the same thing for D. 4.)GC phobia.(The notorious culprit) -Alex +1 Just one silly question. Can the following "naive" D code trigger a garbage collection stall ? score.Text = point_count.to!string() ~ " POINTS"; And what about the same code in C++ ? Now guess why there is such a "phobia"...
Re: I have a plan.. I really DO
On 07/07/2018 2:11 AM, Ecstatic Coder wrote: On Friday, 6 July 2018 at 13:50:37 UTC, 12345swordy wrote: On Friday, 6 July 2018 at 13:15:43 UTC, Ecstatic Coder wrote: LOL Ok, if I'm wrong, then this means D is already a perfect replacement to C++, especially for game development. Just by curiosity, can you tell me how many successful commercial games based on a D game engine are released each year ? Or just this year maybe... No triple AAA engine is going to switch to D for the following reasons: 1.)Cost vs benefit from converting C++ to D. 2.)Gamers do not care how things are implemented, they want results. 3.)There are high abundance of c++ programmers for employees to hired. I can't say the same thing for D. 4.)GC phobia.(The notorious culprit) -Alex +1 Just one silly question. Can the following "naive" D code trigger a garbage collection stall ? score.Text = point_count.to!string() ~ " POINTS"; If the GC has been disabled (which any sane performance caring application should do) no.
Re: I have a plan.. I really DO
On Friday, 6 July 2018 at 13:15:43 UTC, Ecstatic Coder wrote: LOL Ok, if I'm wrong, then this means D is already a perfect replacement to C++, especially for game development. Just by curiosity, can you tell me how many successful commercial games based on a D game engine are released each year ? Or just this year maybe... No triple AAA engine is going to switch to D for the following reasons: 1.)Cost vs benefit from converting C++ to D. 2.)Gamers do not care how things are implemented, they want results. 3.)There are high abundance of c++ programmers for employees to hired. I can't say the same thing for D. 4.)GC phobia.(The notorious culprit) -Alex
Re: I have a plan.. I really DO
LOL Ok, if I'm wrong, then this means D is already a perfect replacement to C++, especially for game development. Just by curiosity, can you tell me how many successful commercial games based on a D game engine are released each year ? Or just this year maybe...
Re: I have a plan.. I really DO
On Wednesday, 4 July 2018 at 19:29:55 UTC, Ecstatic Coder wrote: On Wednesday, 4 July 2018 at 18:05:15 UTC, wjoe wrote: On Wednesday, 4 July 2018 at 08:50:57 UTC, Ecstatic Coder wrote: But indeed, being able use D in a GC-free environment (like C++ and Rust do) would be something many people may NEED, for instance to be able to EASILY use D for soft-realtime applications like games. This has to be the no. 1 excuse. Games have been made with GC'd languages, 3D games, even. And successfully, too. Minecraft, a very successful one, comes to mind, which is or at least was made in Java. Plenty of games are made in C#, too. +1 Slow code is slow and allocating memory in a tight loop is a huge performance killer - regardless of language. +1 Nothing forces anyone to use the GC, memory can be managed manually via malloc/free and you get to do it with scope statements/nested functions which makes it nicer than in C. You could also implement shared/weak ptr stuff in D - warts and all. That's what Timur said. If you need a GC free standard library, I believe there is an ongoing effort -or several- at code.dlang.org and probably other places. You said do this and that, GC, etc. to motivate C++ folks to come to D. I say it's an excuse not to use D and no matter the effort of advertising, a GC free phobos, etc. on part of the D-Lang Foundation and contributors would make these folks switch. They would simply find a different excuse. You say that garbage collection is not a real problem for game development. Maybe, but that's not my experience. For instance, have you read Unity's own official recommandations on how to overcome this problem ? And obviously, Tibur, a highly skilled D game engine developer, is not a big fan of D's non incremental garbage collector, from the number of @nogc he has put in his Dlib container code. He has written no-GC libs for sure but he said in a blog post about his projects that he has no problem with GC. As long as you do not use it in critical areas. Modern D is a very attractive choice as a language for game development. Even the garbage collector is not a problem, because you can use object pools, custom allocators, or simply malloc and free. The key point is to know when the GC is invoked and try to avoid those cases in performance critical code. Personally, I prefer using malloc so that I can free the memory when I want, since delete has been deprecated and destroy just releases all the references to an object instance without actually deleting it. Using manual memory management imposes some restrictions on the code–for example, you can’t use closures or D’s built-in containers–but that, again, is not a big problem. A large effort is currently underway to lessen GC usage in dlib, so that you can use it to write fully unmanaged applications with ease. It has GC-free containers, file I/O streams, image decoders, and so on. https://dlang.org/blog/2016/09/16/project-highlight-timur-gafarov/ Remember he's into real-time stuff. As an indie game developer with a strong bias toward graphics engines and rendering tech, I always try to keep track of modern compiled languages effective enough for writing real-time stuff. The most obvious choice in this field is C++, and I actually used it for several years until I found D in 2010. I immediately fell in love with the language’s clean, beautiful syntax, its powerful template system, the numerous built-in features absent in C++, and the rich and easy to use standard library. Maybe you disagree with us because you are a professional game developer who has already released a successful commercial game in D without caring for the garbage collection. If it's the case, then nice, I'd be happy to have it wrong on this :) Read the blog post, you're wrong. Of course it's perfectly your right to develop your games without caring for all these performance "details". But other people do. GC in not a performance bottle neck if you truly know what you're doing. So, as I said, those who use C++ or Rust because D's GC is a problem for them, won't probably use D in its current state. If D had X people. Not customers.
Re: I have a plan.. I really DO
On Wednesday, 4 July 2018 at 19:29:55 UTC, Ecstatic Coder wrote: First, to be clear, I mainly use D as a scripting language for file processing, and for this use case, having a GC is a blessing. This is a non issue and a GC doesn't matter at all in this case. You could allocate all you wanted and never free and as long as there's enough memory to finish the script you couldn't tell the difference. Once a script or program is done the OS reclaims all memory. But memory leaks in software, running in some kind of main loop, become real performance bottlenecks eventually and a time sink to debug. You say that garbage collection is not a real problem for game development. No, what I'm saying is that I've hadn't had any issues with the GC so far and that I don't expect any. I'm also saying that I keep hearing this argument against using D but it was never backed up by anthing substantial so it sounds like an excuse by folks who never really considered D in the first place. Like, what does it matter if a collection cycle is triggered during a loading screen ? Performance aware C++ folks do have to do resource management at some point, too, and that's not free either and is usually done while the loading screen is displayed. For instance, have you read Unity's own official recommandations on how to overcome this problem ? No, I haven't. It probably boils down to pre-allocation, object pools, reusing objects, don't allocate in a loop, caching data, be mindful of what you do and when and how, etc, etc. Which would be good advice for game development in general and I'd do exactly that in C/C++, or any non-GC'd language, too. And about developing video games in C++, actually most studios use orthodox C++. This means no exceptions, no RTTI, few virtual methods, fast lightweight smart pointers and collections, etc. They could get that with -betterC which also does not use a GC. And about the scripting language, it's not my fault if some game engine developers don't care for the performance or GC issues when adding a scripting language to their game engine. Never said it was your fault, just pointed out the fact that it's a very common occurance. So, as I said, those who use C++ or Rust because D's GC is a problem for them, won't probably use D in its current state. Or any other language tagged GC for that matter, except maybe LUA. Nobody and nothing forces anyone to use the GC or features which use it. Just go ahead and manage your memory manually. They will not be using features like dynamic arrays, the standard library, and such but that's not a loss since they'd roll their own, more performant implementations, anyways. But I'm convinced that they wouldn't consider D - even if there was a GC-free Phobos. They would find the next excuse. Those who are willing find solutions, those who are not find excuses.
Re: I have a plan.. I really DO
On Friday, 29 June 2018 at 07:03:52 UTC, Dmitry Olshansky wrote: I never ever (I think) did something provocative, something to finally see: ... My 5 cents inspired by experimenting with D some years ago. 1. Programming became niche oriented and quite diverse. Writing new language requires significant manpower. 2. D manpower is not sufficient for finishing language in low level niche. AFAIK Walter estimated manpower around 2013 to be equivalent of bus factor of 10. This is not enough to deliver stable language, it will always be "tasted as raw" comparing with c++. 3. D strategic mistake is ad-hoc design. Some features are added or extended and because of complexity result in corner cases (this is exacerbated because sometimes backward compatibility is preserved and sometimes not). Fixing corner cases sometimes produces more questions. As a result language has some mess which is unlikely to be fixed coherently (c++ is at least a documented mess). 4a. Limited developers' efforts are consumed by fixes and internal code optimization rather than important issues. 4b. Dips (related to language design) mostly fail because proposal authors do not write code and developers are busy. 5. My view of D future. Walter and developers will continue to improve and develop D but at low pace. Low-level niche will be dominated by c++ as a common denominator. D and some alternative languages would compete for different parts of this niche. In long-term low-level niche will be broken into smaller niches with languages specializing in them. Being "just low level" would be wrong as "just language". This would raise questions what D goal is. I am from area of economic, financial and scientific calculations used in decision making. It is dominated by python, c++ and statistical software. In most cases it does not require absolute speed (except financial markets rt trading, big data processing or some hard mathematical problems which are relevant for researchers in top institutions with supercomputers). It is hard for me to provide arguments for using D (meaning from professional area view) because c++ can be used for performance and D is poor in statistical libraries. Because it is applied area nobody cares whether exceptions have root class or whether virtual is default.
Re: I have a plan.. I really DO
On Wednesday, 4 July 2018 at 19:49:00 UTC, Ecstatic Coder wrote: For instance, to be a perfect C++ alternative, D would probably need to be 100% : 1. usable (strings, slices, etc) without GC 2. interoperable with any existing C++ library For for game development : 3. compilable on all game development platforms (Win/Mac/Linux/Android/iOS/Switch/PS4/etc) I don't know if this can be achieved, or if this is really worth the effort. I think it isn't. Language is only a small part of the equation nowadays. The ecosystem is more important. If you made strings, slices etc. usable without GC, you'd probably make it incompatible with 90% of the existing code. The ecosystem would be split into "no GC" and "GC" libraries. And then you'd have the "C++ folks" complaining about how it's hard to tell what is supported, what isn't. If you aren't decisive, you open yourself to others doubting you. Look at C#, Java, Javascript. They have GC, do people complain about it? For the most part no, they just learned to deal with it and other language features make it worth it for them. These languages don't really consider adding advanced manual memory management options to lure in "C++ folks". Neither Unity is rewriting their engine in Rust as of this moment.
Re: I have a plan.. I really DO
Exactly. As Walter has said before, (and I paraphrase,) it's far more profitable to cater to *existing* customers who are already using your product, to make their experience better, than to bend over backwards to satisfy the critical crowd who points at issue X and claim that they would not use D because of X. But X is not the *real* reason they don't want to use D; it's just an excuse. Once you solve problem X, they will find issue Y and say *that* is the reason they're still not using D. And if you solve Y, they will find issue Z. It never ends, and you're wasting your efforts on non-customers who will *never* become customers. Why bother? Far better to improve things for existing customers (who may then get you new customers by word-of-mouth of their success stories -- *eager* new customers who aren't just looking for the next excuse not to use D). +1 For instance, to be a perfect C++ alternative, D would probably need to be 100% : 1. usable (strings, slices, etc) without GC 2. interoperable with any existing C++ library For for game development : 3. compilable on all game development platforms (Win/Mac/Linux/Android/iOS/Switch/PS4/etc) I don't know if this can be achieved, or if this is really worth the effort.
Re: I have a plan.. I really DO
On Wednesday, 4 July 2018 at 18:05:15 UTC, wjoe wrote: On Wednesday, 4 July 2018 at 08:50:57 UTC, Ecstatic Coder wrote: But indeed, being able use D in a GC-free environment (like C++ and Rust do) would be something many people may NEED, for instance to be able to EASILY use D for soft-realtime applications like games. This has to be the no. 1 excuse. Why is C++ the language of choice currently? My bet is productivity and economic concerns. Amongst other things the productivity gain from resource management via constructor and destructor. Which solves like 75% of the headaches of manual resource management and goto nightmares. Back in the day when C was used to make games, the excuse not to use C++ was vtable, exception and RTTI overhead. Now it's called the bare metal best performance language which everything and their grandma is measured against. This C++ overhead didn't make C any slower or C++ any faster than C but it made C++ superior in productivity. This was around 2002/03, and C++, at the time, some 23+ years old. Games have been made with GC'd languages, 3D games, even. And successfully, too. Minecraft, a very successful one, comes to mind, which is or at least was made in Java. Plenty of games are made in C#, too. My bet, again, would be productivity and economic concerns. The countless hours wasted on debugging memory leaks and cyclic dependencies are better spent making the actual game/software. And smart pointers introduce overhead of their own which makes them inferior to C's bare metal raw pointer performance - or GC'd pointers for that matter. The culprit being the collection cycle. The best thing about this whole argument, however, is the claim for GC no can do and with the next breath they pull LUA into their games. A scripting language that brings a VM, GC and extraordinarily inflated loading times when the scripts are compiled to byte code at the end user's PC which make C64 loading times shine. The reasoning probably being productivity again and C++'s lunch break compile times. Using the D compiler as a library, instead of LUA, D code could be used for 'scripting', as well, and compiled to native machine code. In a snap. I have no metrics between any AAA game engine and their port to D but I do know that I wrote a sound/music player library in Java, which folks like you claim impossible because GC, never bothered with GC and had no performance issues whatsoever - and I don't expect any porting it to D. And there is EASTL. A STL made by Electronic Arts. Because the standard implementation shipped with the compiler is too slow ? Even though written by C++ wizards ? Slow code is slow and allocating memory in a tight loop is a huge performance killer - regardless of language. Also, why do you feel like a GC is inacceptable for games but doesn't matter for your file handling program? Handling dozens, maybe thousands, of files sounds like an awful lot of memory management involved and whether a e.g. grep takes 15 seconds to do it's job or under 1 matters not? Nothing forces anyone to use the GC, memory can be managed manually via malloc/free and you get to do it with scope statements/nested functions which makes it nicer than in C. You could also implement shared/weak ptr stuff in D - warts and all. If you need a GC free standard library, I believe there is an ongoing effort -or several- at code.dlang.org and probably other places. You said do this and that, GC, etc. to motivate C++ folks to come to D. I say it's an excuse not to use D and no matter the effort of advertising, a GC free phobos, etc. on part of the D-Lang Foundation and contributors would make these folks switch. They would simply find a different excuse. And where's the usefulness of toy examples like 2 line web servers which essentially do nothing? And how is that helping with getting attention from the game devs ? Putting on the front page a 12 line maze game which can be imported from the standard library? Not using the GC? First, to be clear, I mainly use D as a scripting language for file processing, and for this use case, having a GC is a blessing. You say that garbage collection is not a real problem for game development. Maybe, but that's not my experience. For instance, have you read Unity's own official recommandations on how to overcome this problem ? And obviously, Tibur, a highly skilled D game engine developer, is not a big fan of D's non incremental garbage collector, from the number of @nogc he has put in his Dlib container code. Maybe you disagree with us because you are a professional game developer who has already released a successful commercial game in D without caring for the garbage collection. If it's the case, then nice, I'd be happy to have it wrong on this :) And about developing video games in C++, actually most studios use orthodox C++. This means no exceptions, no RTTI, few virtual
Re: I have a plan.. I really DO
On Wed, Jul 04, 2018 at 06:05:15PM +, wjoe via Digitalmars-d-announce wrote: > On Wednesday, 4 July 2018 at 08:50:57 UTC, Ecstatic Coder wrote: > > But indeed, being able use D in a GC-free environment (like C++ and > > Rust do) would be something many people may NEED, for instance to be > > able to EASILY use D for soft-realtime applications like games. > > This has to be the no. 1 excuse. +1. It's typical GC-phobia that is mostly subjective and only tenously backed by real evidence. [...] > The best thing about this whole argument, however, is the claim for GC > no can do and with the next breath they pull LUA into their games. A > scripting language that brings a VM, GC and extraordinarily inflated > loading times when the scripts are compiled to byte code at the end > user's PC which make C64 loading times shine. Spot on! [...] > You said do this and that, GC, etc. to motivate C++ folks to come to > D. I say it's an excuse not to use D and no matter the effort of > advertising, a GC free phobos, etc. on part of the D-Lang Foundation > and contributors would make these folks switch. They would simply find > a different excuse. [...] Exactly. As Walter has said before, (and I paraphrase,) it's far more profitable to cater to *existing* customers who are already using your product, to make their experience better, than to bend over backwards to satisfy the critical crowd who points at issue X and claim that they would not use D because of X. But X is not the *real* reason they don't want to use D; it's just an excuse. Once you solve problem X, they will find issue Y and say *that* is the reason they're still not using D. And if you solve Y, they will find issue Z. It never ends, and you're wasting your efforts on non-customers who will *never* become customers. Why bother? Far better to improve things for existing customers (who may then get you new customers by word-of-mouth of their success stories -- *eager* new customers who aren't just looking for the next excuse not to use D). T -- They pretend to pay us, and we pretend to work. -- Russian saying
Re: I have a plan.. I really DO
On Wednesday, 4 July 2018 at 08:50:57 UTC, Ecstatic Coder wrote: But indeed, being able use D in a GC-free environment (like C++ and Rust do) would be something many people may NEED, for instance to be able to EASILY use D for soft-realtime applications like games. This has to be the no. 1 excuse. Why is C++ the language of choice currently? My bet is productivity and economic concerns. Amongst other things the productivity gain from resource management via constructor and destructor. Which solves like 75% of the headaches of manual resource management and goto nightmares. Back in the day when C was used to make games, the excuse not to use C++ was vtable, exception and RTTI overhead. Now it's called the bare metal best performance language which everything and their grandma is measured against. This C++ overhead didn't make C any slower or C++ any faster than C but it made C++ superior in productivity. This was around 2002/03, and C++, at the time, some 23+ years old. Games have been made with GC'd languages, 3D games, even. And successfully, too. Minecraft, a very successful one, comes to mind, which is or at least was made in Java. Plenty of games are made in C#, too. My bet, again, would be productivity and economic concerns. The countless hours wasted on debugging memory leaks and cyclic dependencies are better spent making the actual game/software. And smart pointers introduce overhead of their own which makes them inferior to C's bare metal raw pointer performance - or GC'd pointers for that matter. The culprit being the collection cycle. The best thing about this whole argument, however, is the claim for GC no can do and with the next breath they pull LUA into their games. A scripting language that brings a VM, GC and extraordinarily inflated loading times when the scripts are compiled to byte code at the end user's PC which make C64 loading times shine. The reasoning probably being productivity again and C++'s lunch break compile times. Using the D compiler as a library, instead of LUA, D code could be used for 'scripting', as well, and compiled to native machine code. In a snap. I have no metrics between any AAA game engine and their port to D but I do know that I wrote a sound/music player library in Java, which folks like you claim impossible because GC, never bothered with GC and had no performance issues whatsoever - and I don't expect any porting it to D. And there is EASTL. A STL made by Electronic Arts. Because the standard implementation shipped with the compiler is too slow ? Even though written by C++ wizards ? Slow code is slow and allocating memory in a tight loop is a huge performance killer - regardless of language. Also, why do you feel like a GC is inacceptable for games but doesn't matter for your file handling program? Handling dozens, maybe thousands, of files sounds like an awful lot of memory management involved and whether a e.g. grep takes 15 seconds to do it's job or under 1 matters not? Nothing forces anyone to use the GC, memory can be managed manually via malloc/free and you get to do it with scope statements/nested functions which makes it nicer than in C. You could also implement shared/weak ptr stuff in D - warts and all. If you need a GC free standard library, I believe there is an ongoing effort -or several- at code.dlang.org and probably other places. You said do this and that, GC, etc. to motivate C++ folks to come to D. I say it's an excuse not to use D and no matter the effort of advertising, a GC free phobos, etc. on part of the D-Lang Foundation and contributors would make these folks switch. They would simply find a different excuse. And where's the usefulness of toy examples like 2 line web servers which essentially do nothing? And how is that helping with getting attention from the game devs ? Putting on the front page a 12 line maze game which can be imported from the standard library? Not using the GC?
Re: I have a plan.. I really DO
Throw everything we can this dude's way so we can make D the most powerful we can We need pattern matching, we need typeclasses, we need HKT's, we need linear types, we need @nogc Phobos, we need concurrency so fearless I can change any variable and not give two shits Personally I don't really NEED pattern matching, typeclasses, etc That would be nice, but personally that wouldn't prevent me from getting the job done. But indeed, being able use D in a GC-free environment (like C++ and Rust do) would be something many people may NEED, for instance to be able to EASILY use D for soft-realtime applications like games. So being able to add a "-nogc" flag to the DMD compiler and use a minimal Phobos-like library (strings, arrays, lists, maps and other collections, file system functions, etc) which use EXCLUSIVELY reference counted memory block accessed through strong/weak references and pointers (T@, T&, T*) would be nice. Not an implementation like the one in the standard library of C++, which is maybe safe but not especially efficient or user friendly, but preferably something closer to this : https://github.com/senselogic/BASE/tree/master/CODE/COUNTED And being able to DIRECTLY use D with REAL Go-like ease of use and performance (http components, fibers and channels using both concurrency and parallelism) to implement web frameworks and online services is also something many people may NEED.
Re: I have a plan.. I really DO
On Friday, 29 June 2018 at 07:03:52 UTC, Dmitry Olshansky wrote: I never ever (I think) did something provocative, something to finally see: - who in the community WANTS D language to succeed? - who are just these funny “people” let’s call th this, that are I don’t know “just hang around” Because shame is a weapon much like fear (of death esp), pride can be used as weapon but ehm better shame the bastard... And so on. So - until we all understand that these donations are not because we are begging fir money. I will send ~ 10$ each day _specifically_ to see who WANTS D TO SUCCED and WILL NOT BE SHAMED LIKE THAT FOR ONCE! It is because it’s (soon) your last chance to invest into the Future. P.S. I mean what you think the future of native code is??? Rust? Crystal?? Nim??? Throw everything we can this dude's way so we can make D the most powerful we can We need pattern matching, we need typeclasses, we need HKT's, we need linear types, we need @nogc Phobos, we need concurrency so fearless I can change any variable and not give two shits
Re: I have a plan.. I really DO
On Tuesday, 3 July 2018 at 06:43:44 UTC, Ecstatic Coder wrote: D has a very diverse use case so the generalization is moot. For example I prefer having the gc manage memory for me...For most of the things I do with D...contrary to other opinions. +1 For most D use cases (including mine, which is file processing), D's GC is a blessing, and one of its main advantages over C++, IMHO. And if you want to use D for C++-like use cases where you don't want it, this generally leads to having to reinvent the wheel in order to avoid unwanted garbage collections. For instance : https://github.com/gecko0307/dlib/blob/master/dlib/container That's why I'm personally in favor of D supporting reference-counting based memory management directly in its syntax (T@, etc), and also providing the GC-free standard PS : BTW kudos to Timur Gafarov, it's a pity so many D developers prefer to start developing their own engines instead of helping Tibur finish Dagon to make it a production-ready game engine (adding terrain, UI, networking, etc). Very promising work IMHO ! https://dlang.org/blog/2016/09/16/project-highlight-timur-gafarov/ And having the language help him (native strong/weak references) would be nice too :D I waa aware aware of dlib by I never knew about the impressive he had done with D, especially the game engine Dagon and physics engine dmech. Shows what D can do in a clean way. Beyond that, he took time to write detailed tutorials for the game engine. Its definitely better for others to contribute instead of reinventing the wheel. His work is really impressive. https://github.com/gecko0307/dagon/wiki/Tutorials
Re: I have a plan.. I really DO
On Sunday, 1 July 2018 at 12:43:53 UTC, Johannes Loher wrote:
Am 01.07.2018 um 14:12 schrieb Ecstatic Coder:
Add a 10-liner "Hello World" web server example on the main
page and that's it.
There already is one in the examples:
#!/usr/bin/env dub
/+ dub.sdl:
name "hello_vibed"
dependency "vibe-d" version="~>0.8.0"
+/
void main()
{
import vibe.d;
listenHTTP(":8080", (req, res) {
res.writeBody("Hello, World: " ~ req.path);
});
runApplication();
}
Its nice when it works.
First: its a hack as nobody will run any production code with the
shebang include like the example posted. And they will be forced
set up a dub package. This already confuses people as its two
standards. Shebang is nice and well if you have Unix experience
but not so much for Windows users who have no Posix experience.
Crystal or Go where your simply adding a import http and your can
keep working on that code.
Second: Its a hack and it fails easily. Maybe its dub or whatever
but i remember trying that example in the past several times and
had a lot of issues with failures using it. Using the proper dub
package actually worked better.
So this http example is not exactly prime. Add to this that
Vibe.d also keeps having issues with D releases. Where DMD breaks
something (regressions come to mind) and when Vibe.d ( and its
dependencies ) as a result also break.
I never found D + Vibe.D very reliable or stable. Your almost
forced to stick to a version of D and never reinstall your
system. Even setting up a home / work setup with some time
between can result in issues that eat away hours of your time.
It also does not help that Vibe.D has problems to reach higher
performance levels.
https://www.techempower.com/benchmarks/#section=test=7dc8ea3a-6db5-41b8-a4d3-c18cfe72182b=ph=fortune
Even in my own tests, D+Vibe always lags behind Crystal, Go and
other languages. That is just shucking resources out of the
window. Not what you expect for a language this old.
Re: I have a plan.. I really DO
On Tuesday, 3 July 2018 at 05:52:40 UTC, Ecstatic Coder wrote: I mean, you should offer a short panel of D enhancement projects, with their precise goal, minimum bugdet and investment time limit (for instance one year to reach the required budget), plus an ordered list of additional developments if the gathered money exceeds the initial budget. People can then invest in the project(s) that interest them the most. That's what we thought we were getting with Open Collective goals before we activated it. That was a bit disappointing. Anyway, the plan is to have something similar to what you describe. It won't be Kickstarter, though. Before activating yet another service, I want to look at ways to integrate what we already have. I'll have more news on this somewhere down the road.
Re: I have a plan.. I really DO
D has a very diverse use case so the generalization is moot. For example I prefer having the gc manage memory for me...For most of the things I do with D...contrary to other opinions. +1 For most D use cases (including mine, which is file processing), D's GC is a blessing, and one of its main advantages over C++, IMHO. And if you want to use D for C++-like use cases where you don't want it, this generally leads to having to reinvent the wheel in order to avoid unwanted garbage collections. For instance : https://github.com/gecko0307/dlib/blob/master/dlib/container That's why I'm personally in favor of D supporting reference-counting based memory management directly in its syntax (T@, etc), and also providing the GC-free standard components (strings, slices, maps, etc). PS : BTW kudos to Timur Gafarov, it's a pity so many D developers prefer to start developing their own engines instead of helping Tibur finish Dagon to make it a production-ready game engine (adding terrain, UI, networking, etc). Very promising work IMHO ! https://dlang.org/blog/2016/09/16/project-highlight-timur-gafarov/ And having the language help him (native strong/weak references) would be nice too :D
Re: I have a plan.. I really DO
Let me echo this: transparency has historically been a big problem for D. AFAIK, nobody in the broader community was ever told that the D foundation money would be used to fund a bunch of Romanian interns, it just happened. In the end, it appears to have worked out great, but why would anybody donate without being given transparency on where the money was going in the first place, when it could have ended badly? I understand Andrei had connections with that Romanian university, but some donor might have had connections with a Brazilian or Chinese university that might have worked out even better. We'll never explore such connections and alternatives without transparency. The current move to fund some IDE work with Opencollective is better in that regard, but with no concrete details on what it entails, not significantly better: https://forum.dlang.org/post/pxwxhhbuburvddnha...@forum.dlang.org Anyway, I don't use such IDEs, so not a reason for me to donate anyway. Honestly, Dmitry's posts starting this thread are incoherent, I'm not sure what he was trying to say. If he feels D users should be donating much more, he and others need to make clear how that money will be spent. +1 And maybe it would be a good idea to use a Kickstarter-like philosophy to fund D's development with more transparency. I mean, you should offer a short panel of D enhancement projects, with their precise goal, minimum bugdet and investment time limit (for instance one year to reach the required budget), plus an ordered list of additional developments if the gathered money exceeds the initial budget. People can then invest in the project(s) that interest them the most. If the minimum budget is not reached after the time limit, the investors can get their money back, or decide to invest it in another project which hasn't expired. As you guess, in my opinion, two possible fundable projects would be : 1. a project to add http-related components to D's standard library 2. a project to allow D to be REALLY usable without GC, i.e. add weak/strong reference to the language and provide a standard library which uses them
Re: I have a plan.. I really DO
On Monday, 2 July 2018 at 18:03:25 UTC, bachmeier wrote: On Saturday, 30 June 2018 at 03:02:15 UTC, Joakim wrote: The future of native code will be replacing scripting languages. D is really good at that task. This will never happen, doesn't matter how good D is at it, they will always be better because they sacrifice performance for ease of use. Generalization I think it depends on a couple of factors. First, some of us prefer static typing, but until a few years ago, the POS known as Java was the best available language with static typing. As languages like D build up libraries that make it easy to replace the functionality of scripting languages, many of us will move. Second, scripting languages lose their ease of use advantages quickly once performance becomes an issue. As data science and web services continue to grow at a fast pace, more programs are being written for which performance will eventually be an issue. JavaScript is the most popular and growing language on earth. AFAIK, nobody in the broader community was ever told that the D foundation money would be used to fund a bunch of Romanian interns, it just happened. My understanding is that a lot of that was funded by Andrei (but maybe I am wrong) so I have never had a problem with that decision. Where it does cause problems is that anyone else, myself included, may not be eager to donate for that reason because it's not what we feel is going to help with adoption of the language. As you mentioned, some work on IDEs is being funded, but even then it appears to be one IDE for Windows users. Windows? It's not an IDE. Its a text editor by Microsoft called Visual Studio Code and it's cross platform. The D extension is the most capable cross platform option. I use it on Linux an it works really well. I wouldn't hesitate to donate money just to see it gain further improvements. Its really awesome. When I see people complaining about lack of D support for code editors...I wonder if they make effort to assert their complaints. If course D cannot be supported on every ide/text editor. Popular ones are well supported. Visual Studio and Visual Studio Code being the best IMO. However, sublime, vim, and monodevelop have good support too. Maybe they should mention what they're not getting from supported IDEs/text editors. That's not relevant to anything I'm doing. It's better if I contribute by improving the ecosystem in a way that helps others doing the same things. D has a very diverse use case so the generalization is moot. For example I prefer having the gc manage memory for me...For most of the things I do with D...contrary to other opinions.
Re: I have a plan.. I really DO
On Saturday, 30 June 2018 at 03:02:15 UTC, Joakim wrote: The future of native code will be replacing scripting languages. D is really good at that task. This will never happen, doesn't matter how good D is at it, they will always be better because they sacrifice performance for ease of use. I think it depends on a couple of factors. First, some of us prefer static typing, but until a few years ago, the POS known as Java was the best available language with static typing. As languages like D build up libraries that make it easy to replace the functionality of scripting languages, many of us will move. Second, scripting languages lose their ease of use advantages quickly once performance becomes an issue. As data science and web services continue to grow at a fast pace, more programs are being written for which performance will eventually be an issue. AFAIK, nobody in the broader community was ever told that the D foundation money would be used to fund a bunch of Romanian interns, it just happened. My understanding is that a lot of that was funded by Andrei (but maybe I am wrong) so I have never had a problem with that decision. Where it does cause problems is that anyone else, myself included, may not be eager to donate for that reason because it's not what we feel is going to help with adoption of the language. As you mentioned, some work on IDEs is being funded, but even then it appears to be one IDE for Windows users. That's not relevant to anything I'm doing. It's better if I contribute by improving the ecosystem in a way that helps others doing the same things.
Re: I have a plan.. I really DO
On Monday, 2 July 2018 at 05:20:51 UTC, Joakim wrote:
On Sunday, 1 July 2018 at 15:40:20 UTC, Ecstatic Coder wrote:
On Sunday, 1 July 2018 at 14:01:11 UTC, Jonathan M Davis wrote:
On Sunday, July 01, 2018 13:37:32 Ecstatic Coder via
Digitalmars-d-announce wrote:
On Sunday, 1 July 2018 at 12:43:53 UTC, Johannes Loher wrote:
> Am 01.07.2018 um 14:12 schrieb Ecstatic Coder:
>> Add a 10-liner "Hello World" web server example on the
>> main page and that's it.
>
> There already is one in the examples:
>
> #!/usr/bin/env dub
> /+ dub.sdl:
> name "hello_vibed"
> dependency "vibe-d" version="~>0.8.0"
> +/
> void main()
> {
>
> import vibe.d;
> listenHTTP(":8080", (req, res) {
>
> res.writeBody("Hello, World: " ~ req.path);
>
> });
> runApplication();
>
> }
Yeah I know, guess who asked for it...
But the last step, which is including such functionality
into the standard library , will never happen, because
nobody here seems to see the point of doing this.
I guess those who made that for Go and Crystal probably did
it wrong.
What a mistake they did, and they don't even know they make
a mistake, silly them... ;)
What should and shouldn't go in the standard library for a
language is something that's up for a lot of debate and is
likely to often be a point of contention. There is no clear
right or wrong here. Languages that have had very sparse
standard libraries have done quite well, and languages that
have had kitchen sink libraries have done quite well. There
are pros and cons to both approaches.
- Jonathan M Davis
I agree.
But here I'm just talking of the "public image" of the
language.
Languages which integrates HTTP-related components in their
standard library, and advertize on that (like Crystal for
instance), obviously apply a different "marketing" strategy
than languages which have chosen not to do so.
That's all I say...
Two points:
- Andrei pushed to include vibe.d but it didn't happen.
"There's no web services framework (by this time many folks
know of D, but of those a shockingly small fraction has even
heard of vibe.d). I have strongly argued with Sönke to bundle
vibe.d with dmd over one year ago, and also in this forum.
There wasn't enough interest."
https://forum.dlang.org/post/nipb14$ldb$1...@digitalmars.com
- As you acknowledge, integration has drawbacks too. I thought
this was an interesting recent article about how it has now
hobbled one of the biggest tech companies in the world:
https://stratechery.com/2018/intel-and-the-danger-of-integration/
I don't think the web matters enough these days that it is
worth bundling, which is why a webassembly port is also not
worth it for most:
https://www.mobiloud.com/blog/mobile-apps-vs-the-mobile-web/
Instead of trying to integrate vibe.d, which I don't think would
be a good idea, personally I'd rather suggest taking the
opportunity to design the interface of those standard
HTTP-related components from scratch (listener server, fibers,
channels, etc), independently from vibe.d and with a minimalistic
mindset, by taking inspiration mainly from Go, along with Crystal
and vibe.d, even if the implementation will obviously end up
being very similar to the one of vibe.d.
Re: I have a plan.. I really DO
On Friday, 29 June 2018 at 07:03:52 UTC, Dmitry Olshansky wrote: P.S. I mean what you think the future of native code is??? Rust? Crystal?? Nim??? Thank you very much for mentioning about the Crystal programming language. I din't know there is a Crystal lang so I changed my project name from Crystal to Liberty, 2 days ago so people don't get confuzed.
Re: I have a plan.. I really DO
On Sunday, 1 July 2018 at 15:40:20 UTC, Ecstatic Coder wrote:
On Sunday, 1 July 2018 at 14:01:11 UTC, Jonathan M Davis wrote:
On Sunday, July 01, 2018 13:37:32 Ecstatic Coder via
Digitalmars-d-announce wrote:
On Sunday, 1 July 2018 at 12:43:53 UTC, Johannes Loher wrote:
> Am 01.07.2018 um 14:12 schrieb Ecstatic Coder:
>> Add a 10-liner "Hello World" web server example on the
>> main page and that's it.
>
> There already is one in the examples:
>
> #!/usr/bin/env dub
> /+ dub.sdl:
> name "hello_vibed"
> dependency "vibe-d" version="~>0.8.0"
> +/
> void main()
> {
>
> import vibe.d;
> listenHTTP(":8080", (req, res) {
>
> res.writeBody("Hello, World: " ~ req.path);
>
> });
> runApplication();
>
> }
Yeah I know, guess who asked for it...
But the last step, which is including such functionality into
the standard library , will never happen, because nobody here
seems to see the point of doing this.
I guess those who made that for Go and Crystal probably did
it wrong.
What a mistake they did, and they don't even know they make a
mistake, silly them... ;)
What should and shouldn't go in the standard library for a
language is something that's up for a lot of debate and is
likely to often be a point of contention. There is no clear
right or wrong here. Languages that have had very sparse
standard libraries have done quite well, and languages that
have had kitchen sink libraries have done quite well. There
are pros and cons to both approaches.
- Jonathan M Davis
I agree.
But here I'm just talking of the "public image" of the language.
Languages which integrates HTTP-related components in their
standard library, and advertize on that (like Crystal for
instance), obviously apply a different "marketing" strategy
than languages which have chosen not to do so.
That's all I say...
Two points:
- Andrei pushed to include vibe.d but it didn't happen.
"There's no web services framework (by this time many folks know
of D, but of those a shockingly small fraction has even heard of
vibe.d). I have strongly argued with Sönke to bundle vibe.d with
dmd over one year ago, and also in this forum. There wasn't
enough interest."
https://forum.dlang.org/post/nipb14$ldb$1...@digitalmars.com
- As you acknowledge, integration has drawbacks too. I thought
this was an interesting recent article about how it has now
hobbled one of the biggest tech companies in the world:
https://stratechery.com/2018/intel-and-the-danger-of-integration/
I don't think the web matters enough these days that it is worth
bundling, which is why a webassembly port is also not worth it
for most:
https://www.mobiloud.com/blog/mobile-apps-vs-the-mobile-web/
Re: I have a plan.. I really DO
On Sunday, 1 July 2018 at 14:01:11 UTC, Jonathan M Davis wrote:
On Sunday, July 01, 2018 13:37:32 Ecstatic Coder via
Digitalmars-d-announce wrote:
On Sunday, 1 July 2018 at 12:43:53 UTC, Johannes Loher wrote:
> Am 01.07.2018 um 14:12 schrieb Ecstatic Coder:
>> Add a 10-liner "Hello World" web server example on the main
>> page and that's it.
>
> There already is one in the examples:
>
> #!/usr/bin/env dub
> /+ dub.sdl:
> name "hello_vibed"
> dependency "vibe-d" version="~>0.8.0"
> +/
> void main()
> {
>
> import vibe.d;
> listenHTTP(":8080", (req, res) {
>
> res.writeBody("Hello, World: " ~ req.path);
>
> });
> runApplication();
>
> }
Yeah I know, guess who asked for it...
But the last step, which is including such functionality into
the standard library , will never happen, because nobody here
seems to see the point of doing this.
I guess those who made that for Go and Crystal probably did it
wrong.
What a mistake they did, and they don't even know they make a
mistake, silly them... ;)
What should and shouldn't go in the standard library for a
language is something that's up for a lot of debate and is
likely to often be a point of contention. There is no clear
right or wrong here. Languages that have had very sparse
standard libraries have done quite well, and languages that
have had kitchen sink libraries have done quite well. There are
pros and cons to both approaches.
- Jonathan M Davis
I agree.
But here I'm just talking of the "public image" of the language.
Languages which integrates HTTP-related components in their
standard library, and advertize on that (like Crystal for
instance), obviously apply a different "marketing" strategy than
languages which have chosen not to do so.
That's all I say...
I personally appreciate that my Go and Crystal code is mostly
based on standard components which are updated along with the
language, but I agree that vibe.d can perfectly get the job done
if you better trust thirdparty libraries for that.
Re: I have a plan.. I really DO
On Sunday, July 01, 2018 13:37:32 Ecstatic Coder via Digitalmars-d-announce
wrote:
> On Sunday, 1 July 2018 at 12:43:53 UTC, Johannes Loher wrote:
> > Am 01.07.2018 um 14:12 schrieb Ecstatic Coder:
> >> Add a 10-liner "Hello World" web server example on the main
> >> page and that's it.
> >
> > There already is one in the examples:
> >
> > #!/usr/bin/env dub
> > /+ dub.sdl:
> > name "hello_vibed"
> > dependency "vibe-d" version="~>0.8.0"
> > +/
> > void main()
> > {
> >
> > import vibe.d;
> > listenHTTP(":8080", (req, res) {
> >
> > res.writeBody("Hello, World: " ~ req.path);
> >
> > });
> > runApplication();
> >
> > }
>
> Yeah I know, guess who asked for it...
>
> But the last step, which is including such functionality into the
> standard library , will never happen, because nobody here seems
> to see the point of doing this.
>
> I guess those who made that for Go and Crystal probably did it
> wrong.
>
> What a mistake they did, and they don't even know they make a
> mistake, silly them... ;)
What should and shouldn't go in the standard library for a language is
something that's up for a lot of debate and is likely to often be a point of
contention. There is no clear right or wrong here. Languages that have had
very sparse standard libraries have done quite well, and languages that have
had kitchen sink libraries have done quite well. There are pros and cons to
both approaches.
- Jonathan M Davis
Re: I have a plan.. I really DO
On Sunday, 1 July 2018 at 12:43:53 UTC, Johannes Loher wrote:
Am 01.07.2018 um 14:12 schrieb Ecstatic Coder:
Add a 10-liner "Hello World" web server example on the main
page and that's it.
There already is one in the examples:
#!/usr/bin/env dub
/+ dub.sdl:
name "hello_vibed"
dependency "vibe-d" version="~>0.8.0"
+/
void main()
{
import vibe.d;
listenHTTP(":8080", (req, res) {
res.writeBody("Hello, World: " ~ req.path);
});
runApplication();
}
Yeah I know, guess who asked for it...
But the last step, which is including such functionality into the
standard library , will never happen, because nobody here seems
to see the point of doing this.
I guess those who made that for Go and Crystal probably did it
wrong.
What a mistake they did, and they don't even know they make a
mistake, silly them... ;)
Re: I have a plan.. I really DO
Am 01.07.2018 um 14:12 schrieb Ecstatic Coder:
>
> Add a 10-liner "Hello World" web server example on the main page and
> that's it.
There already is one in the examples:
#!/usr/bin/env dub
/+ dub.sdl:
name "hello_vibed"
dependency "vibe-d" version="~>0.8.0"
+/
void main()
{
import vibe.d;
listenHTTP(":8080", (req, res) {
res.writeBody("Hello, World: " ~ req.path);
});
runApplication();
}
Re: I have a plan.. I really DO
On Sunday, 1 July 2018 at 02:57:26 UTC, RhyS wrote: On Saturday, 30 June 2018 at 07:11:18 UTC, Joakim wrote: I'd hope a manager would look at actually meaningful stats like downloads, rather than just fluffy stats such as "likes": http://www.somsubhra.com/github-release-stats/?username=crystal-lang=crystal http://www.somsubhra.com/github-release-stats/?username=ldc-developers=ldc I see around 9k total downloads of the various Crystal 0.24 and 0.25 versions over the last 8 months, compared to 14k downloads of the ldc 1.9 compiler alone from two months ago. Its hard to compare those figure because D and Crystal also use package installers on the respectable platforms. Going to the crystal download page makes that very clear. Making tracking downloads more harder. D can reach more Git downloads thanks to Windows users that do not rely on Linux system packages. D its buginess in between releases also does not help. I probably downloaded LDC and DMD in the last 9 months a dozen times, being forced to go back to older versions. Then trying the new versions, going back. Again and again on Windows. Downloads do not mean a lot when you can not keep the people. I can swear that i alone am probably responsible for over 25+ downloads on Windows and dozens on Linux OS. And every time D loses me after running into issues. Crystal its 0.24 release is still perfectly working here. I literally have downloaded 2 version in the last year. 0.23 and 0.24... That is it. No switching between version because of bugs or package issues or dependency issues. Kind of ironic but maybe because the http server and other packages are build in to the core, i have no need for external 3th party solutions like D's Vibe.d. Of course, all these stats can be gamed, but I think it'd be hard to argue Crystal is more popular. code.d Total 1336 packages found. crystalshards.xyz 3359 total shards Track both sites using archive.org and notice that Crystal is growing faster in regards to Shards then D its packages. Duplicates D something like 6 postgresql driver packages. Crystal has 2 drivers. So D is actually fluffing its numbers with a lot of not maintained duplicates. Mysql ... Its not hard to tell that Crystal its Shards community is more active. Crystal only recently got the funding to get a full time employees to work on the code base. So one can expect the development to increase from a mostly community driven platform. They out gross Nim by almost double on average ( salt.bountysource.com ) and that does not include the 2000$ / month that "84 codes" directly donates. I do not know how much D takes in per month. This has always been a more obscure, as is who are the people that really are paid full time to work on D. Walter? Crystal needs a lot of work but so does D. You expect D to have more its act together for a language this old. No default http server in this day and age is just really weak sauce. And Vibe.d breaks plenty of times in between its releases and DMD releases. Both have issues but one is under development for 4 year and the other for 16 years. You expect D to simply outclass Crystal and other languages. Even Rust is out developing D in many areas, a lot thanks to a big community. +1 At the moement, D's default standard library obviously requires a garbage collector, and this won't change for a while. Trying to convince developers to use D instead of C++ is often pointless, because most of the time, if you develop something in C++ instead of Java/C#/Go/etc, there is a reason for that. And that reason why they don't use those nice garbage collected languages is generally the same reason why they won't use D either. But those who currently use those same garbage collected languages (Go/Java/C#/etc) can be convinced to switch to D, because D's garbage collector won't be probably a problem for them either, as they are already using one in production. So what remains a mystery for me is that the D leadership OBVIOUSLY CAN'T BE CONVINCED that marketing D as a Go/Java/C# alternative could be much more efficient than marketing D as a C/C++ alternative. Why are they trying to sell D on its weakness, instead of selling it on its strength. The only thing that D needs to compete on the same ground as Go and Crystal is to have similar default HTTP-related libraries, which don't rely on thirdparty libraries for the reasons you just explained... Add a 10-liner "Hello World" web server example on the main page and that's it. And if they REALLY want to ALSO compete with C++, then I strongly suggest to add weak and strong references to the syntax (for instance T& and T@), and provide an alternative standard library which doesn't require garbage collection at all, like those of C++ and Rust. But I think it's quite obvious that the first option (Go-like) clearly requires less time and efforts than the second (C++-like).
Re: I have a plan.. I really DO
On Saturday, 30 June 2018 at 21:15:09 UTC, Ecstatic Coder wrote: Already tried. Good luck with that... ;) Well to be clear I'm more providing the feedback out courtesy and thanks for the work people have done on D and vibe.d in particular. While I'd love to see D succeed in the long run, we're blessed with enough options these days that it's not a huge deal to me either way. Thanks for the link to Diamond, I'll check it out. That said, the majority of my use cases are exposing lower level D code as network accessible services and occasionally implementing custom network protocols rather than writing full client web apps in D, but always good to keep various options in mind.
Re: I have a plan.. I really DO
On Sunday, 1 July 2018 at 02:57:26 UTC, RhyS wrote: D its buginess in between releases also does not help. I probably downloaded LDC and DMD in the last 9 months a dozen times, being forced to go back to older versions. Then trying the new versions, going back. Again and again on Windows. Downloads do not mean a lot when you can not keep the people. I can swear that i alone am probably responsible for over 25+ downloads on Windows and dozens on Linux OS. And every time D loses me after running into issues. Been there. Just recently found out about DVM (https://github.com/jacob-carlborg/dvm). Not sure how well it works for Windows.
Re: I have a plan.. I really DO
On Saturday, 30 June 2018 at 12:59:02 UTC, punkUser wrote: I don't normally contribute a lot here but as I've been using a fair mix of C/C++, D and Rust lately for a variety of projects from game dev to web to services, I have a few thoughts. Without exhaustively comparing the different pros/cons of the languages, the most important thing that makes me pick D for a project these days is actually vibe.d. It's the perfect balance between letting me expose my low level stuff as a network/web service easily while not trying to take over too much of my application or conversely get me to manually write async network state machines. I'd happily argue that its cooperative fiber model is actually superior to C#'s, and while it's not quite to the level of Go (mostly just because it's not as ubiquitously supported in the standard library), I'll still happily take the trade-off to use a language closer to C/C++. Rust's web framework and cooperative fiber story is still just forming, and I have some concern they'll go down the C# route which while better than nothing, isn't quite as nice as vibe.d where any function can effectively be part of a cooperative fiber without the need for infectious markup everywhere. Rust's syntax is also a fair bit different than C/C++ which makes it harder to collaborate with people for the moment, while D's is close enough that anyone with a decent amount of C/C++ experience can jump in pretty quickly. In terms of what makes me *not* want to use D, while GC is certainly a factor in some uses, in more cases it's actually that I want more language and compiler stability. While things have calmed down somewhat in the past year the number of times a D update has broken code (mine or code in a dependency) and left me trying to debug someone else's code deep in a library somewhere when I'm trying to just do a small update has been far too high. Rust's "stable" branch and their new epochs model (where the language can change every few years but critically dependencies using different epochs work together) is something I would love to be adopted in D. In any case I just wanted to give the feedback that from my point of view the main thing that keeps me coming back to it for new projects is vibe.d. Thus I'm in favor of making vibe.d a big part of the selling point and design considerations for D going forward. Not to brag and what not, but if you're going straight for web and not anything else then use Diamond, because it gives you so much more than vibe.d alone does, but at the same time allows you to utilize vibe.d to its full extend.
Re: I have a plan.. I really DO
On Saturday, 30 June 2018 at 07:11:18 UTC, Joakim wrote: I'd hope a manager would look at actually meaningful stats like downloads, rather than just fluffy stats such as "likes": http://www.somsubhra.com/github-release-stats/?username=crystal-lang=crystal http://www.somsubhra.com/github-release-stats/?username=ldc-developers=ldc I see around 9k total downloads of the various Crystal 0.24 and 0.25 versions over the last 8 months, compared to 14k downloads of the ldc 1.9 compiler alone from two months ago. Its hard to compare those figure because D and Crystal also use package installers on the respectable platforms. Going to the crystal download page makes that very clear. Making tracking downloads more harder. D can reach more Git downloads thanks to Windows users that do not rely on Linux system packages. D its buginess in between releases also does not help. I probably downloaded LDC and DMD in the last 9 months a dozen times, being forced to go back to older versions. Then trying the new versions, going back. Again and again on Windows. Downloads do not mean a lot when you can not keep the people. I can swear that i alone am probably responsible for over 25+ downloads on Windows and dozens on Linux OS. And every time D loses me after running into issues. Crystal its 0.24 release is still perfectly working here. I literally have downloaded 2 version in the last year. 0.23 and 0.24... That is it. No switching between version because of bugs or package issues or dependency issues. Kind of ironic but maybe because the http server and other packages are build in to the core, i have no need for external 3th party solutions like D's Vibe.d. Of course, all these stats can be gamed, but I think it'd be hard to argue Crystal is more popular. code.d Total 1336 packages found. crystalshards.xyz 3359 total shards Track both sites using archive.org and notice that Crystal is growing faster in regards to Shards then D its packages. Duplicates D something like 6 postgresql driver packages. Crystal has 2 drivers. So D is actually fluffing its numbers with a lot of not maintained duplicates. Mysql ... Its not hard to tell that Crystal its Shards community is more active. Crystal only recently got the funding to get a full time employees to work on the code base. So one can expect the development to increase from a mostly community driven platform. They out gross Nim by almost double on average ( salt.bountysource.com ) and that does not include the 2000$ / month that "84 codes" directly donates. I do not know how much D takes in per month. This has always been a more obscure, as is who are the people that really are paid full time to work on D. Walter? Crystal needs a lot of work but so does D. You expect D to have more its act together for a language this old. No default http server in this day and age is just really weak sauce. And Vibe.d breaks plenty of times in between its releases and DMD releases. Both have issues but one is under development for 4 year and the other for 16 years. You expect D to simply outclass Crystal and other languages. Even Rust is out developing D in many areas, a lot thanks to a big community.
Re: I have a plan.. I really DO
On Saturday, 30 June 2018 at 12:59:02 UTC, punkUser wrote: I don't normally contribute a lot here but as I've been using a fair mix of C/C++, D and Rust lately for a variety of projects from game dev to web to services, I have a few thoughts. Without exhaustively comparing the different pros/cons of the languages, the most important thing that makes me pick D for a project these days is actually vibe.d. It's the perfect balance between letting me expose my low level stuff as a network/web service easily while not trying to take over too much of my application or conversely get me to manually write async network state machines. I'd happily argue that its cooperative fiber model is actually superior to C#'s, and while it's not quite to the level of Go (mostly just because it's not as ubiquitously supported in the standard library), I'll still happily take the trade-off to use a language closer to C/C++. Rust's web framework and cooperative fiber story is still just forming, and I have some concern they'll go down the C# route which while better than nothing, isn't quite as nice as vibe.d where any function can effectively be part of a cooperative fiber without the need for infectious markup everywhere. Rust's syntax is also a fair bit different than C/C++ which makes it harder to collaborate with people for the moment, while D's is close enough that anyone with a decent amount of C/C++ experience can jump in pretty quickly. In terms of what makes me *not* want to use D, while GC is certainly a factor in some uses, in more cases it's actually that I want more language and compiler stability. While things have calmed down somewhat in the past year the number of times a D update has broken code (mine or code in a dependency) and left me trying to debug someone else's code deep in a library somewhere when I'm trying to just do a small update has been far too high. Rust's "stable" branch and their new epochs model (where the language can change every few years but critically dependencies using different epochs work together) is something I would love to be adopted in D. In any case I just wanted to give the feedback that from my point of view the main thing that keeps me coming back to it for new projects is vibe.d. Thus I'm in favor of making vibe.d a big part of the selling point and design considerations for D going forward. Already tried. Good luck with that... ;)
Re: I have a plan.. I really DO
I don't normally contribute a lot here but as I've been using a fair mix of C/C++, D and Rust lately for a variety of projects from game dev to web to services, I have a few thoughts. Without exhaustively comparing the different pros/cons of the languages, the most important thing that makes me pick D for a project these days is actually vibe.d. It's the perfect balance between letting me expose my low level stuff as a network/web service easily while not trying to take over too much of my application or conversely get me to manually write async network state machines. I'd happily argue that its cooperative fiber model is actually superior to C#'s, and while it's not quite to the level of Go (mostly just because it's not as ubiquitously supported in the standard library), I'll still happily take the trade-off to use a language closer to C/C++. Rust's web framework and cooperative fiber story is still just forming, and I have some concern they'll go down the C# route which while better than nothing, isn't quite as nice as vibe.d where any function can effectively be part of a cooperative fiber without the need for infectious markup everywhere. Rust's syntax is also a fair bit different than C/C++ which makes it harder to collaborate with people for the moment, while D's is close enough that anyone with a decent amount of C/C++ experience can jump in pretty quickly. In terms of what makes me *not* want to use D, while GC is certainly a factor in some uses, in more cases it's actually that I want more language and compiler stability. While things have calmed down somewhat in the past year the number of times a D update has broken code (mine or code in a dependency) and left me trying to debug someone else's code deep in a library somewhere when I'm trying to just do a small update has been far too high. Rust's "stable" branch and their new epochs model (where the language can change every few years but critically dependencies using different epochs work together) is something I would love to be adopted in D. In any case I just wanted to give the feedback that from my point of view the main thing that keeps me coming back to it for new projects is vibe.d. Thus I'm in favor of making vibe.d a big part of the selling point and design considerations for D going forward.
Re: I have a plan.. I really DO
On Saturday, 30 June 2018 at 07:11:18 UTC, Joakim wrote: On Saturday, 30 June 2018 at 06:52:01 UTC, Ecstatic Coder wrote: On Friday, 29 June 2018 at 22:59:25 UTC, bachmeier wrote: On Friday, 29 June 2018 at 20:13:07 UTC, Ecstatic Coder wrote: Have a look at Crystal's Github project, you will see that Crystal, still in development and quite far from its 1.0 mile version (= despite no parallism and windows support, etc) ALREADY has 11206 stars, 881 forks and 292 contributors : https://github.com/crystal-lang/crystal Not bad for a language in its 0.25 version and first released in June 2014 (4 years), especially compared to D in its 2.0 version and first released in December 2001 (16 years), whose official compiler has 1806 stars, 452 forks and 168 contributors : https://github.com/dlang/dmd If those numbers means anything, I think its that Crystal is probably getting popularity much quicker than D, and honestly, after having tried it, I think it's really deserved, even if I agree that there are still many things that remain to be implemented before it's really ready for an official "production-ready" 1.0 release. Do you by chance work as a manager? Managers like comparisons that involve one number, with a higher number being better. I don't know what can be learned about D from that comparison and I don't think anyone else does either. That's your opinion. First, most managers don't become manager by chance, but because of their skills. Like being able to take the right decisions, based on facts, not on personal preferences. For instance, if a good manager sees that the github project of a 4 years old compiler has been liked by 11206 persons, and the github project of a 16 years old compiler has been liked by 1806 persons, I think he could probably think that MUCH more people are interested in the development of the first github project than in the second. I'd hope a manager would look at actually meaningful stats like downloads, rather than just fluffy stats such as "likes": http://www.somsubhra.com/github-release-stats/?username=crystal-lang=crystal http://www.somsubhra.com/github-release-stats/?username=ldc-developers=ldc I see around 9k total downloads of the various Crystal 0.24 and 0.25 versions over the last 8 months, compared to 14k downloads of the ldc 1.9 compiler alone from two months ago. Of course, all these stats can be gamed, but I think it'd be hard to argue Crystal is more popular. Anyway, I you think that Crystal is not worth our attention, it's your right. But my PERSONAL opinion is that Crystal will soon become a great alternative to D, Go and Rust for web server development, while I still think that D is BY FAR a much better language than Go or Rust. So now we can try to analyze what make Crystal a useful and popular language in this domain and learn lessons from it, or simply ignore it. Very honestly I don't care, because I exclusively use D as a file processing scripting language, and I'm very happy with D in its current state. And to be perfectly clear on that point, its current syntax is perfect, very simple and concise, and if DON'T want any change made to its current syntax which would make it less simple and concise when using it in GC mode.
