Re: Symmetry Autumn of Code
On Sunday, 5 August 2018 at 05:22:44 UTC, Mike Franklin wrote: On Sunday, 5 August 2018 at 04:47:42 UTC, tanner00 wrote: Hi, I’m interested in working on this project and just wanted to touch base. Is there any word on who will be mentoring this project? I’m entering college this fall but I’ve been programming since a very young age and enjoy systems programming. The project is mostly about creating high-performance, resource-efficient 2D software rasterizer, something like this (http://nothings.org/gamedev/rasterize/) or (https://medium.com/@raphlinus/inside-the-fastest-font-renderer-in-the-world-75ae5270c445) If that isn't enough work for the event you can build on it by creating path objects with clipping and offsetting (http://angusj.com/delphi/clipper.php), rasterizing TrueType or OpenType fonts, creating drawing primitives, and even potentially creating 2D widgets (buttons, text labels, etc.) I think it's up to you how much of it you want to take on. I proposed the idea, but I don't think I'd be a very good mentor for the project because I've never created a 2D rasterizer myself. However, I'd be happy to help anyone working on the project in an unofficial capacity, and can probably articulate the intended use case for it. Mike I was 14 and a half when I implemented my first depth buffer based rasterizer, in 6502 assembly on a C64, for a hi-res mode 3D renderer. The algorithm, despite being "naive", is actually still an efficient one even now. I stored an array of x/depth ranges (one per raster line), and updated them while drawing the wireframe points of the 3 clipped edges, while updating the y range of the triangle. Then I simply iterated on the triangle y range and drew the inner points (between minimum_x+1 and maximum_x-1), using the filling color and interpolating depth. Clearly not realtime as my character-based wireframe renderer, I admit it. But this more than fast enough to quickly render a hi-res 3d scene in memory in *filled* mode. So this "dumb" algorithm may still be worth being investigated in your case, as this C64 implementation was meant to run on a rather similar hardware (very limited memory and CPU, only fixed point operations, etc). Just add antialiasing on the wireframe edges and you're done...
Re: Symmetry Autumn of Code
On Sunday, 5 August 2018 at 05:16:50 UTC, Mike Parker wrote:
On Sunday, 5 August 2018 at 04:47:42 UTC, tanner00 wrote:
[...]
Hi, I’m interested in working on this project and just wanted
to touch base. Is there any word on who will be mentoring this
project? I’m entering college this fall but I’ve been
programming since a very young age and enjoy systems
programming.
No one has volunteered to mentor this project yet, but if you'd
like to write a proposal for it we can find a mentor if you are
selected.
Btw I *had* ("And I'd be glad to mentor you on this :)", here on
July 24th).
Thanks for remembering me why I now better enjoy the Crystal
community...
Re: Symmetry Autumn of Code
On Monday, 23 July 2018 at 08:08:03 UTC, Mike Franklin wrote: On Monday, 23 July 2018 at 06:24:04 UTC, Zheng (Vic) Luo wrote: Moreover, The term "dependency-free" in the project description often confuses me, because as a hardware-agnostic library the project does have to depend on external implementations like "sin"/"memset" or even "thread_start", and I'm not sure which kind of dependency is proper for this project: Should we assume a multi-threading model? Should this library rely on "malloc"/"free"? Correct me if my understanding is wrong since I had few experience on embedded programming. There is more to this project than just getting a software rasterizer in D. Part of the goal is to demonstrate D as a formidable alternative to C in micrcontroller firmware programming. D will never achieve that notoriety if it's always depending on C, the C runtime, the C standard library, or some library implemented in C. So, IMO, if you need to link in a library or object file that was not compiled from D code, then you're cheating. This is also one of the reasons why I suggested re-implementing software building blocks such as `memcpy`, `memset`, `malloc`, `free`, etc. in D as another potential project for the Autumn of Code. So, to keep this software rasterizer project within scope, I suggest creating naive implementations of those functions in D for now to stay true to spirit of the project (no dependencies, everything in D), and "make the point". You can those software building blocks in their own module, and let the user of the software rasterizer library link it their own implementation if they wish to deviate from the spirit of the proposal. Mike I agree But this BetterC minimalistic standard library (allocations, arrays, strings, slices, maps) is something which can be reused by many similar hardware-level projects. This is a project on its own, and as I said, I think it should better be provided to the candidate so he can use his development time on developing the rasterizer, and, if there is enough time, a minimalistic nuklear-like gui system over it to demonstrate its performance and usefulness.
Re: Symmetry Autumn of Code
On Monday, 23 July 2018 at 09:09:40 UTC, Mike Franklin wrote: On Sunday, 22 July 2018 at 17:12:31 UTC, Ecstatic Coder wrote: 2/ Nuklear (https://github.com/vurtun/nuklear) Reading the documentation for Nuklear, I found this: https://rawgit.com/vurtun/nuklear/master/doc/nuklear.html#drawing To draw all draw commands accumulated over a frame you need your own render backend able to draw a number of 2D primitives. This includes at least filled and stroked rectangles, circles, text, lines, triangles and scissors That's basically what the Autumn of Code proposal would like to have built in D: A rasterizer with fundamental drawing primitives. So, it seems Nuklear is a library intended to be built on top of the proposed rasterizer. Mike +1 Then I agree that Antigrain is probably the best reference code for the antialiased renderer, as its code is small, very complete (ttf/gsv/raster fonts, top quality antialiasing, etc) and reasonably fast. IMO the better-C standard library runtime should be provided to the developer in charge of developing that rasterizer.
Re: Symmetry Autumn of Code
I'm interested in the "Graphics library for resource constrained embedded systems" project and have some spare time this autumn, but I have some questions: - Does this project aim at creating a hardware-agnostic rasterizer supporting a few primitives like https://skia.org/ or implementing a full GUI library like emWin rendering widget and handling I/O events such as mouse? The latter one sounds a little bit challenging to finish in four months - In the past year I primarily wrote C++ and don't have much experiences with production-level D programming, can I get involved into this program? Thanks IMHO no need to reinvent the wheel for that. You can probably do both in four months, if you just "port" (separately) and bind the code of the two following libraries : 1/ swGL (https://github.com/h0MER247/swGL) 2/ Nuklear (https://github.com/vurtun/nuklear) They have a very open design, and are already quite well optimized for speed and memory consumption. Moreover this would allow the D port of the Nuklear library to also use a hardware accelerated renderer on desktop platforms. Nice isn't it ? And I'd be glad to mentor you on this :)
Re: Symmetry Autumn of Code
I've said, that if we get signatures, I'll build the damn thing myself. Signatures give a very lightweight vtable implementation while also giving conceptual representation of structs+classes. Which for an event loop, is a very desirable thing to have. But alas, I'm waiting on my named parameter DIP and seeing where that goes, before continuing work on signatures. Thanks for the clear explanations. Glad to know that you're on this. I hope the importance of your work for D's "competivity" will be truly recognized.
Re: Symmetry Autumn of Code
On Wednesday, 18 July 2018 at 03:19:53 UTC, rikki cattermole wrote: On 18/07/2018 5:36 AM, Ecstatic Coder wrote: On Saturday, 14 July 2018 at 06:02:37 UTC, Mike Parker wrote: Thanks to the sponsorship of Symmetry Investments, the D Language Foundation is happy to announce the Symmetry Autumn of Code! We're looking for three university students to hack on D this autumn, from September - January. We're also in search of potential mentors and ideas for student projects. Head to the Symmetry Autumn of Code page for the details. Spread the word! https://dlang.org/blog/symmetry-autumn-of-code/ I'd suggest adding the following to SAOC 2018 project proposals : 1/ adding a Go-like http module to the standard library 2/ adding Go-like async IO management to the standard library, i.e. fibers communicating through blocking channels Until we get an event loop in druntime, both of these options are off the table. Sad. Then I'd suggest to add the event loop implementation to SAOC 2018 too, because the absence of a default http module in D's standard library may have very good justifications, but I'm still convinced that it doesn't help when trying to "sell" it to modern developers, considering that nowadays MANY of the applications they will develop in a professional facility will have to integrate http code to access or update the company's data.
Re: Symmetry Autumn of Code
On Saturday, 14 July 2018 at 06:02:37 UTC, Mike Parker wrote: Thanks to the sponsorship of Symmetry Investments, the D Language Foundation is happy to announce the Symmetry Autumn of Code! We're looking for three university students to hack on D this autumn, from September - January. We're also in search of potential mentors and ideas for student projects. Head to the Symmetry Autumn of Code page for the details. Spread the word! https://dlang.org/blog/symmetry-autumn-of-code/ I'd suggest adding the following to SAOC 2018 project proposals : 1/ adding a Go-like http module to the standard library 2/ adding Go-like async IO management to the standard library, i.e. fibers communicating through blocking channels 3/ possibility to use automatic reference counting (with weak references) instead of garbage collection for automatic unused memory deallocation 4/ adding automatic cycle detection and collection to the automatic reference counting system (https://wiki.dlang.org/SAOC_2018_ideas) Thanks :)
Re: Funding code-d
On Friday, 13 July 2018 at 15:05:05 UTC, Michael wrote: On Friday, 13 July 2018 at 14:20:19 UTC, Mike Parker wrote: As promised in my tweet of June 30 (and to the handful of people who emailed me), the cloud of mystery surrounding the use of the money raised for code-d and its supporting tools has now been (partially) lifted! In this post, I lay out the details of how the first $1000 will be paid out to project maintainer Jan Jurzitza, a.k.a Webfreak001, and explain what we hope to achieve with this ecosystem fundraising initiative going forward. This time around, it all came together in the background of prepping for DConf with little forethought beyond activating an Open Collective goal and then working with Jan to determine the details. Lessons were learned. Later this year, you'll see the result when we announce the next of what we hope to be an ongoing series of funding targets. In the meantime: The blog https://dlang.org/blog/2018/07/13/funding-code-d/ Reddit https://www.reddit.com/r/d_language/comments/8yka7b/funding_coded_the_d_blog/ I think this is a worthy cause for the money. I'm glad to see the D foundation looking more towards investing in these kinds of community projects, as they make up the D ecosystem that many opponents of D describe as lacking. Yeah, indeed all of my friends who tried D and were not convinced that's it's a good alternative to Go/C++/etc were pushed away by a bad support in Visual Studio Code. Even those who didn't use Visual Studio Code (most of them actually). Like being able to automatically make a foreach loop become parallel for instance. Invaluable... Keep up the good work and let's invest still more money in extending further this fantastic plugin. PS: Joking... ;)
Re: Funding code-d
On Saturday, 14 July 2018 at 16:19:29 UTC, Joakim wrote: On Friday, 13 July 2018 at 14:20:19 UTC, Mike Parker wrote: As promised in my tweet of June 30 (and to the handful of people who emailed me), the cloud of mystery surrounding the use of the money raised for code-d and its supporting tools has now been (partially) lifted! In this post, I lay out the details of how the first $1000 will be paid out to project maintainer Jan Jurzitza, a.k.a Webfreak001, and explain what we hope to achieve with this ecosystem fundraising initiative going forward. This time around, it all came together in the background of prepping for DConf with little forethought beyond activating an Open Collective goal and then working with Jan to determine the details. Lessons were learned. Later this year, you'll see the result when we announce the next of what we hope to be an ongoing series of funding targets. In the meantime: The blog https://dlang.org/blog/2018/07/13/funding-code-d/ Reddit https://www.reddit.com/r/d_language/comments/8yka7b/funding_coded_the_d_blog/ Nice explication of the plan, really needed. Why github never rolled out such a bounty program for OSS and other public projects has to be one of the head-scratching moves of all time, no wonder they were about to run out of money before they sold. A good way to decide on future projects would be to let prospective donors stake money on various proposals, to see how much backing they might receive, sort of like how kickstarter and other crowdfunding sites work. +1 May I suggest the two following improvements for the next proposals : 1/ integrating a Go-like web server code inside the default library (http module, fiber and channel async IO) 2/ possibility to use automatic reference counting (with weak references and optional cycle detection) instead of garbage collection for automatic unused memory deallocation The first one to help D compete on the same grounds as Go and Crystal, and the second to make it usable in the same GC-unwanted use cases where people currently use C or C++. Probably just a silly idea, please feel free to completely ignore it... PS: Geany is also a VERY nice multi-platform IDE to develop in C++ and D on Linux, Windows and Mac, for those who still don't know it...
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: 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 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
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 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
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 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 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 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
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 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 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 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
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 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: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
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
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
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
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 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 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, 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
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 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
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.
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. Obviously you haven't read my post. No problem, I'll repeat it. I said that Crystal is probably gaining popularity FASTER than D. I've never said that Crystal is more used than D. FYI, D is in the top 50 at the TIOBE index, while Crystal is only in the top 100. Of course, you will tell me that these rankings are numbers, and that a higher number means nothing. Right ?
Re: I have a plan.. I really DO
DasBetterC resolves that, though the library issue remains. Indeed. Unfortunately, it's often the standard library which makes the difference between a nice language, and a nice useful language. D is a great language not only because of the many great decisions you made when designing the language (UFCS, slice-based strings and arrays, etc), but also because of its great standard library, which is well designed and very complete. To be really useful as a C++ alternative, D still needs another standard library based on reference counting, instead of garbage collection, even if this implies that some class interfaces will have to diverge from their GC-based counterpart. Without that, D will be a bit like a gun without ammunitions for many developers. And Rust, despite it has perfect C/C++-like performance D has perfect C/C++ like performance, if you code it the same way. +1 :)
Re: I have a plan.. I really DO
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. But if you want to think the opposite, it's perfectly your right, I've got not problem with that.
Re: I have a plan.. I really DO
On Friday, 29 June 2018 at 20:51:56 UTC, bauss wrote: On Friday, 29 June 2018 at 20:13:07 UTC, Ecstatic Coder wrote: On Friday, 29 June 2018 at 19:46:06 UTC, bauss wrote: On Friday, 29 June 2018 at 19:42:56 UTC, Ecstatic Coder wrote: On Friday, 29 June 2018 at 17:09:44 UTC, JN wrote: On Friday, 29 June 2018 at 08:43:34 UTC, Ecstatic Coder wrote: Once Crystal integrates parallelism (at 1.0), it should become de facto one of the best alternative to Go, Java, C#, etc, because it's actually "Go-made-right". For instance it's genericity system works well, and its type inference system natively support union types. Except it has no Windows support and doesn't look like it will happen anytime soon. Some people might be living in a UNIX bubble, but Windows is a big market, and a language won't make it big without Windows support. Right :) But remember that Crystal is still in its infancy, as it hasn't reached its 1.0 version yet. Parallelism is on its way, and Windows support too... Don't forget that nowadays many (can I say most ?) servers are based on unix variants, so their platform support order looks perfectly fine and logical to me. Actually a large share of servers run Windows Server and/or Azure servers running Windows too. It's not logical to not support both. D already has that advantage supporting pretty much every platform you can think of. I agree, but you must compare what is comparable. 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. Yes. Crystal is a fantastic language already. As someone who uses many languages, I tend to just use what does the task at hand best. I'm sure I'll be able to find some usage for Crystal when it's production ready, but it doesn't mean I'll abandon D. That'll probably never happen, especially considering I have a lot of projects written in D with thousands of lines of code. Same for me :)
Re: I have a plan.. I really DO
On Friday, 29 June 2018 at 19:46:06 UTC, bauss wrote: On Friday, 29 June 2018 at 19:42:56 UTC, Ecstatic Coder wrote: On Friday, 29 June 2018 at 17:09:44 UTC, JN wrote: On Friday, 29 June 2018 at 08:43:34 UTC, Ecstatic Coder wrote: Once Crystal integrates parallelism (at 1.0), it should become de facto one of the best alternative to Go, Java, C#, etc, because it's actually "Go-made-right". For instance it's genericity system works well, and its type inference system natively support union types. Except it has no Windows support and doesn't look like it will happen anytime soon. Some people might be living in a UNIX bubble, but Windows is a big market, and a language won't make it big without Windows support. Right :) But remember that Crystal is still in its infancy, as it hasn't reached its 1.0 version yet. Parallelism is on its way, and Windows support too... Don't forget that nowadays many (can I say most ?) servers are based on unix variants, so their platform support order looks perfectly fine and logical to me. Actually a large share of servers run Windows Server and/or Azure servers running Windows too. It's not logical to not support both. D already has that advantage supporting pretty much every platform you can think of. I agree, but you must compare what is comparable. 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.
Re: I have a plan.. I really DO
On Friday, 29 June 2018 at 18:48:19 UTC, bauss wrote: On Friday, 29 June 2018 at 17:08:12 UTC, Ecstatic Coder wrote: If you're a web developer with no dependencies then youre either reinventing the wheel (could cause trouble in the long run, if your implementations aren't correct.) Or your application just isn't more than a hobby project. Most enterprise projects will have dependencies outside standard libraries and that is true for ex. Go too. I agree with you, but what I mean is that all those nice Go and Crystal web frameworks are actually implemented using exactly the same building blocks, so that their authors didn't have to reinvent the wheel to reimplement them. That's why there are so many available frameworks, and you can easily pick one which closely matches your needs and preferences... Well you don't really need to re-invent the wheel at all with D either tbh. You would need to with vibe.d, because it's really just the skeleton of a web application, but with Diamond? Not so much. It supports things that other frameworks don't even support, which you will end up implementing yourself anyway in 99% of all other frameworks. To give an example, consent, privacy and GDPR. There is no framework, at least what I have seen, that has compliance for such things implemented, but Diamond has it usable straight out of the box. Another example would be validation for email, url, various credit-cards, files (Not just extension, but also whether the data is correct.) etc. most of such validations are very limited in other frameworks or non-existent at all. My point is that, even if those languages has http somewhat standard, they do not implement actual features that are useful to your business logic, application design etc. only to the skeleton. However with frameworks in D you do get the best of both worlds. http://diamondmvc.org/ Indeed this framework looks really complete, and should get much more promotion from D's official website. But I still think that D's vision of what should be included in the standard library really diverges from those of Go and Crystal, despite this strategy has worked pretty well for them, and that Diamond clearly proves that D has all the basic language features to compete well with them (native performance, fiber-based concurrency, great string and array support, etc).
Re: I have a plan.. I really DO
On Friday, 29 June 2018 at 17:09:44 UTC, JN wrote: On Friday, 29 June 2018 at 08:43:34 UTC, Ecstatic Coder wrote: Once Crystal integrates parallelism (at 1.0), it should become de facto one of the best alternative to Go, Java, C#, etc, because it's actually "Go-made-right". For instance it's genericity system works well, and its type inference system natively support union types. Except it has no Windows support and doesn't look like it will happen anytime soon. Some people might be living in a UNIX bubble, but Windows is a big market, and a language won't make it big without Windows support. Right :) But remember that Crystal is still in its infancy, as it hasn't reached its 1.0 version yet. Parallelism is on its way, and Windows support too... Don't forget that nowadays many (can I say most ?) servers are based on unix variants, so their platform support order looks perfectly fine and logical to me.
Re: I have a plan.. I really DO
If you're a web developer with no dependencies then youre either reinventing the wheel (could cause trouble in the long run, if your implementations aren't correct.) Or your application just isn't more than a hobby project. Most enterprise projects will have dependencies outside standard libraries and that is true for ex. Go too. I agree with you, but what I mean is that all those nice Go and Crystal web frameworks are actually implemented using exactly the same building blocks, so that their authors didn't have to reinvent the wheel to reimplement them. That's why there are so many available frameworks, and you can easily pick one which closely matches your needs and preferences...
Re: I have a plan.. I really DO
On Friday, 29 June 2018 at 10:06:12 UTC, bauss wrote:
On Friday, 29 June 2018 at 08:43:34 UTC, Ecstatic Coder wrote:
As you know, I'm convinced that D could be marketed as the
perfect language to develop native web servers and mobile
applications, and have its core libraries somewhat extended in
thqg direction, like Go and Crystal which allow "plug'n'play"
web server development for instance
D allows for plug n' play web server development too.
Then this should be more advertised...
For instance :
https://crystal-lang.org/
The FIRST paragraph of text of Crystal's web page is :
"Syntax
Crystal’s syntax is heavily inspired by Ruby’s, so it feels
natural to read and easy to write, and has the added benefit of a
lower learning curve for experienced Ruby devs.
# A very basic HTTP server
require "http/server"
server = HTTP::Server.new do |context|
context.response.content_type = "text/plain"
context.response.print "Hello world, got
#{context.request.path}!"
end
puts "Listening on http://127.0.0.1:8080;
server.listen(8080)
"
So the FIRST thing you learn about Crystal is that the standard
library already gives you all you need to program a simple "hello
world" web server.
The Go standard library is also known to provide the same
building blocks :
package main
import (
"fmt"
"net/http"
)
func main() {
http.HandleFunc("/", func(w http.ResponseWriter, r
*http.Request) {
fmt.Fprintf(w, "Hello, you've requested: %s\n", r.URL.Path)
})
http.ListenAndServe(":80", nil)
}
Both are batteries-included for web development. That's why many
developers don't feel the need to use thirdparty frameworks to
implement their microservices...
So if it's also the case for D, then sorry for my mistake...
Re: I have a plan.. I really DO
Anyway, I try to avoid GC as much as possible. The main issue for me in game development with D is the cross-compilation (e.g. iOS, Windows Universal Platform..). +1 That's why I don't think C++ will be soon replaced by Rust, D, etc Maybe in a few years, but obviously not right now...
Re: 'static foreach' chapter and more
On Tuesday, 26 June 2018 at 01:52:42 UTC, Ali Çehreli wrote: I've made some online improvements to "Programming in D" since September 2017. http://ddili.org/ders/d.en/index.html NOTE: The copies of the book at hard copy printers are not updated yet. If you order from Amazon etc. it will still be the OLD version. I need some more time to work on that... Also, only the PDF electronic format is up-to-date; other ebook formats are NOT. * The code samples are now up-to-date with 2.080.1 * Digit separator (%,) format specifier: http://ddili.org/ders/d.en/formatted_output.html#ix_formatted_output.separator * Stopwatch is moved to module std.datetime.stopwatch * Replace 'body' with 'do' * Text file imports (string imports): http://ddili.org/ders/d.en/mixin.html#ix_mixin.file%20import * First assignment to a member is construction (search for that text on the page): http://ddili.org/ders/d.en/special_functions.html#ix_special_functions.this,%20constructor * static foreach: http://ddili.org/ders/d.en/static_foreach.html#ix_static_foreach.static%20foreach Ali Thanks for also providing this book as a free download. It's THE perfect book both for people who are learning to program for the first time as for experience developers who are just learning the D language !
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??? And btw, if D could have its standard libraries and language features (strings, arrays, maps, slices, etc) also NATIVELY work without GC (= NATIVE weak/strong reference counting), IMHO D could perfectly be the future of native code, as it could become a better alternative to both C++, Rust, Go, etc
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??? I know most people here don't agree with me, but I think you're fighting an already lost battle ;) As you know, I'm convinced that D could be marketed as the perfect language to develop native web servers and mobile applications, and have its core libraries somewhat extended in thqg direction, like Go and Crystal which allow "plug'n'play" web server development for instance, but obviously the D "leadership" remains convinced that D must be sold as the best alternative to C++. Personally I'm a complete D fan because it is SOOO MUCH better than JavaScript/Python/Perl/etc for file processing... For engine and game development I'm still using C++, despite I prefer D, and believe me this won't change for a while. Game development is a very special use case, but personally I don't think that many of those who use C++ for close-to-the-metal development should be that much interested in switching to D, because most of its standard libraries depend on the presence of a GC... And to answer your question, IMHO the future of native code probably remains C++ (not Rust) for system programming, and (unfortunately) Go for web development (great ecosystem, db drivers, often faster than Java, C#, Dart, etc) despite it lacks several core feature many developers need (generics, etc). Once Crystal integrates parallelism (at 1.0), it should become de facto one of the best alternative to Go, Java, C#, etc, because it's actually "Go-made-right". For instance it's genericity system works well, and its type inference system natively support union types. Nim disqualifies itself because contrarily to D and C# for instance, it doesn't manage mutual dependencies automatically for you, which is a pity. And Rust, despite it has perfect C/C++-like performance and doens't need a GC, its borrow checker made it a hell to use at first, as unfortunately Rust hasn't integrated strong/weak references as a core feature of the language (Rc/Weak are templates, RefCell is needed for mutability, etc), despite that's actually what many C++ developers use today for resource management, and would be more than enough for them to get their job done once they switch to Rust...
Re: How an Engineering Company Chose to Migrate to D
IMHO, implementing a EP-to-D source code converter was probably more risky than simply extending an existing Pascal Compiler in that case. Risc is in the eye of the beholder ;-) Indeed :) But that doesn't mean I'm completely wrong. I also enjoy A LOT implementing minimalistic transpilers using the most simplistic code possible, because implementing manual tokenization and a parsing using only "baby code" is really all that's needed for my small DSLs. My Github account is literally full of them ;) So yes, implementing transpilers is incredibly fun and easy. But implementing full blown compilers too actually. And the advantage of compilers which generate assembly code is that you don't have to fight with the unavoidable limitations of the high-level target language. For instance I've implemented my first "true" compiler in Basic when I was 13 years old, in order to implement my first 3D renderer and game for my C64 (a simple 3D wireframe tank game using a custom 2x4 pixel charset for rendering), as I quickly found out that it was actually much faster and easier to implement it in a minimalistic basic-like language with integrated fixed point and pointer arithmetic converted into 6502 machine language, than to implement the game directly in 6502 assembler. So if at one moment you hit a wall with the transpiling approach, you should consider trusting me if I say that implementing an EP compiler which emits IL code could actually be just a matter of months. Look at the code of this tutorial, which shows how to implement a very limited closure-based language (i.e. with local functions and variable) in C using just Flex and Bison : https://github.com/senselogic/COMPILER_TUTORIAL It was implemented in just a few days, and if you check by yourself, you will see that it's 100% baby code... So if you change your mind and decide to implement your own extended EP compiler (i.e. with additional modern features), you could be astonished by the number of passionate developers who could also be interested in this "modern object Pascal" project... That's the approach they've had for Crystal, and so far it's worked quite well for them...
Re: How an Engineering Company Chose to Migrate to D
Man, proggit can be savage with the criticism. Every Nim/Rust and the one Ada programmer have come out of the woodwork to make sure you know their language supports nested functions. You've seemingly got to be an expert in every current language to write a comparison article that suggests D may have some advantages. I've read the criticisms about the choice of the alternative language on the Reddit page, and I think that most of them are finally quite unfair. In my programming career, I've already used many strongly-typed languages (C, C++, C#, Java, D, Go, Rust, Nim, Crystal, Julia, Pascal, etc) for at least one professional or personal project, and I'm also convinced that D is a good alternative to EP, especially compared to C++, Go and Rust for instance. Where I disagree with Bastiaan is on the rejection of the Pascal language itself, as there are other open-source Pascal compilers (GNU Pascal in EP mode) which could have been used and enhanced to match the company requirements, while preserving the company future for the decades to come. IMHO, implementing a EP-to-D source code converter was probably more risky than simply extending an existing Pascal Compiler in that case. Like everybody here, I hope that Bastiaan efforts will pay in the long term, but I'm not as optimistic as many here that this will end as a success story, as I'm not sure that his teammates will really enjoy working the automatically generated D code as much as on the original source code...
Textual database designer (Basil 2.0)
For those interested, Basil, my textual database designer, can now export database schemas in SQL, CQL, Go and Crystal format, and their fake data in SQL and CQL format. I've slightly changed the syntax so that the table columns can use any combination of scalar types, foreign keys, tuples, maps, lists and sets. You can download it here : https://github.com/senselogic/BASIL Here are two sample scripts illustrating the new syntax : BLOG | count 5 SECTION Id : UINT64 | key, unique, incremented Number : UINT64 Name : STRING | capacity 45 Text : STRING Image : STRING | capacity 45 ImageIndex : UINT64 | !stored USER Id : UINT64 | key, unique, incremented FirstName : STRING | capacity 45 LastName : STRING | capacity 45 Email : STRING | capacity 45 Pseudonym : STRING | capacity 45 Password : STRING | capacity 45 Phone : STRING | capacity 45 Street : STRING City : STRING | capacity 45 Code : STRING | capacity 45 Region : STRING | capacity 45 Country : STRING | capacity 45 Company : STRING | capacity 45 ItIsAdministrator : BOOL ARTICLE | count 15 Id : UINT64 | key, unique, incremented SectionId : SECTION.Id | partitioned UserId : USER.Id | clustered Title : STRING Text : STRING Image : STRING | capacity 45 Date : DATE Section : POINTER[ SECTION ] | !stored User : POINTER[ USER ] | !stored ImageIndex : UINT64 | !stored COMMENT | count 30 Id : UINT64 | key, unique, incremented ArticleId : ARTICLE.Id | indexed UserId : USER.Id | indexed Text : STRING | english 2 4 5 7 DateTime : DATETIME Article : POINTER[ ARTICLE ] | !stored User : POINTER[ USER ] | !stored SUBSCRIBER Id : UINT64 | key, unique, incremented Name : STRING | capacity 45 Email : STRING | capacity 45 TEST | count 10 SIMPLE Uuid : UUID | key, unique Bool : BOOL | partitioned Int8 : INT8 | clustered Uint8 : UINT8 | indexed Int16 : INT16 Uint16 : UINT16 Int32 : INT32 Uint32 : UINT32 Int64 : INT64 Uint64 : UINT64 Float32 : FLOAT32 Float64 : FLOAT64 String : STRING Date : DATE | unique DateTime : DATETIME Blob : BLOB COMPOUND Id : INT32 | key, unique, incremented Location : Country : STRING | uppercase Name : TUPLE[ FirstName : STRING, LastName : STRING ] | unique NameSet : SET[ TUPLE[ FirstName : STRING, LastName : STRING ] ] | count 2 CompanyMap : MAP[ Phone : STRING, Company : STRING ] | count 2 EmailSet : SET[ Email : STRING ] | count 2 PhoneList : LIST[ Phone : STRING ] | count 2 SimpleDate : SIMPLE.Date SimpleDateMap : MAP[ COMPOUND.Name, SIMPLE.Date ] | count 2 SimpleDateSet : SET[ SIMPLE.Date ] | count 2 SimpleDateList : LIST[ SIMPLE.Date ] | count 1 3 NameSetMap : MAP[ SIMPLE.Date, COMPOUND.NameSet ] | count 2 SimplePointerArray : ARRAY[ POINTER[ SIMPLE ] ] | !stored
Internationalization code generator
For those interested, I've open-sourced my localization code
generator here :
https://github.com/senselogic/LINGUI
It converts human-readable translation scripts into compilable
D/C# code.
For instance, this script :
Game
New_game
Welcome first_name last_name
Pears count
English : Game
New_game
"New game"
Welcome first_name last_name
"Welcome, "
first_name
" "
last_name
"!"
Pears count
*count
" "
if @count = one
"pear"
else
"pears"
German : Game
New_game
"Neues Spiel"
Welcome first_name last_name
"Willkommen, "
first_name
" "
last_name
"!"
Pears count
*count
" "
if @count = one
"Birne"
else
"Birnen"
French : Game
New_game
"Nouveau jeu"
Welcome first_name last_name
"Bienvenue, "
first_name
" "
last_name
" !"
Pears count
*count
" "
if @count = one
"poire"
else
"poires"
Can be used this way :
// -- IMPORTS
import std.stdio : writeln;
import ENGLISH_LANGUAGE_MODULE;
import FRENCH_LANGUAGE_MODULE;
import GAME_LANGUAGE_MODULE;
import GERMAN_LANGUAGE_MODULE;
import TRANSLATION_MODULE;
// -- FUNCTIONS
void Test(
GAME_LANGUAGE game_language
)
{
writeln( game_language.New_game() );
writeln( game_language.Welcome( TRANSLATION( "Jack" ),
TRANSLATION( "Sparrow" ) ) );
writeln( game_language.Pears( TRANSLATION( 0 ) ) );
writeln( game_language.Pears( TRANSLATION( 1 ) ) );
writeln( game_language.Pears( TRANSLATION( 2 ) ) );
}
// ~~
void main(
string[] argument_array
)
{
Test( new ENGLISH_LANGUAGE() );
Test( new GERMAN_LANGUAGE() );
Test( new FRENCH_LANGUAGE() );
}
Which will thus print :
New game
Welcome, Jack Sparrow!
0 pears
1 pear
2 pears
Neues Spiel
Willkommen, Jack Sparrow!
0 Birnen
1 Birne
2 Birnen
Nouveau jeu
Bienvenue, Jack Sparrow !
0 poire
1 poire
2 poires
I know there are other ways to do this, but for Unity games this
was what best matched my needs, especially performance-wise...
Prettify plugin for Geany
I've released a small open source plugin for Geany, which calls Prettify on the edited file. https://github.com/senselogic/GEANY_PRETTIFY It's mainly targeted for programmers like me who use Geany to develop in D, but it works also for other languages (C, C++, PHP, HTML, CSS, JS, etc). In the background, it simply creates a temporary file with the same file name and extension in /tmp/, calls Prettify on it, and then loads the prettified file.
Re: Prettify and Resync are now open source too
On Friday, 19 May 2017 at 22:46:07 UTC, aberba wrote: On Friday, 19 May 2017 at 16:22:36 UTC, Ecstatic Coder wrote: I have released a few other tools on Github under the GNU GPL, including : * Resync : a local folder synchronizer. * Prettify : a source code prettifier for D and other languages. https://github.com/senselogic I don't know if some of you will be interested in them, but here they are... Remote folder sync will be awesome for code back up Resync is optimized to do very fast backups on any local drive, including remote drives mounted as local drives. But of course there isn't any form of compression when copying files, like in Rsync.
Re: Prettify and Resync are now open source too
To see how the prettified looks like, the easiest way is to have a look at any D source code file on the SenseLogic github account (https://github.com/senselogic/). All of them have had their spacings, indentations and alignments automatically standardized by Prettify. Basically, it's just Allman style code with leading operators in hierarchical expressions and four spaces per level of indentation, so nothing fancy... Of course, the code style and readability are also a matter of taste, so it's up to you to decide if you think that the code has been prettified or "uglified" ;)
Re: Prettify and Resync are now open source too
On Saturday, 20 May 2017 at 15:38:04 UTC, Bastiaan Veelo wrote: On Friday, 19 May 2017 at 16:22:36 UTC, Ecstatic Coder wrote: * Prettify : a source code prettifier for D and other languages. Can you tell something about in what ways D code is prettified? How does it compare to dfmt? Thanks. The main difference is that it applies its own set of strict coding standard rules for PHP/HTML, JavaScript, CSS, C, C++ and D. So it's basically a multi-language alternative to dfmt, which presents the prettified code a little differently (spaces, indentations, alignments, etc).
Prettify and Resync are now open source too
I have released a few other tools on Github under the GNU GPL, including : * Resync : a local folder synchronizer. * Prettify : a source code prettifier for D and other languages. https://github.com/senselogic I don't know if some of you will be interested in them, but here they are...
Basil, Genesis, Patchup, Pendown and Pepss are now open source
I have released five of my internal tools on Github under the GNU GPL, not only in the hope that they are useful to others, but also to indirectly promote the D language, in which most of them are implemented. https://github.com/senselogic These tools are : * Basil, a textual database builder (D). * Genesis, a generic source code preprocessor (D). * Patchup, a scriptable source code patcher (D). * Pendown, a lightweight markup for colored documents (JS). * Pepss, a SCSS preprocessor (D). All of them are implemented as single file scripts without external dependencies, to be easily compilable.
