Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Next C compiler is a D compiler: Introducing DMD's ImportC

briancallahan.net

Post reply on HN
Print view View original

61–70 of 89 posts

Re: Next C compiler is a D compiler: Introducing DMD's ImportC

#61

Post by eptcyka »

newpavlov wrote: post #35
bachmeier wrote: post #34

Earlier quoted context omitted.

> Using D code in Rust probably will be much more painful and I am not sure if it can be done 100% safely... Can you elaborate? Saying it will be "much more painful" without anything further is not especially helpful. I've added D functions to C programs more or less trivially, including compiling to a shared library, with no change to the code.

Because I am not knowledgeable about D runtime I can not say that it will not cause any conflicts with Rust assumptions (thus the use of "probably"). For example, IIRC there are serious issues with integrating Go code into a Rust project. If D code is compiled in the betterC mode, then there should not be any problems.

There are serious considerations for including Go code in a rust project, but it's not like there are any showstoppers - one just can't use the default runtime and must rely on Cgo, and the FFI entry points are not performant. Other than that, it's relatively painless. Far less painful than calling into the JVM IMO.

Re: Next C compiler is a D compiler: Introducing DMD's ImportC

#63

Post by germandiago »

WalterBright wrote: post #40
winrid wrote: post #37

Can you tell the D compiler to free a pointer returned from a C method when it goes out of scope? Like uniq_ptr

D can do RAII.

via structs, right? As for classes you should not rely on it I recall.

Re: Next C compiler is a D compiler: Introducing DMD's ImportC

#64

Post by cxr »

simplotek wrote: post #45
cxr wrote: post #25

Earlier quoted context omitted.

Do you plan on giving Zig a try? (They seem to be doing a lot right.) Taking the opportunity here to point people to "Adding Modules to C in 10 Lines of Code" from NWCPP earlier this year: https://www.youtube.com/watch?v=2ImfbGm0fls > (The pitfalls you mention running into there wrt to different compiler instances is itself a decent case study in not relying on singletons http://www.object-oriented-security.org/lets-…

> Do you plan on giving Zig a try? (They seem to be doing a lot right.) All this Zig spam is getting very tiring.

It's not "Zig spam" to ask, in direct response to a compiler guy who has just stated that they have not tried it yet, whether they plan to. For further context, the video I linked to is Walter showing up to a C++ users group to present a talk about the D compiler infrastructure—again, at a C++ event, for a bunch of C++ programmers. Considering that, if what I've done here by asking the natural follow up question is a faux pas, then I hesitate to conceive of what you must think of those actions by the person I'm asking it of.

Even all that aside, comparing and contrasting contemporaries in a similar space is natural. That's just, like, scholarship, you know? Imagine someone who's defending their thesis responding to a question about alternatives to their research by getting into a big huff about it. That'd be pretty silly, right?

And the comments about "PL tribalism" are a little odd, then, since the most tribalistic behavior we have evidence for in this thread is someone reacting exactly like this. As a fan of Walter's contributions, including D, in the past I've gone so far as to put a non-trivial amount of effort into polishing the articles on D, Walter, and Digital Mars on Wikipedia. Meanwhile, I've never even written a Zig program, dude; if there's a tribe I belong to, it's not Zig.

Re: Next C compiler is a D compiler: Introducing DMD's ImportC

#65

Post by svnpenn »

WalterBright wrote: post #41
svnpenn wrote: post #26

What I don't like about LDC, is you have to install the entire Visual Studio if you want a static build [1]. Contrast this with Go, Nim, Rust, Zig and others, that don't put this burden developers. Is DMD any different in this regard? 1. https://github.com/ldc-developers/ldc/issues/4047

DMD doesn't require anything else. Except for Win64, where it needs the VS C runtime library and linker.

> VS C runtime library and linker

is that included with the DMD installer? If not thats the same situation as LDC.

Re: Next C compiler is a D compiler: Introducing DMD's ImportC

#67

Post by nkozyra »

krylon wrote: post #59
benreesman wrote: post #29

Earlier quoted context omitted.

A lot of people might not know that before doing the D language, Walter was already a world-wide acknowledged expert on the compilation of C and C++. I don’t use D seriously but I’d still bet my ass that something smart happens when you feed C code to the D compiler toolchain.

> A lot of people might not know that Personally, that would surprise me, because C++ compilers is the context where I first read the name. I'm not saying this is incorrect, but I would find it amusing somehow.

It's fair to say that Walter is best known for his work with D rather than his work with C++, though.

Re: Next C compiler is a D compiler: Introducing DMD's ImportC

#68

Post by isthisthingon99 »

gavinray wrote: post #28

Note that the one feature holding this back from "true greatness" during development is that the tooling for providing LSP completions for D symbols in editors doesn't appear capable of detecting C code in your project yet One of the major appeals of ImportC is that it does away with needing to write (and maintain) D bindings to C libraries -- by hand, or generated. I was trying to experiment with io_uring in D and u…

> For hardcore vim programmers this is likely the norm

Just FYI, not anymore.

Re: Next C compiler is a D compiler: Introducing DMD's ImportC

#69

Post by tzs »

KerrAvon wrote: post #15
cylinder714 wrote: post #11

Walter, since you're here: what's your position regarding bootstrapping and Ken Thompson's "Reflections on Trusting Trust"?

The D compiler will steal your passwords, but only for old VAX BSD versions of passwd, so Walter can log in and fix your K&R C bugs while you're sleeping. your daily edition of WalterBrightFacts™

Hmmm...once at Caltech someone got into my account on the PDP-10 and all they did, as far as I could tell, was fix some bugs in a program of mine I was having trouble with.

I never did find out who did it. I wonder if it was Walter?

I was an overly obnoxious frosh at the time and I'm certain I was quite annoying to the older students who frequented the terminal room such as Walter (I think he would have been a junior at the time).

And I'm certain Walter was aware of me, because he had once either targeted me in a prank or used me in a prank against someone else (or perhaps both--I've never been clear on who was the target). The someone else was one of the system admins, Bill. Bill really liked playing Walter's game "Empire".

So one day I was sitting at a terminal hacking away at something and I got a message via the system for sending a text message to another terminal from Bill telling me to not do what I just did again or I'd be in trouble and have my account suspended.

I had no idea what he was talking about. A while later I got another message. Bill seemed really annoyed with me. I then got summoned to his office. He was really mad. He said I keep sending him rude messages, like telling him to stop playing Empire and get his fat ass back to work.

I denied sending these messages and he was not buying it.

And then another insult from me came through while I was there in his office.

Bill then started to maybe believe me, and went to Walter's directory to look at the Empire source. Sure enough, Walter had recently added code that checked for Bill playing while I was also logged on, and would fake rude and insulting messages from me from my terminal to Bill.

And that is why I will never use a compiler from Walter if there is any way the compiler might be able to tell I'm the one using it. :-)

Re: Next C compiler is a D compiler: Introducing DMD's ImportC

#70

Post by pjmlp »

flohofwoe wrote: post #50
WalterBright wrote: post #10

Earlier quoted context omitted.

Designator-list support has since been added. The multi-layer designators are still to be done, though (they're rarely used, so are a lower priority).

I think something along those lines (rarely used...) was also given by the C++ Committee as justification why so much of the C99 designated init feature set was left out of C++20, which is a bit of a shame. All C99 designated-init 'sub-features' complement each other nicely once you start using them. It's a great way for building 'data-centric' APIs. For instance check out this call to create a 3D-API pipeline-state-…

The C++ reason has to do with the construction order of fields, which C naturally doesn't have.
Post reply on HN