On Sunday, 15 May 2022 at 17:21:18 UTC, Walter Bright wrote:

Don't these two sentences contradict each other? Unless I'm misinterpreting the meaning of words "converted" and "successfully".

Can you elaborate on this? One function at a time conversion can be easily done if one language is mostly a superset of another, such as converting from C to C++. But converting from C++ back to C one function at a time would be not so easy anymore (because there are classes, templates and other advanced language features).

Yes, if it ain't broke, don't fix it. Especially if this costs money and introduces unnecessary risks.

C is not very good for implementing new code compared to the other programming languages. But once the job is done, long term maintenance is relatively painless. The language is standardized and newer versions of the compilers are only becoming more strict about certain things.

D is good for rapid development of new code, but isn't great for long term maintenance because of the language evolution and compatibility breakages. My understanding is that many D projects and libraries died off because they could not afford to keep up and can't be even compiled anymore.

I don't think that converting the existing C code into D makes much sense. Because such conversion only turns the strength of one language into the weakness of another.

Well, everyone is doing this and bindings for popular C libraries are available for most programming languages.

Do I understand it right that ImportC is intended for implementing major new features in the existing old C projects using D language?

One of the old C projects is the Linux kernel. I know that some people are working on making it possible to develop some parts of the Linux kernel using Rust language. Would ImportC make it possible to use D for developing some parts of the Linux kernel and how is it different from what Rust people are doing?

On Monday, 16 May 2022 at 06:51:46 UTC, Siarhei Siamashka wrote:

Rust isn't being used to develop any part of the Linux kernel itself, AFAIK. It's approved for driver development, not any part of the kernel proper(although device drivers are, like, 90+% of the code in the Linux project so...).

On Monday, 16 May 2022 at 06:51:46 UTC, Siarhei Siamashka wrote:

That is possible yes. There are many chip vendors that has some kind of C API framework that is available together with their IPs. In this case (if import C works correctly) you can import their C API in D and then write D code than the usual C/C++ code which more likely will lead to buggy code. For low level code you're more likely to use better C than D though.

If import C worked, I would have done that right out of the bat (the managers will stop me of course).

On Monday, 16 May 2022 at 06:51:46 UTC, Siarhei Siamashka wrote:

I don't think that's true at all. Maybe some people felt the rate of change is to high (others will tell you they want more breakage), but I suspect many D projects and libraries died off because their creators moved on to other things before they got their projects to the state they wanted. You can find countless projects like that in every language ecosystem. They're perhaps more noticeable in ours because we're so small.

It's very easy to start a new project on a whim in any language, but getting it to the state you're aiming for and maintaining it long-term require discipline and commitment. Talk to people who actually maintain projects long-term to see what their take is.

On Monday, 16 May 2022 at 08:33:08 UTC, Mike Parker wrote:

I vaguely remember this message about maintaining 400kloc D code and keeping it up with the latest compiler versions: https://forum.dlang.org/post/idswokerwzdkszevjbrh@forum.dlang.org

Now I see that the poster said that the amount of breakages that come from compiler upgrades was reasonably small (at least by the poster's standards). But honestly, the description of their development process and the fact that there are at least some compatibility breaks is terrifying me. For example, I wonder what are they doing when they need to bisect a somewhat old bug? There are many little things like this that make everything problematic.

C++ compilers allow to pick an older versions of the standard for keeping compatibility with legacy code (such as as the '-std=c++11' option supported by G++). Rust has language editions too, which help to ensure that the legacy code keeps working even as the compiler evolves. But D language forever remains experimental. Or at least it is perceived as such by many outsiders and gets dismissed because of this.

On Monday, 16 May 2022 at 08:08:51 UTC, Walter Bright wrote:

Which of the two contradicting statements has credibility? Is it "not an option to rewrite working C code into D" or "I have successfully converted small and medium C code projects to D"?

Yes, it is relatively painless. Huge amounts of the existing C code developed over the span of decades show us a very different picture. Why would you want to refactor something that already works fine and needs to keep working fine in the future?

I think that you are exaggerating the problem.

If an old C project is doing its job just fine, then it only needs minimal maintenance and has no use for any fancy stuff. Now if a major new feature is needed in such an old project, then people normally use C (or C++) to implement it. Or if they prefer a more convenient nicer higher level language, then maybe they embed Lua or Python code to do the job. Is ImportC intended to allow using D language as an alternative to Lua/Python for such mixed language hybrid projects?

On Tuesday, 2 November 2021 at 17:27:25 UTC, Dr Machine Code wrote:

Two aspects:

First of all:
D The biggest problem is the name! Of course, many people deny this problem.
If you search for a letter in a search engine, it's hard to get valid results.
For example, a Google search for "D" results in comparison to a search for "Python," "Ruby," and "rust."
This has the undesirable effect of making it difficult for new users to find learning materials.

Second:
The standard library is weak, and the most basic HTTP modules are probably well supported in Python, Golang, and Rust, making it easy to build HTTP servers and use HTTP clients to access HTTP server resources. Even the most basic URL parsing is missing from the D standard library. I think the library should have a better experience with python and Golang.

-- zoujiaqing

On Monday, 16 May 2022 at 09:25:14 UTC, Siarhei Siamashka wrote:

Having done both, keeping up with C++ compilers is a lot more work than keeping up with D compilers.

C++ compilers do not have the same standard library, and not the same front-end. Some headers are missing for other's compilers. MSVC might remove features you need just like that, like inline 32-bit assembly.

And, C++ compilers have bugs too and when you get one there is no nice centralized Bugzilla to post it to.