Re: Is Anything Holding you back?

[Kagamin via Digitalmars-d]

On Wednesday, 7 October 2015 at 16:09:37 UTC, Jan Johansson wrote:

Yepp, that's the point of SOA :-) We are in agreement.


:) Since the contract is known upfront, it can be processed at 
compile time and D can do it. C# has to do it at run time because 
it can't do a thing at compile time.

Re: Is Anything Holding you back?

[Kagamin via Digitalmars-d]

On Tuesday, 6 October 2015 at 16:38:06 UTC, Jan Johansson wrote:
I know about that too, the KnownType is applied to types that 
the DataContractSerializer (not the XmlSerializer) must be 
aware of before it can serialize the type (you enlist the type 
to the serializer). Thanks.


For a general purpose serialization it can make sense to support 
arbitrary types, but WCF is a communication technology that 
warrants contracts including and especially web-services that 
usually require full contract to be expressed in WSDL in order to 
be cross-platform.

Re: Is Anything Holding you back?

[Jonathan M Davis via Digitalmars-d]

On Wednesday, 7 October 2015 at 07:08:39 UTC, extrawurst wrote:
Method 1: Adding a static c'tor to every module does not work 
very long in practice (as experienced first handed) cause you 
are in "cyclic c'tor hell" very quick...


The cyclic dependency checking in druntime makes static 
constructors almost unusable. It's a case of being protected so 
much while trying to do something that you can't do what you're 
trying to do. There really should be some way IMHO to have 
something similar to @trusted where you tell the compiler/runtime 
that the order does not matter for a particular static 
constructor and that it should just trust the programmer on that, 
but Walter rejected the idea when it was brought up.


- Jonathan M Davis

Re: Is Anything Holding you back?

[extrawurst via Digitalmars-d]

On Monday, 5 October 2015 at 09:08:56 UTC, Jonas Drewsen wrote:

On Monday, 5 October 2015 at 06:18:45 UTC, Manu wrote:

[...]

[...]

The first method is bad because you need to mixin code manually 
for each module you have.


The second method is bad because you need to keep the 
"registration" file in sync with any modules 
added/renamed/removed.


[...]

/Jonas


Method 1: Adding a static c'tor to every module does not work 
very long in practice (as experienced first handed) cause you are 
in "cyclic c'tor hell" very quick...


--Stephan

Re: Is Anything Holding you back?

[Johannes Pfau via Digitalmars-d]

Am Wed, 07 Oct 2015 08:41:30 +
schrieb Jonathan M Davis :

> On Wednesday, 7 October 2015 at 07:08:39 UTC, extrawurst wrote:
> > Method 1: Adding a static c'tor to every module does not work 
> > very long in practice (as experienced first handed) cause you 
> > are in "cyclic c'tor hell" very quick...
> 
> The cyclic dependency checking in druntime makes static 
> constructors almost unusable. It's a case of being protected so 
> much while trying to do something that you can't do what you're 
> trying to do. There really should be some way IMHO to have 
> something similar to @trusted where you tell the compiler/runtime 
> that the order does not matter for a particular static 
> constructor and that it should just trust the programmer on that, 
> but Walter rejected the idea when it was brought up.
> 
> - Jonathan M Davis

With LDC you can abuse the C constructor mechanism to do that. GDC does
not yet expose C constructors to D code but it's on my list and it's
easy to implement.

Re: Is Anything Holding you back?

[Jonathan M Davis via Digitalmars-d]

On Wednesday, 7 October 2015 at 10:03:11 UTC, Johannes Pfau wrote:

Am Wed, 07 Oct 2015 08:41:30 +
schrieb Jonathan M Davis :


On Wednesday, 7 October 2015 at 07:08:39 UTC, extrawurst wrote:
> Method 1: Adding a static c'tor to every module does not 
> work very long in practice (as experienced first handed) 
> cause you are in "cyclic c'tor hell" very quick...


The cyclic dependency checking in druntime makes static 
constructors almost unusable. It's a case of being protected 
so much while trying to do something that you can't do what 
you're trying to do. There really should be some way IMHO to 
have something similar to @trusted where you tell the 
compiler/runtime that the order does not matter for a 
particular static constructor and that it should just trust 
the programmer on that, but Walter rejected the idea when it 
was brought up.


- Jonathan M Davis


With LDC you can abuse the C constructor mechanism to do that. 
GDC does not yet expose C constructors to D code but it's on my 
list and it's easy to implement.


I'm not quite sure what you mean by C constructors, so I don't 
know how that works, but unless it's in all of the compilers, I 
don't think that it's really worth much ultimately. And we _do_ 
have workarounds already. std.stdio is an example of one such 
module where what is essentially its static constructor is called 
by another module in order to break the cycle. But then you lose 
out on the special benefits of static constructors with regards 
to initializing stuff like immutable objects, which can be a 
problem - particularly when stuff like pure gets involved.


Honestly, I think that if we don't want it to be considered 
borderline bad practice to use static constructors, I think that 
we need a solution for this that allows them to function normally 
without being concerned about circular dependencies (at least 
when the programmer marks them as such). And if the C constructor 
mechanism that you're talking about somehow does that, then 
great, but it needs to be standard D, or it's a pretty limited 
solution.


- Jonathan M Davis

Re: Is Anything Holding you back?

[Johannes Pfau via Digitalmars-d]

Am Wed, 07 Oct 2015 10:50:38 +
schrieb Jonathan M Davis :

> On Wednesday, 7 October 2015 at 10:03:11 UTC, Johannes Pfau wrote:
> > Am Wed, 07 Oct 2015 08:41:30 +
> > schrieb Jonathan M Davis :
> >
> >> On Wednesday, 7 October 2015 at 07:08:39 UTC, extrawurst wrote:
> >> > Method 1: Adding a static c'tor to every module does not 
> >> > work very long in practice (as experienced first handed) 
> >> > cause you are in "cyclic c'tor hell" very quick...
> >> 
> >> The cyclic dependency checking in druntime makes static 
> >> constructors almost unusable. It's a case of being protected 
> >> so much while trying to do something that you can't do what 
> >> you're trying to do. There really should be some way IMHO to 
> >> have something similar to @trusted where you tell the 
> >> compiler/runtime that the order does not matter for a 
> >> particular static constructor and that it should just trust 
> >> the programmer on that, but Walter rejected the idea when it 
> >> was brought up.
> >> 
> >> - Jonathan M Davis
> >
> > With LDC you can abuse the C constructor mechanism to do that. 
> > GDC does not yet expose C constructors to D code but it's on my 
> > list and it's easy to implement.
> 
> I'm not quite sure what you mean by C constructors, so I don't 
> know how that works, but unless it's in all of the compilers, I 
> don't think that it's really worth much ultimately. 

Most C compilers support some __attribute(constructor)__ feature.
In LDC this translates to something like this:

import ldc.attribute;

@attribute("constructor") extern(C) void myConstructor()
{
}

and GDC will use basically the same syntax. It's not really meant for
end users though. We can use this to implement some parts of
the druntime shared DSO handling. And it's useful for betterC programs
or embedded systems, as the implementation in the (C) runtime is very
simple. But you're right, this is probably not a good / general purpose
solution. It just wanted to point out that there's another possible
workaround ;-)

> And we _do_ 
> have workarounds already. std.stdio is an example of one such 
> module where what is essentially its static constructor is called 
> by another module in order to break the cycle. But then you lose 
> out on the special benefits of static constructors with regards 
> to initializing stuff like immutable objects, which can be a 
> problem - particularly when stuff like pure gets involved.
> 
> Honestly, I think that if we don't want it to be considered 
> borderline bad practice to use static constructors, I think that 
> we need a solution for this that allows them to function normally 
> without being concerned about circular dependencies (at least 
> when the programmer marks them as such).

I think it wouldn't be hard to implement a solution. I guess it's
mainly a political discussion :-(

An UDA which can be placed on functions with certain signatures would
be nice. And this allows having multiple static ctors per module
(Could be useful for constructors in mixins):

@constructor void myConstructor() //compiler enforces function signature
{
}

> And if the C constructor 
> mechanism that you're talking about somehow does that, then 
> great, but it needs to be standard D, or it's a pretty limited 
> solution.

If we can have a standard solution in DMD there are better ways than
relying on C constructors. The druntime has absolutely no control over
'C constructors' (they're called by the C runtime) which can lead to
problems in some corner cases. C constructors are mainly useful for low
level or embedded code. And they're useful as long as we don't have a
standard solution, as GDC/LDC can implement them without DMDs
approval ;-)

Re: Is Anything Holding you back?

[Jonathan M Davis via Digitalmars-d]

On Wednesday, 7 October 2015 at 14:59:37 UTC, Johannes Pfau wrote:
I think it wouldn't be hard to implement a solution. I guess 
it's mainly a political discussion :-(


It should be fairly easy to implement a solution - especially if 
it's simply marking the static constructor to say that it doesn't 
depend on any other module's static constructor having run 
(obviously, it gets far more complicated if you try and make it 
so that the programmer indicates which modules it doesn't depend 
on in order to have other cyclic dependencies caught if they 
creep into the code). druntime just needs to know that the order 
of that static constructor doesn't matter with regards to the 
others when it's deciding the order to run them in. I expect that 
actually making the change to druntime would be pretty simple.


The core problem is definitely that Walter objects to the idea 
(IIRC on the grounds that it's too easy for circular dependencies 
to creep in later and then not be caught). If he agreed to it, it 
could probably be implemented fairly quickly.


- Jonathan M Davis

Re: Is Anything Holding you back?

[Jan Johansson via Digitalmars-d]

On Wednesday, 7 October 2015 at 08:27:18 UTC, Kagamin wrote:

On Tuesday, 6 October 2015 at 16:38:06 UTC, Jan Johansson wrote:
I know about that too, the KnownType is applied to types that 
the DataContractSerializer (not the XmlSerializer) must be 
aware of before it can serialize the type (you enlist the type 
to the serializer). Thanks.


For a general purpose serialization it can make sense to 
support arbitrary types, but WCF is a communication technology 
that warrants contracts including and especially web-services 
that usually require full contract to be expressed in WSDL in 
order to be cross-platform.


Yepp, that's the point of SOA :-) We are in agreement.

Re: Is Anything Holding you back?

[Jonathan M Davis via Digitalmars-d]

On Tuesday, 6 October 2015 at 13:31:25 UTC, krzaq wrote:
For example: you can't rely on Clock.currTime.toString() (or 
ISO string overloads) to provide a reliable fixed-length 
representation for logging purposes and the class mysteriously 
lacks any kind of .format() function that's available pretty 
much everywhere else.


The ISO standard doesn't really say what to do with the number of 
decimal places, and it's usually cleanest to not have a bunch of 
trailing zeroes, which is why the to*String functions are the way 
they are. I was thinking about adding a way to tell it the number 
of digits though, since std.experimental.logger had to deal with 
that. It's not something that's generally come up though. I 
really should have gotten the custom formatting done before now, 
but it is on the todo list. For most stuff though, it's best to 
just use toISOExtString, since it's a standard format and quite 
legible (unlike straight ISO - I don't know why they even have 
the ISO format in addition to the extended ISO format; it's 
pretty much impossible to read).


- Jonathan M Davis

Re: Is Anything Holding you back?

[Kagamin via Digitalmars-d]

On Monday, 5 October 2015 at 16:40:06 UTC, Jan Johansson wrote:
Yes, I know WCF more than well, doing my own bindings, 
federated security bindings, you name it. I also know that WCF 
works with attribute values during runtime, through reflections 
and extract aspect oriented instructions on how to treat types. 
It would be slick to do the same in D.


Yes, but that's only because C# doesn't support DbI, it also 
doesn't mean WCF accepts arbitrary types in contracts: 
http://stackoverflow.com/questions/7444851/why-knowntypeattribute-need-in-wcf

Re: Is Anything Holding you back?

[krzaq via Digitalmars-d]

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 major for me, just a plentitude of small problems.

For example: you can't rely on Clock.currTime.toString() (or ISO 
string overloads) to provide a reliable fixed-length 
representation for logging purposes and the class mysteriously 
lacks any kind of .format() function that's available pretty much 
everywhere else.


When I decide to write a small tool in D, I pretty ensure that, 
next to D's awesome features, I'll be exposed to some ugly warts 
of the language or its ecosystem. My experience with DUB packages 
(btw, there should be a word for it, like Ruby's gems) is that, 
at least on Windows, they are often out of date and require 
undocumented build steps to even build -- and that's before you 
try to use them and hit the wall of RTFS solutions to 
documentation.


TL;DR: instead of focusing on solving my problem, I have to focus 
on solving problems unknown in other languages. Saving time by 
using fantastic language features and then wasting twice as much 
reinventing the wheel is not what I want to do.

Re: Is Anything Holding you back?

[Jan Johansson via Digitalmars-d]

On Tuesday, 6 October 2015 at 14:28:42 UTC, Kagamin wrote:

On Monday, 5 October 2015 at 16:40:06 UTC, Jan Johansson wrote:
Yes, I know WCF more than well, doing my own bindings, 
federated security bindings, you name it. I also know that WCF 
works with attribute values during runtime, through 
reflections and extract aspect oriented instructions on how to 
treat types. It would be slick to do the same in D.


Yes, but that's only because C# doesn't support DbI, it also 
doesn't mean WCF accepts arbitrary types in contracts: 
http://stackoverflow.com/questions/7444851/why-knowntypeattribute-need-in-wcf


I know about that too, the KnownType is applied to types that the 
DataContractSerializer (not the XmlSerializer) must be aware of 
before it can serialize the type (you enlist the type to the 
serializer). Thanks.

Re: Is Anything Holding you back?

[Manu via Digitalmars-d]

On 5 October 2015 at 14:02, Jan Johansson via Digitalmars-d
 wrote:
> On Sunday, 4 October 2015 at 23:55:42 UTC, Manu wrote:
>>
>> On 5 October 2015 at 03:44, Jan Johansson via Digitalmars-d
>>  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.
>>>
>>>
>>>
>>> I'd wish for attributes to be runtime available, not only compiler
>>> directives. It could then be used for a number of interesting use cases, as
>>> marshaling from and to different formats rather than through API. The
>>> attributes could then be supported by libraries.
>>
>>
>> Anything compile time can be made available at runtime if your system
>> calls for it.
>
>
> Sure it can, but I want a dynamic behavior, not a static behavior.
> Attributes are compiler directives. They are not available at runtime
> according to the specification of D language. Now take the example at:
> http://ddili.org/ders/d.en/uda.html, and separate the code into one library
> that defines the attributes and "printAsXML", keep the consumer of the
> attributes (main function) and get the same slick functionality. It can't be
> done, because UDA is not runtime available.

You can easily make attributes effectively available at runtime by
building lists of attributed things at compile time.
I don't understand your problem. Describe the goal?

I was one of the main guys involved in the introduction of UDA's, and
I have managed to use them successfully for most of my needs.

Re: Is Anything Holding you back?

[Kagamin via Digitalmars-d]

On Monday, 5 October 2015 at 04:02:58 UTC, Jan Johansson wrote:
Sure it can, but I want a dynamic behavior, not a static 
behavior. Attributes are compiler directives. They are not 
available at runtime according to the specification of D 
language. Now take the example at: 
http://ddili.org/ders/d.en/uda.html, and separate the code into 
one library that defines the attributes and "printAsXML", keep 
the consumer of the attributes (main function) and get the same 
slick functionality. It can't be done, because UDA is not 
runtime available.


printAsXML is templated on the input type and hence can access 
all its attributes at compile time. If you're familiar with WCF, 
you should know that all types going through a data contract are 
known at compile time.

Re: Is Anything Holding you back?

[Jonas Drewsen via Digitalmars-d]

On Monday, 5 October 2015 at 06:18:45 UTC, Manu wrote:
You can easily make attributes effectively available at runtime 
by

building lists of attributed things at compile time.
I don't understand your problem. Describe the goal?


This is all nice but still not as slick as could be. Say a want 
to have a central place to lookup all classes with the Foo() 
attribute on it. The classes can be in several files of course so 
there are two ways of registering them at compile time to be 
available for runtime lookups:


1, Add a static module contructor to each module that registers 
the Foo() attribut'ed classes. This constructor is probably 
generated at compile time and mixed into the module as a 
one-liner.


2, Add a "registration" module that imports all other modules in 
order to filter out Foo() attributed classes and register them 
for runtime usage.


The first method is bad because you need to mixin code manually 
for each module you have.


The second method is bad because you need to keep the 
"registration" file in sync with any modules 
added/renamed/removed.


A couple of months ago I was working on an extension to the 
string import() feature of D: It would simply treat a import(*) 
as returning the directory listing of the imports path. From that 
the list of .d file could be figured out and imported at compile 
time. Then the the runtime information could be extracted at 
compile time with no fuzz.


/Jonas

Re: Is Anything Holding you back?

[Jonas Drewsen via Digitalmars-d]

On Monday, 5 October 2015 at 13:38:43 UTC, Adam D. Ruppe wrote:

On Monday, 5 October 2015 at 09:08:56 UTC, Jonas Drewsen wrote:
Say a want to have a central place to lookup all classes with 
the Foo() attribute on it.


You can also use the RTInfo hook in druntime's object.d to 
build that stuff in a central location.


Of course, since that's a centralized file, it can at best be 
changed on a per-project basis...


And it wouldn't work if you want to put your app on e.g. 
code.dlang.org for others to compile using their standard 
druntime. Furthermore RTInfo seems kind of reserved for GC atm.


There's also only RTInfo for types, not functions and 
variables, but still, it'd work for the case of building a list 
of classes.


Types goes a long way for sure. Personally I need both types and 
functions.

Re: Is Anything Holding you back?

[Adam D. Ruppe via Digitalmars-d]

On Monday, 5 October 2015 at 09:08:56 UTC, Jonas Drewsen wrote:
Say a want to have a central place to lookup all classes with 
the Foo() attribute on it.


You can also use the RTInfo hook in druntime's object.d to build 
that stuff in a central location.


Of course, since that's a centralized file, it can at best be 
changed on a per-project basis...


There's also only RTInfo for types, not functions and variables, 
but still, it'd work for the case of building a list of classes.

Re: Is Anything Holding you back?

[Jan Johansson via Digitalmars-d]

On Monday, 5 October 2015 at 08:44:03 UTC, Kagamin wrote:

On Monday, 5 October 2015 at 04:02:58 UTC, Jan Johansson wrote:
Sure it can, but I want a dynamic behavior, not a static 
behavior. Attributes are compiler directives. They are not 
available at runtime according to the specification of D 
language. Now take the example at: 
http://ddili.org/ders/d.en/uda.html, and separate the code 
into one library that defines the attributes and "printAsXML", 
keep the consumer of the attributes (main function) and get 
the same slick functionality. It can't be done, because UDA is 
not runtime available.


printAsXML is templated on the input type and hence can access 
all its attributes at compile time. If you're familiar with 
WCF, you should know that all types going through a data 
contract are known at compile time.


Yes, I know WCF more than well, doing my own bindings, federated 
security bindings, you name it. I also know that WCF works with 
attribute values during runtime, through reflections and extract 
aspect oriented instructions on how to treat types. It would be 
slick to do the same in D.

Re: Is Anything Holding you back?

[Jan Johansson via Digitalmars-d]

On Monday, 5 October 2015 at 09:08:56 UTC, Jonas Drewsen wrote:

On Monday, 5 October 2015 at 06:18:45 UTC, Manu wrote:

[...]


This is all nice but still not as slick as could be. Say a want 
to have a central place to lookup all classes with the Foo() 
attribute on it. The classes can be in several files of course 
so there are two ways of registering them at compile time to be 
available for runtime lookups:


[...]


Thanks Jonas, for your very good input.

Re: Is Anything Holding you back?

[Jan Johansson via Digitalmars-d]

On Sunday, 4 October 2015 at 23:55:42 UTC, Manu wrote:
On 5 October 2015 at 03:44, Jan Johansson via Digitalmars-d 
 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.



I'd wish for attributes to be runtime available, not only 
compiler directives. It could then be used for a number of 
interesting use cases, as marshaling from and to different 
formats rather than through API. The attributes could then be 
supported by libraries.


Anything compile time can be made available at runtime if your 
system calls for it.


Sure it can, but I want a dynamic behavior, not a static 
behavior. Attributes are compiler directives. They are not 
available at runtime according to the specification of D 
language. Now take the example at: 
http://ddili.org/ders/d.en/uda.html, and separate the code into 
one library that defines the attributes and "printAsXML", keep 
the consumer of the attributes (main function) and get the same 
slick functionality. It can't be done, because UDA is not runtime 
available.

Re: Is Anything Holding you back?

[bitwise via Digitalmars-d]

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.


OpenCV would be nice.

I use it a lot at work, and every now and then I want to make a 
small testbed just to try something out. It would be nice to be 
able to use D for this.


It seems odd no one has ported it yet since... "D is for Data 
Science" :)


Bit

Re: Is Anything Holding you back?

[bitwise via Digitalmars-d]

On Sunday, 4 October 2015 at 17:39:26 UTC, bitwise 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.


OpenCV would be nice.

I use it a lot at work, and every now and then I want to make a 
small testbed just to try something out. It would be nice to be 
able to use D for this.


It seems odd no one has ported it yet since... "D is for Data 
Science" :)


Bit


I should add that it would be even nicer to be able to use it for 
production code, but we target iOS.


Bit

Re: Is Anything Holding you back?

[Jan Johansson via Digitalmars-d]

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'd wish for attributes to be runtime available, not only 
compiler directives. It could then be used for a number of 
interesting use cases, as marshaling from and to different 
formats rather than through API. The attributes could then be 
supported by libraries.

Re: Is Anything Holding you back?

[Manu via Digitalmars-d]

On 5 October 2015 at 03:44, Jan Johansson via Digitalmars-d
 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.
>
>
> I'd wish for attributes to be runtime available, not only compiler
> directives. It could then be used for a number of interesting use cases, as
> marshaling from and to different formats rather than through API. The
> attributes could then be supported by libraries.

Anything compile time can be made available at runtime if your system
calls for it.

Re: Is Anything Holding you back?

[ponce via Digitalmars-d]

On Friday, 2 October 2015 at 18:56:32 UTC, deadalnix 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.


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).


On OSX I've used lldb + LDC and stack traces and line numbers are 
there.

Symbols are not demangled though.

Re: Is Anything Holding you back?

[karabuta via Digitalmars-d]

On Friday, 2 October 2015 at 05:28:23 UTC, suliman wrote:

On Friday, 2 October 2015 at 05:15:26 UTC, luminousone 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.




and GUI lib with simple GUI builder


That is what I want to hear.

Re: Is Anything Holding you back?

[deadalnix via Digitalmars-d]

On Saturday, 3 October 2015 at 09:02:52 UTC, ponce wrote:

On Friday, 2 October 2015 at 18:56:32 UTC, deadalnix 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.


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).


On OSX I've used lldb + LDC and stack traces and line numbers 
are there.

Symbols are not demangled though.


LDC is not an option for me ATM as only the latest DMD is 
supported.

Re: Is Anything Holding you back?

[Manu via Digitalmars-d]

On 2 October 2015 at 12:25, Yaser via Digitalmars-d
 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.

Emscripten, Qt, and to a lesser extent, NaCl.

Re: Is Anything Holding you back?

[crimaniak via Digitalmars-d]

Full-featured PDF library (with JBIG2 and Jpeg2000 support and so 
on...)

Re: Is Anything Holding you back?

[Jonathan M Davis via Digitalmars-d]

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

Re: Is Anything Holding you back?

[Dmitry Olshansky via Digitalmars-d]

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

Re: Is Anything Holding you back?

[Chris via Digitalmars-d]

On Friday, 2 October 2015 at 03:34:18 UTC, Adam D. Ruppe wrote:

Moreover, and this is really important, D can already interact 
the majority of existing software out there.


This is a very important point that is often forgotten. What has 
been done in C is also available to D. To work with D you don't 
need to have everything written in D. If that was the case, no 
new language could ever be used, because it's impossible to catch 
up with the wealth of libraries that already exist in C/C++.


And through C you can communicate with other languages too, 
Python, Lua etc. Look at PyD and LuaD for example or the 
DerelictD stuff.


One caveat though: if your software is GUI-centered, research the 
possibilities in D. If you wanna go mobile (ARM), check carefully 
what can be done already and what can't.

Re: Is Anything Holding you back?

[Jack Stouffer via Digitalmars-d]

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.

Re: Is Anything Holding you back?

[Andrei Alexandrescu via Digitalmars-d]

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

Re: Is Anything Holding you back?

[Andrei Alexandrescu via Digitalmars-d]

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

Re: Is Anything Holding you back?

[Sönke Ludwig via Digitalmars-d]

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=library.database

Re: Is Anything Holding you back?

[Kagamin via Digitalmars-d]

On Friday, 2 October 2015 at 08:23:56 UTC, Sönke Ludwig wrote:

http://code.dlang.org/?sort=name=library.database


Unfortunately not everybody is using sqlite and postgresql.

Re: Is Anything Holding you back?

[ponce via Digitalmars-d]

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'd say kickass codegen from DMD but it seems it's getting 
improvements.


Nothing held me back :) Now writing D full-time.

Re: Is Anything Holding you back?

[Kagamin via Digitalmars-d]

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

Re: Is Anything Holding you back?

[Atila Neves via Digitalmars-d]

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.


Sadly, the preprocessor, and it just happened to me today. In 
C++, I include the header and I'm done. In D, I have to either 
manually duplicate the C declarations or use dstep. I'm more than 
ok with the latter option, but my environment is weird (doesn't 
use the system libc) and dstep didn't work. Doing it manually 
would be so much work that I gave up for this project in 
particular.


Mostly I write everything in D these days though.

Atila

Re: Is Anything Holding you back?

[Márcio Martins via Digitalmars-d]

On Friday, 2 October 2015 at 09:44:00 UTC, ponce 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.


I'd say kickass codegen from DMD but it seems it's getting 
improvements.


Nothing held me back :) Now writing D full-time.


That, and the very poor debugging experience.

Our web company is also 100% D, minus a few javascript and css 
tools that we currently use node.js for.

Re: Is Anything Holding you back?

[deadalnix via Digitalmars-d]

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.

Re: Is Anything Holding you back?

[luminousone via Digitalmars-d]

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=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.

Re: Is Anything Holding you back?

[Wyatt via Digitalmars-d]

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

Re: Is Anything Holding you back?

[Jan Johansson via Digitalmars-d]

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.

Re: Is Anything Holding you back?

[Jonathan M Davis via Digitalmars-d]

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

Re: Is Anything Holding you back?

[deadalnix via Digitalmars-d]

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).

Re: Is Anything Holding you back?

[Timon Gehr via Digitalmars-d]

On 10/02/2015 03:24 PM, 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.


It slows it down. The most annoying part of it is that it introduces 
clashes with private aliases introduced for disambiguation. I.e., the 
mechanism that most conveniently deals with ambiguous symbols is 
basically defunct because of spurious ambiguous symbol errors.

Re: Is Anything Holding you back?

[Adam D. Ruppe via Digitalmars-d]

On Friday, 2 October 2015 at 18:56:32 UTC, deadalnix wrote:
don't even have line number in the trace that lead to this 
assert (the dogshit).


http://arsdnet.net/this-week-in-d/sep-20.html

https://github.com/D-Programming-Language/druntime/pull/1354

works on linux now, already worked on Windows, provided you had 
the debughelp libs installed from Microsoft.


idk about Mac though.

Re: Is Anything Holding you back?

[Adam D. Ruppe via Digitalmars-d]

On Friday, 2 October 2015 at 19:17:24 UTC, deadalnix wrote:

Do I need to use specific linker flags to have this work ?


--export-dynamic if you want function names (now done by default 
in dmd.conf anyway) and -g if you want file and line numbers; it 
pulls the info from the debug information.

Re: Is Anything Holding you back?

[deadalnix via Digitalmars-d]

On Friday, 2 October 2015 at 19:12:08 UTC, Adam D. Ruppe wrote:

On Friday, 2 October 2015 at 18:56:32 UTC, deadalnix wrote:
don't even have line number in the trace that lead to this 
assert (the dogshit).


http://arsdnet.net/this-week-in-d/sep-20.html

https://github.com/D-Programming-Language/druntime/pull/1354

works on linux now, already worked on Windows, provided you had 
the debughelp libs installed from Microsoft.


idk about Mac though.


Do I need to use specific linker flags to have this work ?

Also, that's AWESOME !

Re: Is Anything Holding you back?

[Daniel Kozak via Digitalmars-d]

Yaser píše v Pá 02. 10. 2015 v 02:31 +:
> On Friday, 2 October 2015 at 02:29:47 UTC, Adam D. Ruppe 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?
> > 
> > Nope, if anything like that comes up, I'll just write it myself!
> 
> That's the attitude, but do you think you can rewrite 10+ years * 
> X man hours of software by yourself

There is no need to use 10+ years * X man hours sw. You can just write
what you actually need, nothing more nothing less.

Re: Is Anything Holding you back?

[Kagamin via Digitalmars-d]

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.

Re: Is Anything Holding you back?

[Dmitry Olshansky via Digitalmars-d]

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

--
Dmitry Olshansky

Re: Is Anything Holding you back?

[Yaser via Digitalmars-d]

On Friday, 2 October 2015 at 02:52:23 UTC, David DeWitt wrote:
Im sure he meant if he needs something thats not yet available 
then he'll just write it.  D is a community effort so obviously 
many ppl need to chip in.  I pretty much use the usual 
Python/JS combo professionally and there are a ton of battle 
tested libraries and frameworks but innovation always brings 
new techniques and libraries that eventually replace old stuff.
 If the attitude was "well Java has X and countless others" 
then none of the newer languages would every get build.  Look 
at how React has pretty much taken over (well at least for me) 
that is new and so is the countless community driven projects 
evolving around React.


[...]


I knew what he meant, just the attitude of some OSS Devs can be 
asinine

Is Anything Holding you back?

[Yaser via Digitalmars-d]

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.

Re: Is Anything Holding you back?

[Adam D. Ruppe via Digitalmars-d]

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?


Nope, if anything like that comes up, I'll just write it myself!

Re: Is Anything Holding you back?

[David DeWitt via Digitalmars-d]

On Friday, 2 October 2015 at 02:31:50 UTC, Yaser wrote:

On Friday, 2 October 2015 at 02:29:47 UTC, Adam D. Ruppe 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?


Nope, if anything like that comes up, I'll just write it 
myself!


That's the attitude, but do you think you can rewrite 10+ years 
* X man hours of software by yourself


Im sure he meant if he needs something thats not yet available 
then he'll just write it.  D is a community effort so obviously 
many ppl need to chip in.  I pretty much use the usual Python/JS 
combo professionally and there are a ton of battle tested 
libraries and frameworks but innovation always brings new 
techniques and libraries that eventually replace old stuff.  If 
the attitude was "well Java has X and countless others" then none 
of the newer languages would every get build.  Look at how React 
has pretty much taken over (well at least for me) that is new and 
so is the countless community driven projects evolving around 
React.


Like anything D does need more things like better Database 
support, web frameworks, etc but it will get there. Who knows in 
a couple years maybe you will be doing everything in D.

Re: Is Anything Holding you back?

[Yaser via Digitalmars-d]

On Friday, 2 October 2015 at 02:29:47 UTC, Adam D. Ruppe 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?


Nope, if anything like that comes up, I'll just write it myself!


That's the attitude, but do you think you can rewrite 10+ years * 
X man hours of software by yourself

Re: Is Anything Holding you back?

[Adam D. Ruppe via Digitalmars-d]

On Friday, 2 October 2015 at 02:31:50 UTC, Yaser wrote:
That's the attitude, but do you think you can rewrite 10+ years 
* X man hours of software by yourself


It doesn't actually take that long to write useful programs. (and 
btw, I've been writing D for 8+ years already, including a lot of 
support libs for my programs over that time.)



Moreover, and this is really important, D can already interact 
the majority of existing software out there. For example, when I 
needed crypto functions in D, I didn't rewrite it. I just 
copy/pasted a few function prototypes from a C library and called 
them.


When I needed to access a mysql database, I didn't rewrite the 
database. I didn't even implement the communication protocol 
(though that isn't really *that* hard either), I just called the 
official mysql C functions.


Those alone are enough to start doing real work after just a few 
hours of setup, and you can build up the rest from there as 
needed.


IMO part of fully investing in something is spending the time to 
adapt what it has to your needs and filling in the rest of the 
gaps as more needs come up.

Re: Is Anything Holding you back?

[suliman via Digitalmars-d]

On Friday, 2 October 2015 at 05:15:26 UTC, luminousone 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.


vibe.d compatible sqlite, postgresql, and oracle sql drivers. 
dub support in visualD/mono-d, better container libraries in 
the standard library(granted this is coming now that the 
allocator library is just about here).


derelictGL has issues with AMD cards(issues that are AMD's 
fault granted) that has caused me to have to maintain a fork 
with a few things commented out.


I would kill for golang channel like types supported in the 
standard library.


other then some database support missing from vibe.d nothing 
really holds me back, just annoyances really.


and GUI lib with simple GUI builder

Re: Is Anything Holding you back?

[luminousone via Digitalmars-d]

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.


vibe.d compatible sqlite, postgresql, and oracle sql drivers. dub 
support in visualD/mono-d, better container libraries in the 
standard library(granted this is coming now that the allocator 
library is just about here).


derelictGL has issues with AMD cards(issues that are AMD's fault 
granted) that has caused me to have to maintain a fork with a few 
things commented out.


I would kill for golang channel like types supported in the 
standard library.


other then some database support missing from vibe.d nothing 
really holds me back, just annoyances really.