On Friday, 18 October 2019 at 08:28:22 UTC, Petar Kirov [ZombineDev] wrote:
> I don't think that anybody has ever advertised Calypso as anything remotely production ready. Like any proof-concept/alpha software, it should be used only by people coming the mindset that they *will* hit many bugs and they're here to test the project, report the bugs and help its development. If you're not one of those people you should either wait for the project to become ready, or if it's important enough for you to help in some other way.
>

Thank you for that clarification. I distinctly remember some messages here that implied that Calypso is usable. I don't recall who said that.

>> Semi-OT, I would also like to see the automatic C++ header generation integrated into DMD/LDC/GDC. This would complement C++-to-D interop nicely. There's a pull request for this feature on github that is slowly getting stale. I don't know if it's merely being ignored or whether there are remaining issues with it.
>
> That's point 4. on my list. When it will be ready it would be part of all 3 compilers. As far as I know there's more work to be done and when the author has free time he will need to push forward before we can have his PR merged.

I was talking about https://github.com/dlang/dmd/pull/9971, which would include that feature in the DMD frontend.

Either way, the software stack I work with needs C++ at the uppermost layer that ties everything together. I could write individual libraries within the stack in D, but I don't want to maintain separate interface definitions manually. This is why I'm so interested int getting this feature. I don't care quite as much for having C++ interfaces usable from D, although that would be a big one. Most languages require a C wrapper around C++ which makes this stuff even more cumbersome to use. I don't want to bother with anything like this. I even consider the C++ header/implementation file split cumbersome and slow to work with.

On Friday, 18 October 2019 at 10:44:39 UTC, Chris wrote:
>
> Is it so hard to say why D is the best choice for you?

https://p0nce.github.io/d-idioms/#So-D-is-just-C++-with-a-Garbage-Collector?

But it's really:
https://p0nce.github.io/d-idioms/#How-does-D-improve-on-C++17?

that sell me D (the "small" stuff and readability).

It's an excellent combination of power and productivity that shines into the programs you do with it, and the user can notice it in the end.

Auto-decoding? Never had a single issue with it...
Breaking code? That happens, but rarely enough that I can live with it. And it happens less and less.

On Friday, 18 October 2019 at 11:07:15 UTC, Guillaume Piolat wrote:
> On Friday, 18 October 2019 at 10:44:39 UTC, Chris wrote:
>>
>> Is it so hard to say why D is the best choice for you?
>
> https://p0nce.github.io/d-idioms/#So-D-is-just-C++-with-a-Garbage-Collector?
>
> But it's really:
> https://p0nce.github.io/d-idioms/#How-does-D-improve-on-C++17?
>
> that sell me D (the "small" stuff and readability).
>
> It's an excellent combination of power and productivity that shines into the programs you do with it, and the user can notice it in the end.
>
> Auto-decoding? Never had a single issue with it...
> Breaking code? That happens, but rarely enough that I can live with it. And it happens less and less.

Point taken, yeah, D has great features, and how do you use it? Desktop / server only I suppose. How does it scale? Would you use D as other companies use Java and C++. I.e. when it stops being a one man show? Honest answer please.

On Friday, 18 October 2019 at 11:09:42 UTC, Chris wrote:
>
> Again, you are publicly calling for censorship.

Moderation.

> You never have any real points but you are engaging in a smear campaign against me and other critics. That's the typical behavior of an ideologue.

But you are the objective observer I guess.

Here is the thing: I think I have a better handle on actual D shortcomings than you.
Read the whole thing: https://p0nce.github.io/d-idioms/
Pretty critical at times.

I used to be in detailed trivia about D. Addiction for sure. I complained a lot about the language.

But something else I realized is that D cannot really fill three books of "Effective D", let alone one.

Things are actually quite good. Even compared to the "better" competition you mention all the time.

I look at reality: my D products cause me zero problems, make money, are as-fast-as-native can be, easy to maintain, and build faster than in similar languages (with the exception of Nim whose creator actually read the forum there, and is a competent alternative).

On Friday, 18 October 2019 at 11:15:55 UTC, Chris wrote:
>
> Point taken, yeah, D has great features, and how do you use it?

All the time, and avoiding recent features.


> Desktop / server only I suppose. How does it scale?

Hence the iOS effort.


> Would you use D as other companies use Java and C++.

I've used C++ in commercial capacity in 3 places. All had massive compile time problems, fragmentation, inability to add third-party code easily, and were massive debt machines.

I would never, ever start any effort in C++ as it's a sink of money compared to D. It's just much more expensive.

For small tools productivity can be 2x less with C++.

I think Java is fine when you don't use native. I don't use it, but friends are and it seems competent AND fixes long-time issues with C++ such as unsigned.

On Friday, 18 October 2019 at 11:24:38 UTC, Guillaume Piolat wrote:
> On Friday, 18 October 2019 at 11:15:55 UTC, Chris wrote:
>>
>> Point taken, yeah, D has great features, and how do you use it?
>
> All the time, and avoiding recent features.

Avoiding recent features? What does that mean? Which features and why?

>
>> Desktop / server only I suppose. How does it scale?
>
> Hence the iOS effort.

I couldn't wait anymore. Something so basic (not simple). That's when D comes back to bite you. Sad but true.

>> Would you use D as other companies use Java and C++.
>
> I've used C++ in commercial capacity in 3 places. All had massive compile time problems, fragmentation, inability to add third-party code easily, and were massive debt machines.

I believe that but isn't using D a big risk too? Where will it be tomorrow?

> I would never, ever start any effort in C++ as it's a sink of money compared to D. It's just much more expensive.

Ok, me neither. But how does D scale?

> For small tools productivity can be 2x less with C++.

> I think Java is fine when you don't use native. I don't use it, but friends are and it seems competent AND fixes long-time issues with C++ such as unsigned.

Java is way better than it used to be. Don't you think that D has missed (cf. iOS and Android) great opportunities because of too much feature frenzy and trying out CS stuff? Seriously, I think is has.

On Friday, 18 October 2019 at 11:24:38 UTC, Guillaume Piolat wrote:
> On Friday, 18 October 2019 at 11:15:55 UTC, Chris wrote:
>> [...]
>
> All the time, and avoiding recent features.
>
>
>> [...]
>
> Hence the iOS effort.
>
>
>> [...]
>
> I've used C++ in commercial capacity in 3 places. All had massive compile time problems, fragmentation, inability to add third-party code easily, and were massive debt machines.
>
> I would never, ever start any effort in C++ as it's a sink of money compared to D. It's just much more expensive.
>
> For small tools productivity can be 2x less with C++.
>
> I think Java is fine when you don't use native. I don't use it, but friends are and it seems competent AND fixes long-time issues with C++ such as unsigned.

"Don't feed the trolls!"

You don't have to prove anything to anyone, engaging in **any* argument* with such avatars is as dry as Atacama.

On Friday, 18 October 2019 at 12:05:41 UTC, Chris wrote:
> and once Adam said that he uses a very conservative style of D so he never has problems with dmd updates.

I have been kinda avoiding this thread as I don't wanna get burned but I wanna tell a funny little story here.

My libraries have a pretty good compatibility record. Yes, sometimes I push half-baked stuff and people get warnings or whatever, but I tend to fix those fairly quickly so 99% of the time you grab my code it is probably going to work on old and new compilers alike.

Many of my modules work with D versions going back two years or more. I actively test on gcc releases now too, and (in)famously avoid third-party library entanglements... again, for the most part.


But actually a lot of the stuff from the last year I like a lot. And cgi.d now uses static foreach in some optional sections. Pretty cool stuff.

The problem is it now doesn't work on old gdc :( And since version() requires the innards to parse, I can't even version it out. I might mix it in as a string (yikes!) just to maintain that cross-compiler compatibility, as often I'd just stick to the old feature but this time it is legitimately really useful and not easily replaced by an older way.

oh well though.

On Friday, 18 October 2019 at 11:24:38 UTC, Guillaume Piolat wrote:
> On Friday, 18 October 2019 at 11:15:55 UTC, Chris wrote:
>>
>> Point taken, yeah, D has great features, and how do you use it?
>
> All the time, and avoiding recent features.
>
>
>> Desktop / server only I suppose. How does it scale?
>
> Hence the iOS effort.
>
>
>> Would you use D as other companies use Java and C++.
>
> I've used C++ in commercial capacity in 3 places. All had massive compile time problems, fragmentation, inability to add third-party code easily, and were massive debt machines.
>
> I would never, ever start any effort in C++ as it's a sink of money compared to D. It's just much more expensive.
>
> For small tools productivity can be 2x less with C++.
>
> I think Java is fine when you don't use native. I don't use it, but friends are and it seems competent AND fixes long-time issues with C++ such as unsigned.

That's also my experience. Using C++ in a fairly high level projects involving interfacing to servers/cloud or any business application C++ is just a no go, at least for me. C++ has almost nothing out of the box, right now C++ doesn't even have its own socket library. Then you have search of 3rd party libraries which takes time and you really have to watch out when it comes to licenses which reduces the amount you can choose from. 3rd party libraries also varies a lot when it comes to quality. You have Boost which is quite good but when you include it will increase the compile times by a crazy amount.

Anything not low level, stay away from C++.

Java is better with good library support but suffers from high memory consumption. You cannot chuck several Java processes in a Linux system with only 512 - 1 GB of RAM because you will run out of memory very quickly. 1 - 4 java processes but then you're out.

D fills the spot between Java and C++. You can quickly code something in a working condition than C++ which is also more stable. Memory consumption wise I expect it also to be between C++ and Java. I would like to see a plug in referenced counted GC because that would decrease the memory consumption as well which is good for those small but many services you often see in systems today.

On Friday, 18 October 2019 at 11:36:45 UTC, Chris wrote:
>
> But how does D scale?
>

I'm glad you asked!
Your question is not very specific ("scales") but let's try.

D scales in terms of codebase size since the stdlib is rich already, build times are good and chances are will get better still.

D scales in terms of mental load because it has dependency management and SemVer (you can maintain a large amount of code with little breakage). Without DUB I couldn't hope to maintain so much code, SemVer lets you update things when you need them updated.

D scales to teams because it has builtin unittests, invariant, builtin heredoc (though, like C++, you will probably need to restrain some features).

D scales to newer platforms thanks to multiple backends, with very many platforms announced for GDC and iPhone and Webasm coming to LDC.