May 16

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

>

In my experience, it is not an option to rewrite working C code into D.

Note that I have successfully converted small and medium C code projects to D.

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

>

I've done other translations of programs from one language to another.

  1. if you don't have a test suite for the program, a successful conversion becomes an order of magnitude harder

  2. converting a program all at once does not work. It must be done incrementally, one function at a time

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).

>
  1. even so, when faced with a large, complex project, there's just no business case for doing a conversion

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.

>

Even just converting the .h files to D can be a major, rather unpleasant undertaking. We've put a lot of time into converting the various system .h files into D for druntime. There's always a risk of a mistake, and we've made them and the result is bizarre crashes because of ABI mismatches. Hand-checking them is error-prone, tedious and very boring work.

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

>

ImportC makes things so much easier. You can write new D code and hook it up with your existing C code base. You can get reliable, easy, and accurate access to .h files. D will happily work with a project that's a patchwork of C and D code.

>

I.e. it dramatically lowers the barrier to adopting D.

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?

May 16

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

>

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?

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...).

May 16

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

>

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

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).

May 16
On 5/15/2022 11:51 PM, Siarhei Siamashka wrote:
> On Sunday, 15 May 2022 at 17:21:18 UTC, Walter Bright wrote:
>> In my experience, it is not an option to rewrite working C code into D.
>>
>> Note that I have successfully converted small and medium C code projects to D.
> 
> Don't these two sentences contradict each other? Unless I'm misinterpreting the meaning of words "converted" and "successfully".

It means I have credibility when it comes to this topic.


>> 2. converting a program all at once does not work. It must be done incrementally, one function at a time
> Can you elaborate on this?

Doing it one function at a time means if your new build doesn't work, you only have one function to look at to find the error. This means orders of magnitude less time spent debugging.


> But once the job is done, long term maintenance is relatively painless.

No, it isn't. I speak from experience. C's limitations makes for code that is brittle (very hard to refactor).


> 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've brought forward code myself. The D1 => D2 transition was hard, but since then, it isn't that hard. But people don't want to bother with this.


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

This vastly underestimates the scope of the problem.


> 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?

I am unfamiliar with kernel development and its needs. It apparently is also written in a dialect of C with special compiler switches.
May 16

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

>

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'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.

May 16

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

>

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

>

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'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.

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.

May 16

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

>

On 5/15/2022 11:51 PM, Siarhei Siamashka wrote:

>

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

It means I have credibility when it comes to this topic.

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"?

> >

But once the job is done, long term maintenance is relatively painless.

No, it isn't. I speak from experience. C's limitations makes for code that is brittle (very hard to refactor).

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?

> >

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

This vastly underestimates the scope of the problem.

I think that you are exaggerating the problem.

> >

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

?

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?

May 16

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

>

It got asked on reddit sub but for those that aren't active too, I'd like you opinions. Please don't get me wrong, I also love D, I've used it everywhere I can and I'd say it's my favourite language (yes I have one...) but I'm as as the reddit's OP, trying to understand why it's unpopular. Rust and Go seeming to be getting more and more users. I think it's due to large ecosystem and the big corporations with deep pockets that pushes them. But I'd like to know you all opinions

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

May 16
On Sunday, 15 May 2022 at 17:21:18 UTC, Walter Bright wrote:
>
> 3. even so, when faced with a large, complex project, there's just no business case for doing a conversion


This is indeed the biggest problem after a translation, since the social structure that made that software being written and maintained in the first place do not exist for the fork. It might works, but receive no maintenance, performance enhancements, etc.

For example in July 2021 I re-translated parts of stb-image to v2.27 and got a +30%/+45% performance improvement in PNG loading. If I were using an ideal ImportC I would just have to copy the new header to the codebase.

So ImportC will help keeping up with dependencies that improves over time instead of being cast in stone. The security argument is moot, this will enhance security of D programs.
May 16

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

>

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++).

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.

56 57 58 59 60 61 62 63 64 65 66 67 68