D on quora ...

[Adam Wilson]

On 10/15/17 22:20, Dmitry Olshansky wrote:
> On Sunday, 15 October 2017 at 20:24:02 UTC, Adam Wilson wrote:
>>>> database access (MySQL, PostgreSQL, Aerospike) libraries are available,
>>>
>>> That is important actually.
>>>
>>
>> So important that it should be a Priority 0 Must Have.
>
> Luckily it should also be quite strightforward to write them. At minimum
> there would be a C, Go, Java and Python “driver” to look at.
>
> Also surprisingly, D has superior driver for MySQL that talks native
> binary protocol while most other languages use the text mode.
>

The most important SQL DB's all have high quality C libraries. Why not 
leverage those? I don't understand the obsession with having everything 
written in native D. To be bluntly honest, I find the VisualD suffers 
greatly from not being written as a C# MEF component (Visual Studio's 
plugin system). There is no demonstrable advantage to writing an IDE 
plugin in D (as opposed to using the native language of the IDE) other 
than proving that it can be done.

Also, I would caution that MSFT is working *very* hard to retire the COM 
based plugin system for Visual Studio (here is the direction they are 
heading: https://github.com/dotnet/project-system). Honestly we could 
probably knock together an integrated D plugin based on Common Project 
System fairly quickly, but we'd have to do it in C#. Technically you 
could write a P/Invoke wrapper out to D, but ... why?

>>>> preferably as a standard library (like in Dart and Go).
>>>
>>> Can’t do that. And it’s not standard in Go and Dart but packages, dub
>>> should work for that.
>>>
>>
>> I've been thinking about this question a LOT, and I'm not convinced
>> it's impossible to put the DB libs into the standard
>
> Problem is - the development of std has glacial pace. Even if you put
> say Aerospike in std, I don’t think it’s in our best interest to have
> stagnated DB libs. DBs add features and ship new versions all the time.
>
> What might work is JDBC style approach - having a common interface in
> std with implementations in 3rd party. SQL might work this way.
>

I've been (slowly) working on exactly this. I started with a concept 
loosely based on ADO.NET but lately it's more D idiomatic than that.

Also, because SQL is what it is (a text based query language) it would 
actually be possible to include reference implementations of the major 
DB vendors for the common interface. (MySQL, PgSQL, etc.)

> NoSQL though is highly irregular and benefits primarily from features
> unique to a particular vendor.
>

Completely agree. However, some types of NoSQL DB's could be hidden 
behind generic interfaces, for example key-value stores.

-- 
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;