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 using liburing headers included in a C file + ImportC
My D app compiled and ran fine, and I could call liburing but in my editor I was in the dark as to what the methods I could call or their signatures were.
For hardcore vim programmers this is likely the norm, but for me I consider that a step backwards, and I went back to manually generating D bindings and using those.
Waiting for the day we'll see ImportC fully integrated into dub and pure-d/workspace-d!
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.
This might actually make my life a lot easier compared to how I am currently doing certain things with some of my libraries that need to interoperate with C.
(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-argue/singleton...>—even if it ultimately wasn't so inconvenient that the work never got done, it would be even more convenient if it didn't need to have been done in the first place!)
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.
It is Zig spam, not because of the discussion or the question or the topic of the time of day. It's Zig spam because it's yet another Zig post among the barrage of Zig posts desperately shoe-horning offtopic gratuitous references to Zig. It's tiring and adds nothing to any discussion.
If you feel that strongly about the need to promote Zig, submit discussions. Please don't spam each and any top submission with these gratuitous references.
Please don't blow past the comments already addressing your complaint.
What I responded to was a comment from D's own creator who himself directly mentioned Zig. I didn't shoe-horn shit. I've been waiting a long time for a hit on Corncob TV.
If you're upset about Zig mentioned here, your quarrel is not with me, the person who spent over half the words in their comment bringing it back to the original topic by linking to a useful talk; your quarrel is with, if anyone, the original questioner who got Walter to comment on Zig. (And even then, your ire would be tenuous at best, for the reasons already mentioned.) I also cannot "feel that strongly about the need to promote Zig"—because I am not promoting Zig. As I have already said, D is closer to my tribe than Zig is.
It's not off-topic though. D has the facility to compile C projects, as has Zig. OP asked a genuine question about whether Walter Bright was able to compare experiences.
I don't mind languages getting hyped but seeing posts every week on the front page of HN about an unstable esoteric language with 0 adoption - yes, it's getting tiring.
simplotek is most probably a legitimate user annoyed by Zig news. I don't agree with their point, for what it's worth, but at least it's an opinion shared earnestly, unlike the troll.
> Instead of being petulant about it, you could ignore it and move o
Not wanting to see gratuitous self-promoting spam degrading the signal/noise ratio of an otherwise interesting discussion is hardly petulance. Replace any Zig reference shoe-horned into this discussion with, say, Java, and see if you have any point.
Agree about the excessive spam. To include attacks and bashing of other programming languages. It's very obvious what's going on and looks like it's going over the top, as if a concerted effort and mode of operation.
If they've heard of zig, then they've almost certainly heard of Rust. I generally prefer Rust, but C interop is something that zig does significantly better.
The article's title is "Your next C compiler is a D compiler", which makes sense, though it's a bit clickbaity. The HN submission title is "Next C compiler is a D compiler", which barely makes grammatical sense, and to the extent that it does make sense, it sounds like there's a C compiler called "Next C compiler" which is also a D compiler.
I don't think it's your mistake. It seems HN automatically removes certain leading/trailing words from titles so as to reduce clickbait but it doesn't seem to be very smart about it.
It gets annoying, because in cases like this it doesn't make sense, but in other cases it actually changes the meaning of the title. I honestly don't understand it given the prohibition against submitters changing the title.
I'd be much less annoyed by it if dang finally made it a pre-submit check (maybe with a checkbox "Overrule") like the "too long" check. But no, it seems to be important that the submitter has to check manually whether the title he just typed in is still there.
My experience with D is always a joyful one. If it isn't because it is a relatively straightforward language to learn then it is learning something new now and then that just makes life to much more easier.
Infact, D was the first language I learnt templating in and I really like it (or rather, the way D goes about it - made it much more approachable for me).
You definately made it simple! I recall the very first time I tried learning then in D (was trying to understand the `to!` from `std.conv` and it seemed simple enough).
The syntax for inferring a type for function calk arguments is nifty too.
Lastly, today I finally understand what mixins are , I just read some stdlib file somewhere and thought, wow that's rather useful. I definately think I will be making use of mixins sometime soon, been working on a small compiler in D itself and there are times were duplication (or perhaps inclusion is a better word) of code would be nice in such a manner.
Hey walter, have you thought about adding first class types to the language? that would enable us to use CTFE for type based algorithms instead of templates like std.meta.
If you did, what are the reasons against them?
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-object in C99:
Using Rust code in D should be relatively easy: expose C API, compile it into a shared library and use it on the D side as any other library. cbindgen (https://github.com/eqrion/cbindgen) can help with generation of header files. Static linking is possible as well.
Using D code in Rust probably will be much more painful and I am not sure if it can be done 100% safely...
> 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.
You can link in and interop fine with C/C++ as long as you link in the D runtime, kind of how you can mix C and C++ by linking in libcxx.
D's betterC mode ensures that the binary can run purely on libc without D's runtime library. It's kind of like being able to link and execute C++ code without needing libcxx.
Rust is pretty clearly the ascendant language in this (big) niche.
I forecast that as it’s pragmatic, industrial uses (inevitably) grow sharply, that the FFI story will just have to improve. Rust is going to be the next “low-level” language.
The “Pure Rust” talking point will have to recede a bit but it will be a net win for Rust’s truly broad adoption, which is going to happen whether cranky old-timers like me like it or not :)
C has head const and it's pretty common in C code bases. From what I remember, D had transitive const and not head const, so how does ImportC deal with this now?
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?
David Wheeler's Ph.D dissertation on the subject hasn't been refuted as far as I know, so the diverse double compilation method should be sufficient to mitigate the compiler subversion threat. I worked on a project to do this in OpenEmbedded to build firmware for the Power9 Talos workstation firmware and the BMC. Somewhat painful but successful.
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.
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. :-)
The important part in Zig is that you don't need another compiler toolchain to build a mixed C/C++/ObjC project, how that's implemented under the hood (e.g. embedded clang vs self-made compiler) is an implementation detail.
I'd argue that C++ and ObjC support is just as important as C support for real world projects (because a lot of important libraries are written in C++ unfortunately, and ObjC is needed for calling into macOS system APIs - although this could also be done more awkwardly by going through the ObjC C runtime).
The one big downside of embedding Clang and the whole of LLVM is the compiler's executable size (somewhere around 170 MB).
Zig does have "translate-c", which attempts to convert C code to Zig code. Similarly to D, it's used for a feature to automatically import C headers into a Zig program. But even that's based on libclang's parser and AST.
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 using liburing headers included in a C file + ImportC
My D app compiled and ran fine, and I could call liburing but in my editor I was in the dark as to what the methods I could call or their signatures were.
For hardcore vim programmers this is likely the norm, but for me I consider that a step backwards, and I went back to manually generating D bindings and using those.
Waiting for the day we'll see ImportC fully integrated into dub and pure-d/workspace-d!