On Tuesday, 19 November 2019 at 17:23:46 UTC, bachmeier wrote:
> There's a bit of a sample selection issue. Anyone open to GC moved to Java long ago. These days anyone still using C++ either has a good reason to fear the GC (certain real-time applications) or an irrational fear of the GC.

It is not a question of fearing GC, but global collection is a rather blunt tool (compared to a scan-limited single-threaded collector, data-structure-local-collector or good ol' refcounting). Also, GC use twice as much memory or more, than carefully planned memory management.

> The D of today would have had great success at recruiting C++ programmers 20 years ago, but by about 2005 or so, Java had already sucked up all the potential converts.

I doubt Java had much effect on C++ programmers that gave D a shot, some C++ to D converts was absorbed back to C++ from D by C++11/C++14,  and Go and Rust absorbed some others...

Anyway, these days the picture is much more complex. Like how Kotlin is also aiming for the native compilation game with a LLVM backend... so with Kotlin being the default language on Android and Swift trying to become a thing on servers... well, that could skew things quite a bit for C++ programmers looking for managed languages.

On Tuesday, 19 November 2019 at 16:24:38 UTC, Steven Schveighoffer wrote:
> On 11/19/19 3:51 AM, Pavel Shkadzko wrote:
>> Sorry for "clickbaity" title but I believe it is discussion inducing.
>> 
>> This spring I started looking into D and trying it for some of the data analysis and scripting tasks. So, I am fairly new to the language and all its toolset (mainly using Python and Scala at work). I don't know C++. We do however have C++ engineers so I asked them around. I was quite surprised that none of them knew or even tried to use D. They of course heard about the language but that's it.
>> 
>> This Friday I also attended a PyTorch meetup in Munich at Microsoft where one of the core PyTorch developers (Adam Paszke) made a presentation about the future of this deep learning library. During presentation he mentioned that he played around with Hasktorch (a PyTorch inspired library in Haskell) to see how does PyTorch concepts go with functional style. When I approached him after the talk and asked if he ever thought of trying D for that purpose he looked surprised and confessed that he didn't know the language, heard about it yes but it never occurred to him to try and use it.
>
> I think it pretty much has to do with
> 1. what can I get my employer to accept as a language to use and
> 2. How easy is it to interface with my existing code base.
>
> I think the complaints about the GC are way overblown, they are the "Never" crowd. E.g. the ones who will never choose D for whatever reason. If you fix that reason, they'll find another one. Yes, I know there are certain places where the GC is no good for that domain (e.g. AAA games), but there are much more important problems to solve for those domains (i.e. atomics and lock-free message passing), and we do give tools to prevent GC usage (@nogc and betterC).
>
> But on my first point above, not many will accept D as a language to base their company on. The ones who do seem to have shined through with success stories (Sociomantic, Weka, Symmetry), but it's just less risky to use C++ in many minds.
>
> On the second point, we need to get to a place where via tools (dpp) or compiler adjustments (extern C++) we can interface NATIVELY with existing C++ code. One of the most important revelations from Atila, who is obviously a VERY pro-D person, is when he still picked C++ for a project at the company he worked for despite having sole discretion over whether to use D or not. He did it because all the code was already C and to do it in C++ means "I just can include the headers I need". For D, he would have to port much of those headers to D by hand.
>
> We are getting there. And honestly, I'm fine with D being it's own thing and not attracting huge swaths of C++ programmers. They'll figure it out eventually, and there is something to not chirping about how much better D is than C++ when sometimes the initial experience can be so negative on your expectations (stories I hear all the time from pro-D people who convinced coworkers to try out D).
>
> I think we are best off not lamenting about the lack of C++ immigrants.
>
> -Steve

Peter Thiel says competition is for losers.  It's a mistake to think that if one emerging language succeeds then another must fail.  Interviewing guys from a finance background they are much more receptive to D having done some Rust than being stuck in C# or python mindset.  The set of people that talk about programming and get the attention, that's only a particular slice of enterprise users and that world moves very slowly.

It's not like you hear much discussion about how D is stealing market share from Pascal and VBA (or even merely just from that functional programming language known as Excel).  But D will be replacing Pascal at Bastiaan's company and implicitly tools written in D are replacing VBA here.

I asked the boyfriend of a friend who was at Uber and Nvidia how they would tackle what we had done with SIL and he said too ambitious these days for Nvidia.  At Uber they would have put 20 reasonably senior engineers on it.

John was talking to a reasonably senior technical guy from a bank at a social event.  Smart chap who could anticipate the problems there would be.  It was out of his reality that we could do what we do,that there wasn't a large team working on it or that it didn't take many years.

We don't even have twenty programmers across all of Symmetry across all projects though we do have people who don't consider themselves programmers but write code.  And the initial development of SIL was essentially one person working on it at any one time in the first phase.

It might be bigger now but core SIL last I checked was 5k SLoC versus 20k for readline.

So you can do things that are like science fiction to others if you don't mind making different choices and paying the price for it - immense social pressure, tooling challenges and the like.  Most people shouldn't try to make that choice because their context isn't suitable for it.

Look at the budgets being spent on digital transformation.  I don't think the pool of programmers is going to stop growing just yet and I doubt people will become less interested in native code.

If C++ picks up more D features that's great because it's still C++ and a few of those who get used to things in C++ will thereby become a bit more receptive to using D and some will switch.

Yes c++ interop is important.  Dpp just keeps getting better and will handle more in time and for a zero overhead approach that or dstep for C is the best choice.

But, as is well known, C++ is an interpreted language that allows you to instantiate templates a runtime.  Okay, I am just kidding, but it can be true if you want it to be using cling from CERN.

It won't be that fast and for our purposes we used it in a way that is easy but will add more overhead.  However for lots of things just being able to call C++ libraries without manual work opens up a lot and later if it matters you can make it faster.  So we can call quite a lot of C++ from D using cling already and more will follow in time.  We will open source when ready.

It's not bad to be able to use c++ libraries from our little DSL.  And I have a proof of concept for c# though work has stalled - it's not difficult though.  Python will follow too and work Atila is doing on autowrap PyNIH will be useful.

I think it's not really helpful to worry about what others are doing - honourably steal ideas, sure.  But the most important thing is to do good work and make the language, library and ecosystem better.  If that keeps happening then adoption will follow.

You can't force adoption to go faster than what the ecosystem is ready for.  Very fast growth - you know that brings other kinds of challenges, believe me.

If D would bring commercial benefits at work but people you work with can't see it, then either you will have to try putting personal time into demonstrating the benefits like Ali, Bastiaan and I did; or you will need to recognise that your workplace runs on different principles.  It might well be easier to get a job writing D than to persuade your colleagues to switch.  We are hiring at least twenty people and we aren't the only ones hiring people to write D.  So there are choices.

On Tuesday, 19 November 2019 at 17:23:46 UTC, bachmeier wrote:
> On Tuesday, 19 November 2019 at 10:57:20 UTC, Russel Winder wrote:
>> On Tue, 2019-11-19 at 09:28 +0000, bachmeier via Digitalmars-d wrote:
>>> 
>> […]
>>> Unfortunately, D is not a better C++. Most notably, it has a GC, and much of the functionality of the standard library has historically required using the GC. Second, it doesn't work with legacy C++ code. That's changing, but it's a big issue.
>> […]
>>
>> That many C++ developers have an obsessive fear of the words garbage collector is clearly an issue, independent of whether GC is actually an issue for their codebases.
>
> There's a bit of a sample selection issue. Anyone open to GC moved to Java long ago. These days anyone still using C++ either has a good reason to fear the GC (certain real-time applications) or an irrational fear of the GC. The D of today would have had great success at recruiting C++ programmers 20 years ago, but by about 2005 or so, Java had already sucked up all the potential converts.

Look at the pace at which the pool of programmers is growing.  I'm not sure that some of the programmers I work with were even programming at all in 2005.  Myself, I wouldn't have picked up programming again if it had to be Java or C++ because life is too short.

I think it's a real mistake to conceive of life as being a zero-sum game.  In general, but particularly when the pool is growing.

Economic decisions are taken at the margin and the potential substitutes are not what one might think.  It might even be do a project in D or don't do it at all.

The contender can keep growing for a long time picking up new adoption from all kinds of different places.

Also in my experience if people keep insisting something is doomed and it just keeps growing it might be a bad idea to be too confident about that. From the very earliest days on Usenet people were naysaying the prospects of D.  Oh well.

The bigger challenges will come with continued adoption because that will change the nature of the people in the community which may require some adjustments.

On Wednesday, 20 November 2019 at 01:19:32 UTC, Laeeth Isharc wrote:
> [snip]
>
>
> It won't be that fast and for our purposes we used it in a way that is easy but will add more overhead.  However for lots of things just being able to call C++ libraries without manual work opens up a lot and later if it matters you can make it faster.  So we can call quite a lot of C++ from D using cling already and more will follow in time.  We will open source when ready.
>

Any additional details you can provide on this, I would find interesting. For instance, are you using a D interpreter and then Cling as the C++ interpreter to get the C++ code working in the interpreter? I wouldn't think you would need Cling if you're compiling ahead of time.

Also, I noticed jupyter-wire at the symmetryinvestments repository as a replacement for jupyterd. Is this meant to be infrastructure that some other tool will build on? Thanks.

On Tuesday, 19 November 2019 at 17:58:14 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 19 November 2019 at 17:23:46 UTC, bachmeier wrote:
>> There's a bit of a sample selection issue. Anyone open to GC moved to Java long ago. These days anyone still using C++ either has a good reason to fear the GC (certain real-time applications) or an irrational fear of the GC.
>
> It is not a question of fearing GC, but global collection is a rather blunt tool (compared to a scan-limited single-threaded collector, data-structure-local-collector or good ol' refcounting). Also, GC use twice as much memory or more, than carefully planned memory management.
>
>> The D of today would have had great success at recruiting C++ programmers 20 years ago, but by about 2005 or so, Java had already sucked up all the potential converts.
>
> I doubt Java had much effect on C++ programmers that gave D a shot, some C++ to D converts was absorbed back to C++ from D by C++11/C++14,  and Go and Rust absorbed some others...
>
> Anyway, these days the picture is much more complex. Like how Kotlin is also aiming for the native compilation game with a LLVM backend... so with Kotlin being the default language on Android and Swift trying to become a thing on servers... well, that could skew things quite a bit for C++ programmers looking for managed languages.

And .NET absorbed a couple more with its adoption by the games industry in tooling and some major engines.

Plus the Midori and Singularity learning that ended up in mainstream .NET, to the point that one can use .NET Native, .NET Core 3 and the upcoming .NET 5 for low level stuff that a couple of years ago C++ would be the only option in Windows.

And with Unity rewriting parts of their engine with their C# subset (Data-Oriented Tech Stack (DOTS)), having C# among game engines scripting capabilities is starting to be a must have on the feature list, even if it is constrained in some form.

Regarding UIs, in what concerns OS SDKs, C++ has already lost the crown it had on 90's systems, nowadays it is used for the composition engine/visual layer and respective drivers, with everything else done in some managed language, with the exception of Microsoft, due to UWP being basically COM 2.0 and they need to move those MFC/ATL devs to a stack they would accept.

Even Qt now has QML, with traditional C++ widgets being an option only on desktops. Qt 6 is supposed to open QML deployment scenarios back to pure C++ coding, lets see how it turns out.

Right now, D doesn't look like a viable solution to any of those scenarios as C++ replacement, hence the lack of interest.

On Wednesday, 20 November 2019 at 07:43:12 UTC, Paulo Pinto wrote:
> Plus the Midori and Singularity learning that ended up in mainstream .NET, to the point that one can use .NET Native, .NET Core 3 and the upcoming .NET 5 for low level stuff that a couple of years ago C++ would be the only option in Windows.

Is .NET Native available on other platforms than Windows?  Mono seems to perform less well...

> Regarding UIs, in what concerns OS SDKs, C++ has already lost the crown it had on 90's systems, nowadays it is used for the composition engine/visual layer and respective drivers, with everything else done in some managed language, with the

Not only managed, but UI-tweaking is better done in a language that doesn't require compilation, with hot reload (changes are visible in the running application without closing it first).

> Right now, D doesn't look like a viable solution to any of those scenarios as C++ replacement, hence the lack of interest.

IMO, right now there are too many similar-looking languages. Whoever stands out for some very specific use scenarios gain ground.

I found it a bit interesting that the Swift Server WG has 2 people from IBM on board, maybe they see it as an alternative to Java with lower memory footprint (no GC). I wish I knew why they think Swift would be a good solution on the server.

On Wednesday, 20 November 2019 at 09:44:54 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 20 November 2019 at 07:43:12 UTC, Paulo Pinto wrote:
>> Plus the Midori and Singularity learning that ended up in mainstream .NET, to the point that one can use .NET Native, .NET Core 3 and the upcoming .NET 5 for low level stuff that a couple of years ago C++ would be the only option in Windows.
>
> Is .NET Native available on other platforms than Windows?  Mono seems to perform less well...

No, but there are tons of devs that only care about a specific platform.

In what concerns AOT story in .NET, besides IL2CPP and Burst from Unity, there is also Xamarin AOT toolchain used for iOS/Android, and .NET 5 roadmap plans to replace .NET Native with Mono AOT implementation, so I imagine Microsoft is planning some improvements there.

>
>> Regarding UIs, in what concerns OS SDKs, C++ has already lost the crown it had on 90's systems, nowadays it is used for the composition engine/visual layer and respective drivers, with everything else done in some managed language, with the
>
> Not only managed, but UI-tweaking is better done in a language that doesn't require compilation, with hot reload (changes are visible in the running application without closing it first).
>
>> Right now, D doesn't look like a viable solution to any of those scenarios as C++ replacement, hence the lack of interest.
>
> IMO, right now there are too many similar-looking languages. Whoever stands out for some very specific use scenarios gain ground.
>
> I found it a bit interesting that the Swift Server WG has 2 people from IBM on board, maybe they see it as an alternative to Java with lower memory footprint (no GC). I wish I knew why they think Swift would be a good solution on the server.

IBM is responsible for one Swift server framework.

https://github.com/IBM-Swift/Kitura

Java will get value types (with experimental version already available), and IBM has their own JVM implementations as well, so I doubt that, just being present in all fronts I guess.

On Wednesday, 20 November 2019 at 01:19:32 UTC, Laeeth Isharc wrote:
>
> I think it's not really helpful to worry about what others are doing - honourably steal ideas, sure.  But the most important thing is to do good work and make the language, library and ecosystem better.  If that keeps happening then adoption will follow.
>

There are a lot of threads of these "why D isn't picking up", "D is dead" and so on. Why not enjoy programming in D instead of fearing the walls are going down any second.

I'm actually an example. It took 20 years for me to find D. I knew about its existence but there wasn't any real reason to switch from C++ to D. C++ did its job and it was proven technology. The reason I started to finally look into to D is that as time goes on you're expected to do more with less and that's where C++ starts to show its limits. Programs require more today, especially when it comes to communications, DB interactions. Complexity also seem to find its way down into smaller systems as well. Now it is not unusual that small embedded systems should talk to the world through the internet and access databases, both local and server. 10 years ago this was more unusual but it is quickly becoming standard.

Also 20 years ago C++ was less template heavy. You pretty much used C++ as an object oriented language and only touched templates when you needed generics. Today I see much more templates in C++ which reduces the readability a lot. Many programmers also want to show off their template skills but it doesn't help the aesthetics of the program. D has more verbose templates which was for me another reason I wanted to move from C++.

On Wednesday, 20 November 2019 at 12:20:45 UTC, IGotD- wrote:
> doesn't help the aesthetics of the program. D has more verbose templates which was for me another reason I wanted to move from C++.

I assume you meant that D has less verbose templates? Yes, that is an issue in C++, it is getting better, but still not great.

Did you move to D because of memory safety? Or was that a not a major issue for you in C++?

On Wednesday, 20 November 2019 at 12:27:49 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 20 November 2019 at 12:20:45 UTC, IGotD- wrote:
>> doesn't help the aesthetics of the program. D has more verbose templates which was for me another reason I wanted to move from C++.
>
> I assume you meant that D has less verbose templates? Yes, that is an issue in C++, it is getting better, but still not great.
>
> Did you move to D because of memory safety? Or was that a not a major issue for you in C++?

Yes, I made mistake, I meant that D has shorter and readable templates.

Memory safety is not a deal breaker but nice to have for example GC helps speeding up development as you get one less issue to think about but leaking programs are easy to debug. Bounds checking is the most important safety feature as these bugs can manifest themselves so differently and can be hard to find. C++ can find memory overwrites as well, for example MSVC put guards between variables on the stack an heap in debug mode. I would say ergonomics (ex. boiler plate code, library user friendliness) play just as big role as memory safety. The main reason I moved to D was that I found that the language was more productive.