Live data from Hacker News

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

dpldocs.info

31–40 of 322 posts

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

#31
post #29
post #23

Earlier quoted context omitted.

That’s a subjective matter of taste.

Yes, but I think you'll find that many people tend to resist change, including drastic syntactic changes (as compared to how languages like D iterate on previous languages like C++).

Rust specifically changed its syntaxes to resemble C++. For example the turbofish syntax `::` is actually a highly bad choice by its own, but was deemed more familiar to C++ users who are used to `` (which was too ambiguous so had to be tweaked though). Even `return` was spelled `ret` back then!

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

#32
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.

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.

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

#33
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.

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.

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

#34
post #15
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.

Meanwhile Rust is noncompelling due to its syntax. It made a bunch of weird design choices (like putting class methods in separate `impl` blocks) that have ruined my chances of trying to use it for any personal projects.

There are a plethora of languages that allow implementing methods outside of a class block, including Java, Kotlin, Haskell, C#. And many of them are mainstream. Your argument seems weak.

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

#35
post #29
post #23

Earlier quoted context omitted.

That’s a subjective matter of taste.

Yes, but I think you'll find that many people tend to resist change, including drastic syntactic changes (as compared to how languages like D iterate on previous languages like C++).

Rust syntax isn’t really that novel. It’s not exactly like C, but most of its syntax is pulled from some popular language: some from C, some from JS, some from Python, some from ruby, etc.

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

#37
post #15
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.

Meanwhile Rust is noncompelling due to its syntax. It made a bunch of weird design choices (like putting class methods in separate `impl` blocks) that have ruined my chances of trying to use it for any personal projects.

You make it sound like Rust made these choices for the heck of it, whereas there are very good reasons why impl blocks are separate from the struct:

1. Make class methods open to extension. This allows adding methods from other contexts, including other privacy contexts. Sure you could have dedicated syntax like C#'s extension methods, but these were added after the fact. If starting your language from scratch, while have two distinct syntaxes, when one will do?

2. Allows to add methods that only exist for some combinations of generic parameters. For example you can have a generic `Foo` class, and then define a method `from_bar` that only exists for `Foo`. Again, impl blocks may not be the only solution to this, but it is a highly cohesive one.

3. Lastly this is more philosophical, but it decouples the data definition from the method definition.

Not wanting to try Rust because its syntax is unfamiliar has to be the weakest reason, especially when the syntax has excellent reasons to be different.

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

#38
I witnessed a similar case while touring D as an outsider. When Rust was new and the concept of lifetime was brought to the D community, it was deemed unnecessary by Walter. A few years later, he brought his own lifetime proposal that is sufficiently different to Rust's and thus even less verified compared to the previous suggestion from the community. Now that I lost my interest in D, I'm not sure of the maturity of the new lifetime feature, but I would be surprised if it is as useful as Rust's.

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

#39

I witnessed a similar case while touring D as an outsider. When Rust was new and the concept of lifetime was brought to the D community, it was deemed unnecessary by Walter. A few years later, he brought his own lifetime proposal that is sufficiently different to Rust's and thus even less verified compared to the previous suggestion from the community. Now that I lost my interest in D, I'm not sure of the maturity of…

So now you can have a project with someone else's opinion instead of Walter's.

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

#40
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` for example is known to be such case, explaining a functioning but generally unsatisfactory design.) Go is a rare exception where the core team had no reason to honor all stakeholders and enough resource and willpower to do so, and yet some drama did happen.
Post reply on HN