4 ms·

I prefer D, it can be fully compatible with C, the syntax is easy to learn if you've used any of the C family you already know 80%, the package system is simple

by pharke 5y ago

I prefer D, it can be fully compatible with C, the syntax is easy to learn if you've used any of the C family you already know 80%, the package system is simple, modules mean no more headers or include statements just import things where and when you need them, supports every style of programming, QOL improvements like ranges and foreach, proper strings, optional garbage collector, has a long history of continuous improvement and support. To me it's the clear choice if I'm going to rewrite an old C project since I can mostly just copy paste the old code and it runs, after which I can clean it up and simplify it using the new features mentioned. Oh! and integrated unit tests and documentation generation are superb. Helpful error messages too. I could go on but I'd prefer everyone just try it out and see for themselves. https://dlang.org/ https://dlang.org/

10000truths 5y ago
I would say that Zig has the same advantages for a lot of these points. Its interoperability with C at the source and object level is first-class, the syntax was very easy for me to pick up as someone familiar with C/C++, the features it adds on top of C (e.g. slices, compile time execution) are few but huge QoL improvements, its translate-c utility works amazingly well at transpiling C code to Zig, and its test blocks make unit testing trivial to integrate.
- gavinray 5y ago
  Out of curiosity, have you written apps in both languages? I have written small applications in both. To be transparent: my total dev hours in D are probably somewhere around ~100, and in Zig about ~30. So I am more familiar with D than Zig, though competent enough with both to have written a few small real-world programs. > Its interoperability with C at the source and object level is first-class D has direct interop with both C, and C++. Also, it's recently gained it's own C compiler, and can natively compile C code so that they are D objects, not just external definitions. - https://dlang.org/spec/interfaceToC.html https://dlang.org/spec/interfaceToC.html - https://dlang.org/spec/cpp_interface.html https://dlang.org/spec/cpp_interface.html It can even directly interop with C++ classes: - https://dlang.org/spec/cpp_interface.html#using_cpp_classes_from_d https://dlang.org/spec/cpp_interface.html#using_cpp_classes_... > the syntax was very easy for me to pick up as someone familiar with C/C++ D is closer to C/C++ than Zig IMO. One of it's design goals is actually: "10. Where D code looks the same as C code, have it either behave the same or issue an error." And: "The general look and feel of C/C++ is adopted. It uses the same algebraic syntax, most of the same expression and statement forms, and the general layout." See: https://dlang.org/overview.html#goals https://dlang.org/overview.html#goals I found Zig to be much less syntactically similar to C/C++ than D. Zig felt more like a mix of Rust/Go. > the features it adds on top of C (e.g. slices, compile time execution) D also has slices and (outside of Lisp) was the first programming language I believe to introduce CTFE and CTFE-based metaprogramming. C++'s implementation as I understand it is essentially lifted from D. - https://dlang.org/articles/d-array-article.html#introducing-slices https://dlang.org/articles/d-array-article.html#introducing-... - https://tour.dlang.org/tour/en/gems/compile-time-function-evaluation-ctfe https://tour.dlang.org/tour/en/gems/compile-time-function-ev... > its translate-c utility works amazingly well at transpiling C code to Zig As stated above, not required due to ImportC, but there are several tools to automatically generate "extern" bindings to C/ObjectiveC/C++. You use these if you're linking with an external out-of-tree library, or a C++ library. - C, Limited C++ = https://dlang.org/blog/2019/04/08/project-highlight-dpp https://dlang.org/blog/2019/04/08/project-highlight-dpp - C, Extensive C++ = https://github.com/Superbelko/ohmygentool https://github.com/Superbelko/ohmygentool - C, Objective-C = https://github.com/jacob-carlborg/dstep https://github.com/jacob-carlborg/dstep > its test blocks make unit testing trivial to integrate. Again, D also has this: - https://tour.dlang.org/tour/en/gems/unittesting https://tour.dlang.org/tour/en/gems/unittesting ============= Not trying to start a pissing match, because I actually think that Zig has a lot to offer as well -- but for these particular list of things, there's no clear winner here.
  - kaba0 5y ago
    Is syntactical similarity or even compatibility to C a positive thing? Not taking away anything, D is a really cool language that definitely doesn’t get the fame it would rightfully deserve, I just think that breaking with some old habits (eg. postfix types with : are simply superior from a parsing perspective, and the pointer magic of C is just as terrible and the change in Zig is very welcome) when they are superseded is a good thing.
    - gavinray 5y ago
      I do actually prefer postfix types, so I'm not against you there. The bit about D is that while you CAN write it to look like C, (or even directly embed ASM blocks in it), it's usually written in a higher-level form without pointers that looks more like JavaScript: // Count line length of stdin void main() { import std.range, std.stdio; auto sum = 0.0; auto count = stdin.byLine.tee!(l => sum += l.length).walkLength; writeln("Average line length: ", count ? sum / count : 0); } ---- import std.algorithm, std.conv, std.functional, std.math, std.regex, std.stdio; alias round = pipe!(to!(real), std.math.round, to!(string)); static reFloatingPoint = ctRegex!(`[0-9]+\.[0-9]+`); // Replace anything that looks like a real number with the rounded equivalent. void main(){ stdin .byLine .map!(l => l.replaceAll!(c => c.hit.round) (reFloatingPoint)) .each!(it => writeln(it)); }
  - childintime 5y ago
    D has a lot to offer. But C absolutely crushes everything else in the embedded space, on micro-controllers, and if a language wants to be a C replacement, it'll have to leave C gasping right there. D quite simply never tried. Zig on the other hand seems like a silver bullet aimed straight at C's heart, the embedded space. Once it arrives it'll only have to worry about Rust. Rust is the black hole at the center of the software universe, slowly sucking the blood out of everything else. Zig vs Rust is shaping up to be an epic battle, like the Jedi vs the Empire, for sure :)
    - losvedir 5y ago
pjmlp 5y ago
Me too, I really wished some nice corporation would give it the adoption boost it needs.
gavinray 5y ago
Me too. > To me it's the clear choice if I'm going to rewrite an old C project since I can mostly just copy paste the old code and it runs With the new ImportC feature you can literally copy-paste the code and reference your C types from D directly with a mixed compilation. https://news.ycombinator.com/item?id=27872596 https://news.ycombinator.com/item?id=27872596 https://dlang.org/spec/importc.html https://dlang.org/spec/importc.html Quoting Walter from the thread linked above on it's purpose/reasons (which I think ought to go somewhere official tbh, since that brief discussion in the above thread is the best + most succinct overview of it currently AFAIK) The reasons for ImportC are: 1. It's no longer necessary to translate .h files to D to interface with C. While doing the translations isn't hard, it is tedious, and if there are a lot of .h files it becomes a barrier. 2. .h files get updated over time, and correspondingly updating the D files is error prone. It's much more effective to just compile the new .h files. 3. It is not necessary to even create a .h file - just compile the .c file with ImportC and D will access it just like any other module. D will even inline the C functions in it. 4. Use it as a standalone, small and fast, C compiler.
- 59nadir 5y ago
  `@cImport` in zig does the same as `ImportC` for D. You import a C file and can then just use it in your program. Notably it existed in Zig before it did in D.
jeofken 5y ago
For strings in C nothing beats SDS by antirez. So simple
- pjmlp 5y ago
  Sadly it is the kind of stuff that keeps being ignored by WG14.

by pharke 5y ago

10000truths 5y ago

I would say that Zig has the same advantages for a lot of these points. Its interoperability with C at the source and object level is first-class, the syntax was very easy for me to pick up as someone familiar with C/C++, the features it adds on top of C (e.g. slices, compile time execution) are few but huge QoL improvements, its translate-c utility works amazingly well at transpiling C code to Zig, and its test blocks make unit testing trivial to integrate.

gavinray 5y ago
Out of curiosity, have you written apps in both languages? I have written small applications in both. To be transparent: my total dev hours in D are probably somewhere around ~100, and in Zig about ~30. So I am more familiar with D than Zig, though competent enough with both to have written a few small real-world programs. > Its interoperability with C at the source and object level is first-class D has direct interop with both C, and C++. Also, it's recently gained it's own C compiler, and can natively compile C code so that they are D objects, not just external definitions. - https://dlang.org/spec/interfaceToC.html https://dlang.org/spec/interfaceToC.html - https://dlang.org/spec/cpp_interface.html https://dlang.org/spec/cpp_interface.html It can even directly interop with C++ classes: - https://dlang.org/spec/cpp_interface.html#using_cpp_classes_from_d https://dlang.org/spec/cpp_interface.html#using_cpp_classes_... > the syntax was very easy for me to pick up as someone familiar with C/C++ D is closer to C/C++ than Zig IMO. One of it's design goals is actually: "10. Where D code looks the same as C code, have it either behave the same or issue an error." And: "The general look and feel of C/C++ is adopted. It uses the same algebraic syntax, most of the same expression and statement forms, and the general layout." See: https://dlang.org/overview.html#goals https://dlang.org/overview.html#goals I found Zig to be much less syntactically similar to C/C++ than D. Zig felt more like a mix of Rust/Go. > the features it adds on top of C (e.g. slices, compile time execution) D also has slices and (outside of Lisp) was the first programming language I believe to introduce CTFE and CTFE-based metaprogramming. C++'s implementation as I understand it is essentially lifted from D. - https://dlang.org/articles/d-array-article.html#introducing-slices https://dlang.org/articles/d-array-article.html#introducing-... - https://tour.dlang.org/tour/en/gems/compile-time-function-evaluation-ctfe https://tour.dlang.org/tour/en/gems/compile-time-function-ev... > its translate-c utility works amazingly well at transpiling C code to Zig As stated above, not required due to ImportC, but there are several tools to automatically generate "extern" bindings to C/ObjectiveC/C++. You use these if you're linking with an external out-of-tree library, or a C++ library. - C, Limited C++ = https://dlang.org/blog/2019/04/08/project-highlight-dpp https://dlang.org/blog/2019/04/08/project-highlight-dpp - C, Extensive C++ = https://github.com/Superbelko/ohmygentool https://github.com/Superbelko/ohmygentool - C, Objective-C = https://github.com/jacob-carlborg/dstep https://github.com/jacob-carlborg/dstep > its test blocks make unit testing trivial to integrate. Again, D also has this: - https://tour.dlang.org/tour/en/gems/unittesting https://tour.dlang.org/tour/en/gems/unittesting ============= Not trying to start a pissing match, because I actually think that Zig has a lot to offer as well -- but for these particular list of things, there's no clear winner here.
- kaba0 5y ago
  Is syntactical similarity or even compatibility to C a positive thing? Not taking away anything, D is a really cool language that definitely doesn’t get the fame it would rightfully deserve, I just think that breaking with some old habits (eg. postfix types with : are simply superior from a parsing perspective, and the pointer magic of C is just as terrible and the change in Zig is very welcome) when they are superseded is a good thing.
  - gavinray 5y ago
    I do actually prefer postfix types, so I'm not against you there. The bit about D is that while you CAN write it to look like C, (or even directly embed ASM blocks in it), it's usually written in a higher-level form without pointers that looks more like JavaScript: // Count line length of stdin void main() { import std.range, std.stdio; auto sum = 0.0; auto count = stdin.byLine.tee!(l => sum += l.length).walkLength; writeln("Average line length: ", count ? sum / count : 0); } ---- import std.algorithm, std.conv, std.functional, std.math, std.regex, std.stdio; alias round = pipe!(to!(real), std.math.round, to!(string)); static reFloatingPoint = ctRegex!(`[0-9]+\.[0-9]+`); // Replace anything that looks like a real number with the rounded equivalent. void main(){ stdin .byLine .map!(l => l.replaceAll!(c => c.hit.round) (reFloatingPoint)) .each!(it => writeln(it)); }
- childintime 5y ago
  D has a lot to offer. But C absolutely crushes everything else in the embedded space, on micro-controllers, and if a language wants to be a C replacement, it'll have to leave C gasping right there. D quite simply never tried. Zig on the other hand seems like a silver bullet aimed straight at C's heart, the embedded space. Once it arrives it'll only have to worry about Rust. Rust is the black hole at the center of the software universe, slowly sucking the blood out of everything else. Zig vs Rust is shaping up to be an epic battle, like the Jedi vs the Empire, for sure :)
  - losvedir 5y ago

pjmlp 5y ago

Me too, I really wished some nice corporation would give it the adoption boost it needs.

gavinray 5y ago

Me too. > To me it's the clear choice if I'm going to rewrite an old C project since I can mostly just copy paste the old code and it runs With the new ImportC feature you can literally copy-paste the code and reference your C types from D directly with a mixed compilation. https://news.ycombinator.com/item?id=27872596 https://news.ycombinator.com/item?id=27872596 https://dlang.org/spec/importc.html https://dlang.org/spec/importc.html Quoting Walter from the thread linked above on it's purpose/reasons (which I think ought to go somewhere official tbh, since that brief discussion in the above thread is the best + most succinct overview of it currently AFAIK) The reasons for ImportC are: 1. It's no longer necessary to translate .h files to D to interface with C. While doing the translations isn't hard, it is tedious, and if there are a lot of .h files it becomes a barrier. 2. .h files get updated over time, and correspondingly updating the D files is error prone. It's much more effective to just compile the new .h files. 3. It is not necessary to even create a .h file - just compile the .c file with ImportC and D will access it just like any other module. D will even inline the C functions in it. 4. Use it as a standalone, small and fast, C compiler.

59nadir 5y ago
`@cImport` in zig does the same as `ImportC` for D. You import a C file and can then just use it in your program. Notably it existed in Zig before it did in D.

jeofken 5y ago

For strings in C nothing beats SDS by antirez. So simple

pjmlp 5y ago
Sadly it is the kind of stuff that keeps being ignored by WG14.