On Sunday, 15 October 2017 at 07:21:55 UTC, Ecstatic Coder wrote:
> But as a C++ developer, I can tell you that : D's GC is what prevents me to use it for my current C++ programming tasks.
>
> Because I can perfectly live with a GC that progressively collects bits of memory in a predefined amount of time, like in the Nim language, but not one that can pause my application for an unpredictable amount of time.
>
> That's just my personal case and opinion, but I don't think I'm the only C++ programmer on the planet to dislike D's GC for typical C++ development cases, which are generally those where the lack of a GC is the reason that lead to the use of C++.

Out of curiosity, what is it that stops you keeping the heap small and allocating memory manually for the rest?

On Friday, 6 October 2017 at 21:12:58 UTC, Rion wrote:

>
> Other aspects like being unsure when the GC will trigger can also influence people to a non-gc language. The Go developers have done a massive ( an impressive ) amount of work on trying to reduce GC pauses in the last two years, and that communication and effort has helped to reduce the GC myth ( for people looking at Go ).
>

How can GC issues be a myth if the Go developers did an impressive massive amount of work trying to reduced GC pauses?

On Sunday, 15 October 2017 at 16:29:22 UTC, Ecstatic Coder wrote:
>>> If all that is already available, perfect :)
>> [snip]
>>> And moreover I'd be delighted to start using D instead of Go for my next web server developments.
>>
>> You can start now and get performance later? In fact you may supply important benchmarks from your day to day usage.
>
> Ok. Still not convinced to use D instead of C++ for my personal use cases (games and other soft real-time apps), but I get the idea.

I switched my personal game to D from C++. Was easy, most of it was just copy paste. I was writing a math library to replace the one I was using to make it a bit more light way and to fit my needs a bit more. I didn't like how some thing were implemented in the library I was using. So I started with templates, I need multiple types and what not for the same purpose. At some point I have a function that needs to take 2 different template types.
It starts to get so convoluted, order matters cause C++ still just uses copy-paste-includes and I don't think modules made it into C++17. I wrote the same library in half the code, in a way that's more readable and manageable. I didn't have to define things so that they would work, I could define them logically the way I'd expect them to be. Mixins also reduced code quite a bit, generating functions for different types and dimensions. Even though you have constexpr if statements now you still need to define all the function bodies even if they all can go in one function body now.

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.

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

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

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;

On 10/15/17 13:40, Laeeth Isharc wrote:
> On Saturday, 14 October 2017 at 22:43:33 UTC, Adam Wilson wrote:
>> On 10/7/17 14:08, Laeeth Isharc wrote:
>
>>>
>>> In a polyglot environment, D's code generation and introspection
>>> abilities might be quite valuable if it allows you to write core
>>> building blocks once and call them from other languages without too much
>>> boilerplate and bloat.  One could use SWIG, but...
>>
>> Oh dear, I seem to have accidentally set off a firestorm.
>>
>> Personally, I think there are better places to focus our energy than
>> worrying about what the users of other languages think. We like D,
>> that should be enough for us. The last line was somewhat
>> tongue-in-cheek. There is no way we're going to convert C#/Java users
>> either, and unlike C/C++ we cannot easily inter-operate with them.
>
> If we can convert Pascal users, why won't some C# and Java programmers
> be receptive to D?  Plenty of people have approached D from Java:
>

Indeed. I am an example of just such a convert (from C#). :) But it is much more difficult to inter-operate. The easiest path that I can see is Micro-services. Hide your different languages behind a REST API, such that your components are not talking C#<->D anymore, but HTTP<->HTTP. Then the language matters a LOT less, then you can convert individual services to a new language whenever business needs dictate.

> https://dlang.org/blog/2017/09/06/the-evolution-of-the-accessors-library/
> https://dlang.org/blog/2017/08/11/on-tilix-and-d-an-interview-with-gerald-nunn/
>
> https://github.com/intellij-dlanguage/intellij-dlanguage/
> (Kingsley came from Java).
>
> Why can't we easily interop with Java and C#?  I didn't find interop
> with Java so bad for what I was doing (embedding a Java library via the
> JVM with callbacks to D code), and Andy Smith found similar.
>
> http://dconf.org/2015/talks/smith.pdf
> (towards the end)
>
> C# interop for what I am doing sees easy enough.  (I will generate C#
> wrappers for D structs and functions/methods).
>
> This work wasn't open-sourced, and nor did Microsoft send out a press
> release about their use of D in the COM team.  But I spoke to the author
> in Berlin (maybe you did too), and it wasn't so much work to make it
> useful:
>
> http://www.lunesu.com/uploads/ModernCOMProgramminginD.pdf
>

Very cool. I had no idea MSFT was doing that. I didn't talk to him, but I was fighting a bad cold at DConf this year. :( I avoided talking to a lot of people.

Even so, I was more commenting on the fact that D has built in support for inter-operating with C/C++. It's not that it's impossible to inter-operate with C#/Java/etc., but it is significantly more work. And that can be a significant barrier to conversion when the ecosystem they are coming from comfortably provides everything they need already. :)

>
>> Instead of worrying about how to get more people to come from a
>> specific language. People will come if they see an advantage in D so
>> lets try to provide as many advantages as possible. :)
>
> Yes - agree with this.
>


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

On 2017-10-15 18:29, Ecstatic Coder wrote:

> Can you just confirm that D's fibers use most of the available processors/cores by default ?

It depends entirely what you do with with the fibers. When it comes to vibe.d, it will only run on one core by default, last time I checked. Actually, I looked up the option for enabling multithreading for handling HTTP requests, it's now deprecated [1] and the recommendation is instead:

"If possible, instead of threads, the use of separate processes is more robust and often faster"

[1] http://vibed.org/api/vibe.http.server/HTTPServerOption.distribute

-- 
/Jacob Carlborg

>> Btw, when I say you can actually develop complete web servers in Dart and Go just with the components provided in the standard libraries, I really mean it, even if I personally also
>
> I programmed in Go.
> I also was part of Dart team for about a year.
> So yeah, I know what you mean.
>

Ok, then please can you explain why you say about web development libraries that "it’s not standard in Go and Dart", as you are probably the most informed person on that subject from the whole D community.

For instance, the web server behind my personal web site is EXCLUSIVELY based on Go's standard library, nothing else was used...

And moreover its code is incredibly concise and performant. Great job from Google engineering teams...

On 2017-10-16 07: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.

There are already drivers for MySQL (mysql-native) and PostgreSQL (ddb).

-- 
/Jacob Carlborg

On Monday, 16 October 2017 at 09:30:03 UTC, Jacob Carlborg wrote:
> On 2017-10-15 18:29, Ecstatic Coder wrote:
>
>> Can you just confirm that D's fibers use most of the available processors/cores by default ?
>
> It depends entirely what you do with with the fibers. When it comes to vibe.d, it will only run on one core by default, last time I checked. Actually, I looked up the option for enabling multithreading for handling HTTP requests, it's now deprecated [1] and the recommendation is instead:
>
> "If possible, instead of threads, the use of separate processes is more robust and often faster"
>
> [1] http://vibed.org/api/vibe.http.server/HTTPServerOption.distribute

Nowadays most web servers are multicore, so that's probably not very good to optimize their raw performance.