On Monday, 9 March 2020 at 10:21:16 UTC, Claude wrote:
> On Friday, 6 March 2020 at 15:27:27 UTC, IGotD- wrote:
>> I'm surprised C is still on second place. What can we do to kill it really?
>
> That does not surprise me, and I don't see C going anywhere in the foreseeable future.
>
> It's the common denominator between native languages like C++, D, Rust etc. And it interfaces with assembly-language. For system programming, it's the obvious language: easy to grasp and powerful. However, it's obviously not as expressive as like C++, that's true.
>
> For example, Vulkan API is written in C, and it's a beautiful API. If it had been written in C++ (or any other native language), it would have been probably more expressive, but it would have lost a lot in terms of efficiency.
>
> Another advantage of C is that, as it's a smaller language, it's easier to enforce a coherent coding-style for a community project.

A lot of languages also compiles to C before they implement compilation with ex. LLVM etc. because it's easier to do, faster to implement and supports mostly all platforms out of the box making it easy to test a language across platforms before you dive into compiling to machine code (because that's not easy to port.)

On Tuesday, 10 March 2020 at 04:14:33 UTC, SrMordred wrote:
> On Monday, 9 March 2020 at 12:27:34 UTC, FeepingCreature wrote:
>>[...]
>
>
> Thats really nice! Yeah, this kind of "no-effort-interop" is something that allow people to change languages but keep libs old codes to live on, therefore allowing them to keep working on the new language(increasing user retention). I feel that is a interesting thing for D to pursuit.
>
> Out of curiosity, are u working with D or are working/exploring other languages(or custom lang, maybe ) ?
>
> I feel that the closest thing of your D-lite language C interop that i know today is Zig.

https://github.com/atilaneves/dpp

On Tuesday, 10 March 2020 at 18:03:31 UTC, Atila Neves wrote:

> https://github.com/atilaneves/dpp

Hello Atila, i think u missed some part of the discussion where I cited dpp ;)

My point was that, although i love dpp project, it doenst feel part of the D lang.
Its an external project that first comers on the language will just not see, its not yet completly reliable (but work in most cases!),and have some external work to do: create a .dpp file, include the headers that what u, compile/generate binds. All this process feels external to the D language. And although u can make things works, these are little frictions that build up until people start to look for alternatives. (Zig is way more friendly in this area for example. People that are switching from C will find that Zig C interop is very pleasant in comparisson with D).

Its my opinion that if D want to grab a bigger portion of the "low level" market, it should focus on DPP development + seamlessly integration with the D and/or Dub + a better BetterC support.

On Wednesday, 11 March 2020 at 13:40:08 UTC, SrMordred wrote:
> My point was that, although i love dpp project, it doenst feel part of the D lang.

#include "foo.h" is close enough for me.

> Its an external project that first comers on the language will just not see, its not yet completly reliable (but work in most cases!),and have some external work to do: create a .dpp file, include the headers that what u, compile/generate binds.

Honestly, I don't see this as much of an issue, at least in what I've done with dpp. It would be nice if it worked out of the box, but I really don't see that as a big issue these days, more of a one-time minor inconvenience to get it set up.

> All this process feels external to the D language.

IMO, that's a good thing - C interop *is* external to the D language.

> And although u can make things works, these are little frictions that build up until people start to look for alternatives. (Zig is way more friendly in this area for example. People that are switching from C will find that Zig C interop is very pleasant in comparisson with D).

Zig includes a C compiler. That's convenient, but that's not the only relevant metric, and I'm not sure I see it as an advantage over outsourcing compilation to gcc or clang. I admit that I've only spent a little time with Zig, so maybe my impressions are not fully accurate.

On Wednesday, 11 March 2020 at 15:30:41 UTC, bachmeier wrote:
> On Wednesday, 11 March 2020 at 13:40:08 UTC, SrMordred wrote:
>> My point was that, although i love dpp project, it doenst feel part of the D lang.
>
> #include "foo.h" is close enough for me.
>
>> Its an external project that first comers on the language will just not see, its not yet completly reliable (but work in most cases!),and have some external work to do: create a .dpp file, include the headers that what u, compile/generate binds.
>
> Honestly, I don't see this as much of an issue, at least in what I've done with dpp. It would be nice if it worked out of the box, but I really don't see that as a big issue these days, more of a one-time minor inconvenience to get it set up.
>
>> All this process feels external to the D language.
>
> IMO, that's a good thing - C interop *is* external to the D language.
>
>> And although u can make things works, these are little frictions that build up until people start to look for alternatives. (Zig is way more friendly in this area for example. People that are switching from C will find that Zig C interop is very pleasant in comparisson with D).
>
> Zig includes a C compiler. That's convenient, but that's not the only relevant metric, and I'm not sure I see it as an advantage over outsourcing compilation to gcc or clang. I admit that I've only spent a little time with Zig, so maybe my impressions are not fully accurate.

Yeah, its not that is an "issue". I also use dpp, and most of the time it just works fine.
The point is that if u come from C/C++ world and u start to try another languages, smalls frictions can build up. Lets suppose they try D and Zig.

I think that if u came from C, D + betterC is amazing (is the reason why i´m using D now ), but u have an giant wall called garbage collector. Most people will dismiss D before even knowing about betterC, or ways to avoid gc.

Most people will not even know about DPP. Its not part of D, is just a project. (that´s what i meant by not being part of D).

Then they discover DPP, so lets try it: git clone, build, create dpp file (again, another thing that´s not really D) include the headers that i want, d++ ... to generate the binds ( lets ignore compilation ), include in my project. Nice, it works.

Now lets try Zig. Zig its already low level/no GC, so its looks better before really looking.
const c = @cImport({ @cInclude("header.h") });
zig run main.zig
Works. (again ignoring compilation of C parts, although Zig being better at it ).

Its hard to convince people that came from low level programming backgrounds to use D by comparison.

Again, I started this discussion responding the question : "I'm surprised C is still on second place. What can we do to kill it really?"

For me, D+betterC is a C killer. But D focus was never to be a C killer, although i think it have the potential to be.

On Wednesday, 11 March 2020 at 13:40:08 UTC, SrMordred wrote:
> On Tuesday, 10 March 2020 at 18:03:31 UTC, Atila Neves wrote:
>
>> https://github.com/atilaneves/dpp
>
> Hello Atila, i think u missed some part of the discussion where I cited dpp ;)

I most definitely did. Oops!