Why is D unpopular? (page 64)

May 16, 2022

Re: Why is D unpopular?

Posted by Fry
in reply to Mike Parker

Permalink

Fry

Posted in reply to Mike Parker

Permalink

On Monday, 16 May 2022 at 08:33:08 UTC, Mike Parker 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.

I maintained a personal project that was 60k loc of D for the last 6-7 years. Probably won't pick D again for a long term project again. There was always a new compiler bug whenever I upgraded to a new version of the compiler. I'd try to stick to one version of the compiler, but bug fixes only exist for newer versions. Also a quite a bit of breaking changes, I turned off warnings as errors at some point.

I also remember another instance of someone else here maintaining a D project that was still being used but not actively developed anymore. A fix was made in a newer version of D but they were originally using one several versions behind that their code just wasn't compatible with the new D compiler anymore. The response from Walter was to suggest making a donation to back port the fix.

What they did and what is probably being done by other individuals is to just stick to one version of D, a single release. Then hope you don't come across a bug you need fixed. Not sure who else you meant to ask, but yah long-term develop with D sucks compared to other languages.

On Monday, 16 May 2022 at 10:35:14 UTC, zoujiaqing 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. [...] This is not really a big problem. Just search for `dlang` instead of `D` and you get good results. T -- Written on the window of a clothing store: No shirt, no shoes, no service.

On Monday, 16 May 2022 at 15:08:13 UTC, Ola Fosheim Grøstad wrote: > ... > .... > The biggest impact IMHO is that the threshold for *trying out* C-libraries is lowered. If you have to create your own binding your are essentially "locked in" due to the effort you spent just to get started. > > The larger the C-library is and the more frequently it is updated, the more impactful this feature might be. You just summarised my argument for why ImportC == 'here be dragons' ;-) D's focus should be 10 years ahead, not 30 years behind. Just imagine Rust/Go implementing a C compiler inside their own compiler They'd be laughing stock (not because it's wrong or silly, but because they took the initiative to step further awat from C, not further towards it).

On Monday, 16 May 2022 at 08:08:51 UTC, Walter Bright wrote: > ... > .... > I am unfamiliar with kernel development and its needs. It apparently is also written in a dialect of C with special compiler switches. What it 'needs' is to move away from C. https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=linux+kernel

On Monday, 16 May 2022 at 22:35:00 UTC, forkit wrote: > On Monday, 16 May 2022 at 15:08:13 UTC, Ola Fosheim Grøstad wrote: >> ... >> .... >> The biggest impact IMHO is that the threshold for *trying out* C-libraries is lowered. If you have to create your own binding your are essentially "locked in" due to the effort you spent just to get started. >> >> The larger the C-library is and the more frequently it is updated, the more impactful this feature might be. > > You just summarised my argument for why ImportC == 'here be dragons' ;-) > > D's focus should be 10 years ahead, not 30 years behind. > > Just imagine Rust/Go implementing a C compiler inside their own compiler They'd be laughing stock (not because it's wrong or silly, but because they took the initiative to step further awat from C, not further towards it). https://github.com/rust-lang/rust-bindgen It's not built in to the compiler but it's officially supported by the Rust foundation.

On 5/16/2022 12:20 PM, Fry wrote: > I maintained a personal project that was 60k loc of D for the last 6-7 years. Probably won't pick D again for a long term project again. There was _always_ a new compiler bug whenever I upgraded to a new version of the compiler. I'd try to stick to one version of the compiler, but bug fixes only exist for newer versions. Also a quite a bit of breaking changes, I turned off warnings as errors at some point. I'm sorry, but we don't have enough staff to maintain multiple versions simultaneously, especially on a volunteer basis. Most of us are not paid. > What they did and what is probably being done by other individuals is to just stick to one version of D, a single release. Then hope you don't come across a bug you need fixed. Not sure who else you meant to ask, but yah long-term develop with D sucks compared to other languages. Often people want 3 bug fixes along with 2 enhancements. Trying to create various combinations of these in multiple binaries is pretty hard to do.

On Sunday, 15 May 2022 at 23:11:28 UTC, max haughton wrote: > On Sunday, 15 May 2022 at 18:47:22 UTC, IGotD- wrote: >> On Sunday, 15 May 2022 at 06:18:58 UTC, forkit wrote: >>> >>> Also, operating systems of the (near) future will require safety guarantees from the software that is intended to run on that operating system. C is not a language that facilitates this. >>> >> >> Um, no that will not happen, ever. The safety guarantee of modern operating systems is and will be the MMU. Relying on "safe" software will never be enough. There have been attempts using safe intermediary languages like Microsoft Singularity but don't expect this ever to be a commercial operating system. The MMU is here to stay. > > I don't think the choice of language is going to make much difference but I'd be surprised if Apple don't do something along these lines in the future. They already scan and analyse applications relatively aggressive for mobile and to an extent for MacOS too. The choice of language can eliminate a whole class of bugs. It can also ensure the likelihood of a whole class of bugs. I'm sure you know this of course. I'm just stating the obvious. Fortunately, many get this, and are actively researching ways to move away from C - e.g. https://github.com/tock/tock/blob/master/doc/Design.md If Apple is not already doing very extensive research in this area, I'd be ...rather shocked. In the meantime, over here in the D community, we're actively seeking even more ways to get closer to C :-(

Forums