Dear D users,


after a long time evaluating all options I think I finally committed to D and vibe.d! Since I’ll have a lot of memory usage and I want to do an MMORPG I always was scared off by GC-enabled languages, but after thoroughly evaluating what this language (and vibe.d) gives me in terms of performance, memory usage (this is especially important, a lot of GC-languages like Java have unacceptable memory bloat for objects etc.) and productivity I think this is the best decision. Obviously I’ll have some work to do later to move most of the objects out of the GC (they usually live from the start of the server to the end of the server) but I now thinks that this work is still a lot less then all the other work combined. I especially like the built-in contract programming, invariants and unit-tests and I think they’ll be worth a lot! And even more awesome is the compile-time reflection for serialization (very important for my projects).

So, what I actually wanted to ask, which part/project do you think mostly needs contribution? The D documentation on this page? Mono-D (I’ll be using that, already contributed to an issue)? DUB? vibe.d and its documentation? More tutorials on a seperate blog?

Please tell me what you think! :-)


rgds, Kira Backes

On Thursday, 9 January 2014 at 07:45:09 UTC, Kira Backes wrote:
> Dear D users,
>
>
> after a long time evaluating all options I think I finally committed to D and vibe.d! Since I’ll have a lot of memory usage and I want to do an MMORPG I always was scared off by GC-enabled languages, but after thoroughly evaluating what this language (and vibe.d) gives me in terms of performance, memory usage (this is especially important, a lot of GC-languages like Java have unacceptable memory bloat for objects etc.) and productivity I think this is the best decision. Obviously I’ll have some work to do later to move most of the objects out of the GC (they usually live from the start of the server to the end of the server) but I now thinks that this work is still a lot less then all the other work combined. I especially like the built-in contract programming, invariants and unit-tests and I think they’ll be worth a lot! And even more awesome is the compile-time reflection for serialization (very important for my projects).
>
> So, what I actually wanted to ask, which part/project do you think mostly needs contribution? The D documentation on this page? Mono-D (I’ll be using that, already contributed to an issue)? DUB? vibe.d and its documentation? More tutorials on a seperate blog?
>
> Please tell me what you think! :-)
>
>
> rgds, Kira Backes

Hi and welcome here,
It's hard to tell what is most important. I feel that these days dub is an enabling project that deserves some help.

On Thursday, 9 January 2014 at 07:45:09 UTC, Kira Backes wrote:
> Dear D users,
>
>
> after a long time evaluating all options I think I finally committed to D and vibe.d! Since I’ll have a lot of memory usage and I want to do an MMORPG I always was scared off by GC-enabled languages, but after thoroughly evaluating what this language (and vibe.d) gives me in terms of performance, memory usage (this is especially important, a lot of GC-languages like Java have unacceptable memory bloat for objects etc.) and productivity I think this is the best decision. Obviously I’ll have some work to do later to move most of the objects out of the GC (they usually live from the start of the server to the end of the server) but I now thinks that this work is still a lot less then all the other work combined. I especially like the built-in contract programming, invariants and unit-tests and I think they’ll be worth a lot! And even more awesome is the compile-time reflection for serialization (very important for my projects).
>
> So, what I actually wanted to ask, which part/project do you think mostly needs contribution? The D documentation on this page? Mono-D (I’ll be using that, already contributed to an issue)? DUB? vibe.d and its documentation? More tutorials on a seperate blog?
>
> Please tell me what you think! :-)
>
>
> rgds, Kira Backes

A good web service stack is the main thing for Vibe I believe.
Because of this I started Cmsed (I'll push it into repo soon) a component library that also functions as a content management system. I also built and still working on an ORM (Dvorm [0]).
I need OpenDBX support for e.g. Mysql added to it. I have bindings to it available. Mongo already supported.

There is also standards like odata I wish to support with my router natively. For this I need some sort of relationship system within Dvorm.

I strongly believe some sort of GWT [1] inspired system is also required to work alongside a router. I did have this planned for DOOGLE [2] but since talk about a new gui base system, there's little point in me continuing it.

But from a practical side. We need articles showing good examples of simple code to do awesome stuff.
Benchmarks on memory/cpu usage ext. Also very important.

At the end of day, choose what you're good at and love. It'll help no matter what it is :)

[0] https://github.com/rikkimax/Dvorm
[1] http://www.gwtproject.org/
[2] https://github.com/rikkimax/DOOGLE

On 2014-01-09 08:45, Kira Backes wrote:
> Dear D users,
>
>
> after a long time evaluating all options I think I finally committed to
> D and vibe.d! Since I’ll have a lot of memory usage and I want to do an
> MMORPG I always was scared off by GC-enabled languages, but after
> thoroughly evaluating what this language (and vibe.d) gives me in terms
> of performance, memory usage (this is especially important, a lot of
> GC-languages like Java have unacceptable memory bloat for objects etc.)
> and productivity I think this is the best decision. Obviously I’ll have
> some work to do later to move most of the objects out of the GC (they
> usually live from the start of the server to the end of the server) but
> I now thinks that this work is still a lot less then all the other work
> combined. I especially like the built-in contract programming,
> invariants and unit-tests and I think they’ll be worth a lot! And even
> more awesome is the compile-time reflection for serialization (very
> important for my projects).
>
> So, what I actually wanted to ask, which part/project do you think
> mostly needs contribution? The D documentation on this page? Mono-D
> (I’ll be using that, already contributed to an issue)? DUB? vibe.d and
> its documentation? More tutorials on a seperate blog?

We could use some help with all of those. It's hard to choose.

-- 
/Jacob Carlborg

Added to github.
Not ready yet for dub repository addition as I haven't finished with the base subpackage yet.

I want odata to be added before then. Maybe something else is required. I'll see. Shouldn't be long though.

[0] https://github.com/rikkimax/Cmsed

On Thursday, 9 January 2014 at 07:45:09 UTC, Kira Backes wrote:
> Please tell me what you think! :-)

1. If you already have some code, you could refactor some of it into libraries and publish them via Dub aka code.dlang.org.

2. Using Dub, Phobos, DMD-betas, etc you probably find bugs. You can actively search for them by testing your code with each new beta release. You should report them. Ideally, you even fix them and submit pull requests.

3. Blog about your experience with D. Announce it here, on Hacker News, Reddit, etc.

4. Talk about D (commenting on reddit etc). Tell people about D. Give presentations at conferences (DConf 2014!), user groups, etc.

On 1/8/14 11:45 PM, Kira Backes wrote:
> So, what I actually wanted to ask, which part/project do you think
> mostly needs contribution? The D documentation on this page? Mono-D
> (I’ll be using that, already contributed to an issue)? DUB? vibe.d and
> its documentation? More tutorials on a seperate blog?
>
> Please tell me what you think! :-)

Welcome aboard! You are already doing something that D needs, which is establishing a track record of successful applications.

Other things I often here about are: (a) availability of libraries for anything and everything, e.g. database- and networking-related stuff; (b) distribution of such, i.e. http://code.dlang.org and dub.

Experience reports (blogs, articles) on use of D are also great to have. Documentation updates are welcome at all levels.


Cheers,

Andrei

On Thursday, 9 January 2014 at 07:45:09 UTC, Kira Backes wrote:
> So, what I actually wanted to ask, which part/project do you think mostly needs contribution?

Hello,

Given the low frequency of issue reports on some projects, I've definitely noticed a new face in the D ecosystem. I've thought about this problem a little bit as well.

> The D documentation on this page?

For the most part, I've been satisfied with D documentation on the official website. My only general gripe is that there are many outdated pages – sometimes to the point of irrelevance. This can confuse people, given it is on the official website and not marked as outdated. For example: http://dlang.org/safed.html confused me the other day. I did not know it had evolved into @safe.

> Mono-D (I’ll be using that, already contributed to an issue)?

Mono-D is by far my favorite IDE for D. It is cross-platform, free as in speech/beer, and supports DUB package files. Unfortunately, there are a lot of unreported issues or non-reproducable issues which tends to happen when a development team is small. I believe Mono-D and D_Parser are written in C# and not D though. One thing that may be possible and worth doing in the future is using DCD (mentioned later) with Mono-D and combining efforts. Though that is more of a major undertaking.

> DUB?

Sönke is moving along pretty quickly with DUB. I would say having a well fleshed out tutorial or more examples could do it well though.

> More tutorials on a seperate blog?

A lot of D language tutorials and informational resources pander to C++ programmers. I think that we should be more focused on attracting new users or perhaps people who tend to use interpreted languages. See: http://www.rustforrubyists.com/. A lot of people would like a more performant, statically checked, compiled language. D is expressive enough to intersect with a lot of the use cases of a scripting language.

And to expand a bit on my previous post with things I personally thing are important and rather low hanging:

- Create style and layout templates for ddox to help us non-designers
- Make DCD plugins for editors so they can autocomplete, go to definition, etc.
- Create idiomatic D wrappers around deimos/derelict or any other direct C bindings

But most of all, the D ecosystem simply needs users who are willing to generate activity in the form of:
- Usage of D libraries
- Willingness to file issues and follow up on them should a problem arise
- Release of software built using D
- Discussion within (mailing list, IRC) and beyond (reddit, HN) the D community
- Documenting your experiences and creating said discussion
- Openness to test drive prospective "big players" in the environment

To expand on that last point: I mean using things like DUB, ddox, Mono-D or Pegged early on if possible. This makes them viable that much faster, and we need an ecosystem that makes it simple for a new user to come in and set up a project.

Regards,
Kelet

On Thu, Jan 09, 2014 at 11:59:10PM +0000, Kelet wrote:
> And to expand a bit on my previous post with things I personally thing are important and rather low hanging:
> 
> - Create style and layout templates for ddox to help us non-designers
> - Make DCD plugins for editors so they can autocomplete, go to
>   definition, etc.
> - Create idiomatic D wrappers around deimos/derelict or any other
>   direct C bindings
> 
> But most of all, the D ecosystem simply needs users who are willing
> to generate activity in the form of:
> - Usage of D libraries
> - Willingness to file issues and follow up on them should a problem
>   arise
> - Release of software built using D
> - Discussion within (mailing list, IRC) and beyond (reddit, HN) the D
>   community
> - Documenting your experiences and creating said discussion
> - Openness to test drive prospective "big players" in the environment
[...]

You forgot the most important one: browse the bugtracker at http://d.puremagic.com/issues for easy-to-fix Phobos bugs and submit pull requests for them.  You don't have to be an "official" Phobos dev to do that (I'm not, and I've had a good number of pulls merged already).

Or browse the Phobos pull request list on github and help review pull requests (we're very short of people on that front -- arguably this is more important than submitting pulls, since a lot of pulls are stagnating because nobody got around to reviewing them yet).

Phobos code is actually quite pleasant to read in spite of it being the D standard library (for the most part anyway, Phobos does have its dark corners but you need not go there). If you've ever tried reading the source of, say, glibc, you'll know what I mean. Plus, reading Phobos code will also teach you some powerful D idioms that you may not otherwise think of. So you'll be learning "effective D" while helping to improve the quality of its standard library. Double win!


T

-- 
Music critic: "That's an imitation fugue!"