OpenD, a fork of D

As a primarily python programmer with some embedded C experience, I really liked the promise of Dlang when I first saw it, though somewhat it felt as dead language, especially compared to Rust, Zig or Nim - I would rarely hear about Dlang in my circles and bubbles.

Let's hope OpenD takes off, wouldn't mind tipping my toes in it once again.

13

Off-topic, but I'm curious why you would put Nim in that list. While I absolutely love the language, I've never heard of anyone using it for anything serious, especially compared to Rust or even Zig. I'd even be surprised if it has more mindshare than D.

(An absolute shame by the way. Nim looks like an absolutely fantastic language.)

8
I would rarely hear about Dlang in my circles and bubbles.

That's hardly a measure of relevance or technical merit. There's a lot of artificial hype being created around some new projects that have a very tenuous correspondence to their technical merits or problems they actually solve, and social network chatter is hardly a factor in assessing technical merits.

-9
- For me, it means people are actively using it (making libraries... making the language better) or in general there is some movement behind it and I think that is actually important for open source projects.
  
  16

Embracing the GC

I never actually liked the GC in D as it didn't seem to fit in with the general direction of the language, and Walter Bright in D at 20: Hits and Misses says:

Miss: Emphasis on GC

10

I read through the better part of a linked thread: https://forum.dlang.org/thread/ncbawciyybdksecurmsc@forum.dlang.org?page=1. And wow, as a C++ user, I'm not sure if I should feel blessed about how stable and backwards-compatible the language is, or that D users must be bonkers to put up with the breakages. Using C++ both professionally and for hobby projects, in the last 5 or so years I can remember encountering exactly 1 (gcc) compiler bug. There was a simple workaround + someone else had already reported it so with the next minor update the bug was fixed. And the code that triggered it was a nested CRTP spawn of hell so I didn't blame the compiler from borking on it in the first place, it would've been better for everyone had it never compiled :p

Upgrading a major C++ compiler version was never free in my experience, but even when working in a codebase with ~2M LOC the upgrade (e.g. 14 -> 17) was something that could be prepared in a set of feature branches by one person over the span of one, maybe two weeks. That's for fixing compile errors, I don't remember if we had issues with runtime errors due to an upgrade, but if we did it must've been minor because I remember the transition to 17 was pretty smooth. Note that 14 -> 17 requires changing the requested C++ version for the project, which is different from upgrading the actual compiler, i.e. you can do the latter without the former and your code should not require any changes.

7

Upgrading a major C++ compiler version was never free in my experience, but even when working in a codebase with ~2M LOC the upgrade (e.g. 14 -> 17) was something that could be prepared in a set of feature branches by one person over the span of one, maybe two weeks.

That greatly depends on your project, what dependencies it has, and what's involved in the migration. For example, I recall a previous project I worked on that experienced a considerable amount of non-trivial issues when upgrading to C++14 due to unforeseeable curve balls. One of them was caused by a third-party dependency toggling constexpr versions of its member functions only on C++14, which caused a bunch of obscure linker errors as old symbols were no longer available.

4

From the blog post, it sounds like the underlying motivation is not tied to technical aspects but control over the language. If I had invested any of my personal time onboarding onto D and migrated any of my projects to D, I would be concerned about the negative impact these political stunts have on the tech stack.

6

Walter Bright has fairly odious political opinions; like many social conservatives these days, he likes to complain about wokeness and communism, and I would completely understand a community fork simply to remove his control over various parts of the D language.

Also, just for a quick sanity-check: Which languages have you invested/migrated to, only to find that "political stunts" had a "negative impact" on your planned development?

12
- Huh. I've played around with D a few years ago.. don't exactly remember his opinions coming to light, but I can't say I'm surprised either.
  
  2
- Walter Bright has fairly odious political opinions;
  
  I fail to see the relevance of what personal opinions and beliefs he may or may not have. You're making it sound like the goal is not to improve a language ir fix issues, but to take away something away from a person just because you disagree with their political opinions. That's hardly good use of anyone's time, and sounds terribly petty behavior.
  
  I wish I had that much free time to be able to waste it being so vindictive about such trifling issues.
  
  Which languages have you invested/migrated to, only to find that “political stunts” had a “negative impact” on your planned development?
  
  I don't waste my time with meaningless irrelevant stuff. Either a tech stack serves it's purpose, or it doesn't. I don't have enough free time to waste it trying to cancel others.
  
  1

As hard as it is to say this, unfortunate code breaking changese are going to be made. But only if they help achieve the goals listed above.

If this is the case then I think it is an incredibly bad choice to name it D or openD or anything similar

Names are really hard, but non compatible things should not share a name.

One of the coolest things the perl community ever did was changing the name of perl at the major version when perl 5 came out. That is so smart!, and should be the way all software projects function.

1