Live data from Hacker News

OpenD, a D language fork that is open to your contributions

dpldocs.info

51–60 of 322 posts

Re: OpenD, a D language fork that is open to your contributions

#51
post #28

In the last decade, we've had many learning experiences around governance of programming languages. Most of the changing languages that come to mind, I realize, that they, too, had a big upset or oops related to governance. I now think one of the key things to look for in a programming language is governance -- what they say about how they do it, what they actually do, how that's working out so far, and how you think…

While I agree this is an important problem, I don't think there is a satisfactory answer. Programming language evolution is more or less a complexity management, while you also have to balance requirements from various stakeholders. Almost all governance drama came from one group of stakeholders complaining about requirements essential for other group of stakeholders, and you can't always satisfy both. (Rust `async`…

We might be able say that a given assessment of governance will work out well for our needs. But it's a lot easier to identify showstoppers early on.

For example, if a language designer and implementor says upfront that they want to run it as Benevolent Dictator For Life, and also that they don't want to see feature PRs from people, because they prefer to work through all the details themself... That's their right, and great information to have upfront. That governance might tentatively work for some adopters, and others will decide it's a showstopper without needing to explore further.

Re: OpenD, a D language fork that is open to your contributions

#52

Earlier quoted context omitted.

To overcome something as entrenched as C++ it has to be 10x better. Even rust isn't there. Most of it's community isn't ex C and C++ experts, it's people getting into low-level programming for the first time, either from scripting language or pure functional.

Don't we consider a C/C++ replacement "successful" when it was able to capture enough share of prior C/C++ uses, not the entire share? I never thought C or C++ could be completely gone out of sight, even COBOL is technically alive today (on life support). To be clear, I meant that D could have been in the position of Rust today if done right.

Yes, by that criteria C++ was successful over C. And C was successful over fortran. There are small communities that prefer the older stuff, but they were better enough to move the entire industry.

D isn't, and neither is Rust.

> I meant that D could have been in the position of Rust today if done right.

My point was Rust is just a completely different audience. I suppose D could have sold itself as a better JavaScript.

(Sorry for several rewrites.)

Re: OpenD, a D language fork that is open to your contributions

#53

Earlier quoted context omitted.

Rust is a really frustrating language for me: I understand the safety it provides but find the pain of actually using it makes it uncompelling. Plus, the Rewrite it in Rust movement is very off-putting

Rust pissed me off until I stopped fighting it. When I finally gave up and started doing things its way, it became a lot more fun. And `cargo clippy` is flat-out helpful for learning Rust’s idioms. While I’m not yet out to rewrite all the things in Rust, I understand the appeal of rebooting archaeological projects with a modern approach.

The thing is, I just don’t want to write programs the way Rust wants me to. Among statically typed languages, Java is the closest to what I want to use but my true love is Common Lisp. With the arrival of Coalton, I can get the best of both worlds: a type system with nice properties for the rare program that would benefit from them and CL for the majority of programs.

Re: OpenD, a D language fork that is open to your contributions

#54

Earlier quoted context omitted.

I felt the opposite back when I was using D (specifically, D1). It was obvious that everything you can do in C++ can be done in D in so much easier way that it could have replaced C++ in a near future if done right. This is even true when we compare D1 with the current C++20, so I believe D did have a good chance that was wasted somehow.

> It was obvious that everything you can do in C++ can be done in D in so much easier way that it could have replaced C++ in a near future if done right. Do you have an opinion on how the GC schism within D affected it competitively with regards to C/C++?

While I don't know well about exact arguments for and against GC in that incident, I believe it's worthwhile to consider two cases when you want to avoid GC. One is the case where you shouldn't run GC because you have a very strict time limit and any GC pause is not desirable. The other is the case where GC pauses are discouraged but not the end of the world. D's `@nogc` only caters the former, which is much rarer than the later (i.e. hard realtime vs. soft realtime). So I think `@nogc` should have been more like an `@explicitgc`, where any allocation and thus GC pause should be marked in the syntax, but is not forbidden otherwise. But I do agree that something like `@nogc` was required.

Re: OpenD, a D language fork that is open to your contributions

#56
post #51

Earlier quoted context omitted.

While I agree this is an important problem, I don't think there is a satisfactory answer. Programming language evolution is more or less a complexity management, while you also have to balance requirements from various stakeholders. Almost all governance drama came from one group of stakeholders complaining about requirements essential for other group of stakeholders, and you can't always satisfy both. (Rust `async`…

We might be able say that a given assessment of governance will work out well for our needs. But it's a lot easier to identify showstoppers early on. For example, if a language designer and implementor says upfront that they want to run it as Benevolent Dictator For Life, and also that they don't want to see feature PRs from people, because they prefer to work through all the details themself... That's their right, a…

You are right about early adopters, but once those have been filtered, there will still be multiple stakeholders within the resulting community. Even when we don't consider new users, I can't see how they can be adaquately catered for in general.

Re: OpenD, a D language fork that is open to your contributions

#57

Earlier quoted context omitted.

Rust is a really frustrating language for me: I understand the safety it provides but find the pain of actually using it makes it uncompelling. Plus, the Rewrite it in Rust movement is very off-putting

As far as specific complaints go, async rust seems to be a trap: I’ve heard of several companies adopting it and then regretting the decision six months later because of the failure of that abstraction to adequately abstract.

It's difficult to avoid, right? If you are writing a network server or client that manages a lot of connections, you can either use the popular async executor or you can stray far from the beaten path.

Re: OpenD, a D language fork that is open to your contributions

#58

My research group left D for Rust several years ago due to nonresponsiveness and poor language development trajectory. While I wish Adam and the others success with OpenD, I hope they can take the opportunity to pick a more unique/memorable name.

LiberateD

FreeD

Re: OpenD, a D language fork that is open to your contributions

#59
post #42

Earlier quoted context omitted.

Rust is a really frustrating language for me: I understand the safety it provides but find the pain of actually using it makes it uncompelling. Plus, the Rewrite it in Rust movement is very off-putting

Rust was a language that I firmly embraced for my own projects for about 2 years, then I eventually came to the conclusion that the benefits it gave me weren't really that useful for the things I was working on, and I switched away to other languages that I personally enjoy using more.

Which languages do you enjoy more?

Re: OpenD, a D language fork that is open to your contributions

#60
post #9

Earlier quoted context omitted.

I think the fundamental problem with D is much simpler than that, it's the technical context. D is a better C++, but it's not better enough to escape the gravitational pull of C++. Rust is sufficiently compelling, with its focus on memory safety.

I keep saying this and having the exact same argument with everyone every single time I mention it (and I'm sure here we'll go again), but D's fundamental problem was its GC. Its mere presence colors the code that uses it, and once your dependencies use the GC, you have no recourse. It's impossible to abstract away. I fail to see how such a language could ever substitute for C++.

According to the followup a week later[0] it seems OpenD is doubling down on GC:

> One of the guiding principles of this fork is to embrace the GC as a successful design rather than to shun and avoid it. [...] I have harshly criticized @nogc in the past as putting a disproportionate burden on library authors while being the wrong answer to what can be a perfectly fair question.

[0] https://dpldocs.info/this-week-in-d/Blog.Posted_2024_01_08.h...

Post reply on HN