On 02-Oct-2015 05:25, Yaser wrote:
> Are there any critical frameworks or libraries that are holding you back
> in fully investing in D? Obviously I think D is an awesome language, but
> some frameworks/libraries hold me back, wish I could do everything in D.

My personal favorite (8+ years old OMG):
https://issues.dlang.org/show_bug.cgi?id=1238

Makes me want to laugh every time we discuss "problems" of D. Bugs are as usual at the top of problems in my book.

And couple more from the miserable line of basic encapsulation not working:

https://issues.dlang.org/show_bug.cgi?id=314
https://issues.dlang.org/show_bug.cgi?id=463

And there is even more to dig up.

-- 
Dmitry Olshansky

On 10/02/2015 08:54 AM, Jack Stouffer wrote:
> On Friday, 2 October 2015 at 02:25:21 UTC, Yaser wrote:
>> Are there any critical frameworks or libraries that are holding you
>> back in fully investing in D? Obviously I think D is an awesome
>> language, but some frameworks/libraries hold me back, wish I could do
>> everything in D.
>
> Yes: https://issues.dlang.org/show_bug.cgi?id=14927

Do we have an attack on this problem? -- Andrei

On 10/02/2015 09:11 AM, Dmitry Olshansky wrote:
> On 02-Oct-2015 05:25, Yaser wrote:
>> Are there any critical frameworks or libraries that are holding you back
>> in fully investing in D? Obviously I think D is an awesome language, but
>> some frameworks/libraries hold me back, wish I could do everything in D.
>
> My personal favorite (8+ years old OMG):
> https://issues.dlang.org/show_bug.cgi?id=1238
>
> Makes me want to laugh every time we discuss "problems" of D. Bugs are
> as usual at the top of problems in my book.

I agree it's a hole in the module system, but it's not quite something that prevents work from being done.

> And couple more from the miserable line of basic encapsulation not working:
>
> https://issues.dlang.org/show_bug.cgi?id=314
> https://issues.dlang.org/show_bug.cgi?id=463

These seem in the same category. Not to say they aren't important.


Andrei

On Friday, 2 October 2015 at 13:24:10 UTC, Andrei Alexandrescu wrote:
> On 10/02/2015 09:11 AM, Dmitry Olshansky wrote:
>> On 02-Oct-2015 05:25, Yaser wrote:
>>> Are there any critical frameworks or libraries that are holding you back
>>> in fully investing in D? Obviously I think D is an awesome language, but
>>> some frameworks/libraries hold me back, wish I could do everything in D.
>>
>> My personal favorite (8+ years old OMG):
>> https://issues.dlang.org/show_bug.cgi?id=1238
>>
>> Makes me want to laugh every time we discuss "problems" of D. Bugs are
>> as usual at the top of problems in my book.
>
> I agree it's a hole in the module system, but it's not quite something that prevents work from being done.
>
>> And couple more from the miserable line of basic encapsulation not working:
>>
>> https://issues.dlang.org/show_bug.cgi?id=314
>> https://issues.dlang.org/show_bug.cgi?id=463
>
> These seem in the same category. Not to say they aren't important.

Yeah. They do make it much easier to break other code when you make changes (including making changes in something like Phobos), but mostly, they don't prevent work getting done. They are pretty embarrassing though.

- Jonathan M Davis

On Friday, 2 October 2015 at 08:23:56 UTC, Sönke Ludwig wrote:
> Am 02.10.2015 um 10:15 schrieb Kagamin:
>> On Friday, 2 October 2015 at 08:03:03 UTC, Dmitry Olshansky wrote:
>>> On 02-Oct-2015 10:49, Kagamin wrote:
>>>> On Friday, 2 October 2015 at 05:15:26 UTC, luminousone wrote:
>>>>> vibe.d compatible sqlite, postgresql, and oracle sql drivers.
>>>>
>>>> An ODBC driver would be fine too, anything that can connect to a
>>>> database.
>>>
>>> http://dlang.org/phobos/etc_c_odbc_sql.html
>>
>> http://wiki.dlang.org/Libraries_and_Frameworks#Databases
>
> http://code.dlang.org/?sort=name&category=library.database

Looks like an async postgresql driver is in their, but i don't see sqlite supported in this fashion yet. I would love to use vibe.d(we currently use java/tomcat with spring framework) in some of the projects at work, but most of this would require connecting to an oracle server, I will re-examine the pgsql situation.

We have several projects coming up where we will get a dataset from the Utah department of environmental quality and we will build a small website around it for the public to query and look at the data in a user friendly fashion. Assuming pgsql support is up to snuff, I can get away with using vibe.d. And I believe anyway that I could finish the project faster with vibe.d then java/tomcat/spring.

On Friday, 2 October 2015 at 02:25:21 UTC, Yaser wrote:
> Are there any critical frameworks or libraries that are holding you back in fully investing in D? Obviously I think D is an awesome language, but some frameworks/libraries hold me back, wish I could do everything in D.

Nothing is holding me back from using D on my personal projects. At this point, all of them are in D. The primary thing that I'm lacking is time to work on them.

Now, using D at work is another thing entirely, but that has more to do with there being existing codebases and it being very difficult to talk coworkers into using a new language or technology than there necessarily being any technical issues.

Sure, there are some things that would be easier to do if they were written in D or if we had better wrappers for existing C++ stuff (e.g. it would be great to be able to fully use Qt from D), but because it's trivial to call C functions, and even interacting with C++ is possible on some level, it's not really a blocker when something isn't in D - just annoying.

- Jonathan M Davis

On Friday, 2 October 2015 at 02:25:21 UTC, Yaser wrote:
> Are there any critical frameworks or libraries that are holding you back in fully investing in D? Obviously I think D is an awesome language, but some frameworks/libraries hold me back, wish I could do everything in D.

I want a really good communication stack, doing SOAP (no - I don't want the dry old 'JSON' is best, 'SOAP' is bad argument - I got enough reasons to use SOAP in many solutions) and the one really good stack I've seen so far on SOAP is WCF.

It would be a dream to be able to define service contracts and data contracts in a smooth and slick way in D, but maybe it's too heavy. It took MS about 5 years to create.

On Friday, 2 October 2015 at 12:54:30 UTC, Jack Stouffer wrote:
> On Friday, 2 October 2015 at 02:25:21 UTC, Yaser wrote:
>> Are there any critical frameworks or libraries that are holding you back in fully investing in D? Obviously I think D is an awesome language, but some frameworks/libraries hold me back, wish I could do everything in D.
>
> Yes: https://issues.dlang.org/show_bug.cgi?id=14927
>
> This is honestly embarrassing for me when ever I mention D to someone.

This, and debug support in general. I have no idea how to get line number for stack traces on OSX, let alone run GDB or LLDB, but even on linux where the support is better, I need to use a specific set of linker flag + use command lines tools to get line number from stack traces.

On Friday, 2 October 2015 at 17:17:07 UTC, Jonathan M Davis wrote:
>
> Now, using D at work is another thing entirely, but that has more to do with there being existing codebases and it being very difficult to talk coworkers into using a new language or technology than there necessarily being any technical issues.
>
Same boat here, only with the added pain that most of our current stuff is a terrifying tower of Java trash.  I'm not even sure what could be done to ease this situation.

-Wyatt

On Friday, 2 October 2015 at 02:25:21 UTC, Yaser wrote:
> Are there any critical frameworks or libraries that are holding you back in fully investing in D? Obviously I think D is an awesome language, but some frameworks/libraries hold me back, wish I could do everything in D.

1/ Debug support. It is truly bad. Does not work on OSX as far as I know how, and works tediously on linux (line numbers are often wrong in GDB and do not appear ins tack trace, need to use specific linkers flags for this to work at all).

2/ Null reference types. Seriously. Everything is null by default, you get an error where the pointer is used, not where the problem is (and these 2 points can be fairly remote) and, associated with 1) , hard to track. 99% of the time, the thing is null due to a stupid mistake and the compiler could have catched it.

3/ Templates error messages. Especially when you pass closures as alias and the compiler decide to dump them with fucked up indentation all in the middle of the error message. Probably good for these that enjoy Klingon opera, but my taste differs.

4/ There used to be a fair amount of codegen bugs in closures, but these seems mostly fixed at this stage. However, there is still a lot of weirdness going on with them. Symbol in enclosing scope will be resolved, but not alias this for instance. Sometime, the closure will refuse to capture something for unknown reasons and one need to rely on ugly hacks.

5/ mixins are not hygienic. It is often not possible to get the symbols you are interested in at the site where they are going to be resolved. For instance (toy example, but I have various real world example of this in my code) :

module a;

struct S {}

import b;
MixinFail!S mf;

module b;

struct MixinFail(T) {
    mixin(T.stringof ~ " t;");
}

This limitation, forces me jump through all kind of hoops, or make various part of phobos unusable at even moderate scale (the problem in already big in SDC, which is a bit more than 40 kLOC at this stage).

6/ This is not a specific problem, but the general attitude that consist in taking care of details without looking at the big picture. Or to quote a coworker about "One will take great care in a bakery to put presents cackes and sweets nicely, sell them in a pretty box to customers, but do not care that there is a dogshit on the pavement at the entrance".

The recent assert message thread is a good example of that. 6 pages in 2 days about how to best analyze the expression in the assert to get a better error messages (the nice box), when we don't even have line number in the trace that lead to this assert (the dogshit).