On Tuesday, 20 June 2017 at 05:19:21 UTC, Cym13 wrote:
> The issue with that is that you assume:
>
> 1) that a complete libc replacement can be created from scratch
> 2) that a correct libc replacement can be created from scratch
> 3) that a better libc replacement can be created from scratch
> 4) that this replacement can be maintained for years to come on all plateforms

For things like core.stdc it would be insane not to depend on libc. In fact, it would be strange if we did not call into libc, here.

But does this really mean that depending on libc must be the default for everyone?

I doubt that we would have to replace every function provided by libc. We only have to provide alternatives for what we use. Other than that I share your scepsis.

I am not saying that we should actually drop the dependency. I was just curious to learn something.

On Mon, 2017-06-19 at 22:41 +0000, Honey via Digitalmars-d-learn wrote:
> 
[…]
> I heard that Go's standard library is based on a similar approach.
> 
> Not depending on libc at all might serve as a marketing instrument as well.

But there is lots of paid resource in the core Go community which makes not using "middleware" feasible by providing your own. Also of course the Go/C interface is not as clean as is the case in D, so the need for Go-specific middleware is much, much higher. As D can call C linkage libraries, and libc is a library for interfacing to OSes, use it, get the abstraction, pay the (small) price, get someone else to do the maintenance.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Monday, 19 June 2017 at 21:45:56 UTC, Moritz Maxeiner wrote:
> On Monday, 19 June 2017 at 21:35:56 UTC, Steven Schveighoffer wrote:
>> IIRC, Tango did not depend on libc at all. It only used system calls. So it certainly is possible.
>
> How did they invoke those system calls? They are usually access via libc on POSIX systems, so you don't have to implement accessing e.g. vdso on Linux yourself.

Tango just didn't use C abstractions (`FILE*`, say), but rather it would call functions such `read(2)`, `write(2)`, `seek(2)`, etc. and implement buffering/seeking/etc manually. So, the library just declared `extern (C) read (...);`/`extern (C) write`.. and expected for the right library (which doesn't have to be libc, just the one that exposes these syscall wrappers) linked.

On Tuesday, 20 June 2017 at 11:00:00 UTC, Nemanja Boric wrote:
> On Monday, 19 June 2017 at 21:45:56 UTC, Moritz Maxeiner wrote:
>> On Monday, 19 June 2017 at 21:35:56 UTC, Steven Schveighoffer wrote:
>>> IIRC, Tango did not depend on libc at all. It only used system calls. So it certainly is possible.
>>
>> How did they invoke those system calls? They are usually access via libc on POSIX systems, so you don't have to implement accessing e.g. vdso on Linux yourself.
>
> Tango just didn't use C abstractions (`FILE*`, say), but rather it would call functions such `read(2)`, `write(2)`, `seek(2)`, etc. and implement buffering/seeking/etc manually.

Only the second one of those are the system calls I was talking about :p

> So, the library just declared `extern (C) read (...);`/`extern (C) write`.. and expected for the right library (which doesn't have to be libc, just the one that exposes these syscall wrappers) linked.

If you have a library that exposes to you via C API those functions that you need of libc, then that library *is* your (albeit partial) libc (since a libc is defined as any library that exposes such functions). In any case, that's the same way that druntime depends on libc AFAIK.

On Tuesday, 20 June 2017 at 11:08:15 UTC, Moritz Maxeiner wrote:
> On Tuesday, 20 June 2017 at 11:00:00 UTC, Nemanja Boric wrote:
>> On Monday, 19 June 2017 at 21:45:56 UTC, Moritz Maxeiner wrote:
>>> On Monday, 19 June 2017 at 21:35:56 UTC, Steven Schveighoffer wrote:
>>>> IIRC, Tango did not depend on libc at all. It only used system calls. So it certainly is possible.
>>>
>>> How did they invoke those system calls? They are usually access via libc on POSIX systems, so you don't have to implement accessing e.g. vdso on Linux yourself.
>>
>> Tango just didn't use C abstractions (`FILE*`, say), but rather it would call functions such `read(2)`, `write(2)`, `seek(2)`, etc. and implement buffering/seeking/etc manually.
>
> Only the second one of those are the system calls I was talking about :p
>

Yeah, I saw the Steve's answer late, but there's no editing posts here :(. :-)


>> So, the library just declared `extern (C) read (...);`/`extern (C) write`.. and expected for the right library (which doesn't have to be libc, just the one that exposes these syscall wrappers) linked.
>
> If you have a library that exposes to you via C API those functions that you need of libc, then that library *is* your (albeit partial) libc (since a libc is defined as any library that exposes such functions). In any case, that's the same way that druntime depends on libc AFAIK.

Yeah, that stands, but I thought the point of this topic was that (IIRC, not a phobos experienced user) Phobos (_not_ druntime) uses C _standard library_ abstractions for many things, and that's why the OP said we can't beat C in speed. I don't think it's reasonable thing to think that writing syscall wrappers would help D gain to much speed :-).

On Tuesday, 20 June 2017 at 11:18:17 UTC, Nemanja Boric wrote:
> Phobos (_not_ druntime) uses C _standard library_ abstractions for many things

I just took a quick look and it seems that I'm remembering this wrong.

On 2017-06-20 01:29, Steven Schveighoffer wrote:

> I may have misspoke. I mean they didn't depend on the library itself. I think they do depend on the C wrappers.
> 
> So for instance, they didn't use FILE *, but instead used read/write/recv/send.

They did use the Posix and Windows API functions. I can see some imports for libc and Posix functions spread out here and there [1], but I'm not too familiar with are system calls and which are not. It's certainly no way near how much is used in Phobos today.

[1] http://dsource.org/projects/tango/browser/trunk/tango/sys/Process.d#L17

-- 
/Jacob Carlborg

On 2017-06-20 09:48, Russel Winder via Digitalmars-d-learn wrote:

> But there is lots of paid resource in the core Go community which makes
> not using "middleware" feasible by providing your own. Also of course
> the Go/C interface is not as clean as is the case in D, so the need for
> Go-specific middleware is much, much higher. As D can call C linkage
> libraries, and libc is a library for interfacing to OSes, use it, get
> the abstraction, pay the (small) price, get someone else to do the
> maintenance.

Yes. But it would be nice to not be dependent on glibc. If we could use musl it would be a lot easier to create our own tool chain (and get full support for static liking). Avoiding the need to download the C tool chain to be able to use D. I've heard that many times, especially on macOS: "oh, you need to download Xcode to use D?".

-- 
/Jacob Carlborg

On Tuesday, 20 June 2017 at 11:26:44 UTC, Jacob Carlborg wrote:
> Yes. But it would be nice to not be dependent on glibc. If we could use musl it would be a lot easier to create our own tool chain (and get full support for static liking).

Yes, please.

> Avoiding the need to download the C tool chain to be able to use D. I've heard that many times, especially on macOS: "oh, you need to download Xcode to use D?".

Last time I checked you only needed the Xcode command line tools (which are small), not the whole thing. In any case, what would you propose to be bundled as the linker (if we can't depend on the one provided by Xcode)?

On 2017-06-20 13:51, Moritz Maxeiner wrote:

> Last time I checked you only needed the Xcode command line tools (which are small), not the whole thing.

Yes. But I think there are a few things missing, depending on what you need. There's some LLDB library that is missing from the command line tools that is used for editor/IDE integration.

>  In any case, what would you propose to be bundled as the linker (if we can't depend on the one provided by Xcode)?

LLD, the LLVM linker [1]. As far as I understand it, it also support cross-platform linking. Using LDC, musl and LLD you have a fully working cross-compiler tool chain. You might need some extra libraries as well, depending on what you need.

[1] https://lld.llvm.org

-- 
/Jacob Carlborg