Live data from Hacker News

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

dpldocs.info

211–220 of 322 posts

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

#211

Earlier quoted context omitted.

It's worth pointing out that Walter is one of two co-maintainers of the language. The other has not said anything at all. On the other hand, I'm not sure what there is to say if they're not going to make any changes in the process. I'm far more concerned about community development of libraries, IDE support, and the beginner experience (especially on Windows) than I am about changes to the language, which is already…

Aren‘t these connected? Its about the contribution culture. If there is so much pain that it led to a language fork, what IDE and quality of life improvements from a shrinking community can we talk about? When I started with D several years ago, there were a few meetups and active contributors. These ppl now have left D for Rust and now we have this fork. Does it look like there is success ahead? I would say it looks…

I view them as two separate issues. On the one side, there are the complaints about language changes. It's hard to convince Walter to change the language, and it's hard to contribute to the compiler and/or standard library (those are the complaints, true or not).

Then there are problems for users of the language not having enough libraries and a sub-par IDE experience (again, true or not). Go and Rust built communities of programmers that aggressively used the language and made their work available to others. I don't see any reason we couldn't have more of that with the language as it currently stands. Adam certainly had no trouble knocking out hundreds of thousands of lines of nice libraries. Edit: And Ilya doing all his good work with Mir.

The first is a long-term problem. We'll see the effects ten years from now. The second makes it hard to have a reason to use the language right now (largely for anyone that doesn't want to write scripts or interact with C libraries). That's most of what concerns me.

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

#212

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.

They could go with TheD, to fill in the niche left by Coq now Coq's getting renamed.

> ... now Coq's getting renamed

Oh, didn't know that they are working on this.

https://github.com/coq/ceps/blob/coq-roadmap/text/069-coq-ro... and, of course, https://news.ycombinator.com/item?id=38779480

069-coq-roadmap.md? Oh, you!

So now we've got Rocq and Roc https://www.roc-lang.org/

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

#213
post #175

Earlier quoted context omitted.

Unless you happen to be using something like Rust/WinRT and to avoid the usual stop the world cascade deletion when smart pointers in a complex data structure all reach 0, have a background thread collecting those smart pointers.

There’s no plausible scenario in which I’d ever write a single line of Rust/WinRT.

Doesn't change the fact it isn't always obvious.

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

#214

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.

They could go with TheD, to fill in the niche left by Coq now Coq's getting renamed.

The TenaciousD?

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

#215
post #161

Earlier quoted context omitted.

What kind of solution would you propose to folks like your boss? One positive aspect I see about "rewrite it in Rust" is that you can to some degree expect a random Rust project to not leak and crash and expose vulnerabilities quite as much as a random C++ project. It's silly, but "written in Rust" acts somewhat as a badge of safety and performance, whereas "written in Java" and "written in C++" each only carry one o…

That example is really difficult, because between the lines it sounds like it has been working sufficiently well despite the cowboy style, substituting methodical error-avoidance with that special kind of brilliance of super deep code knowledge and remembering all the pitfalls. Very difficult situation. Regarding "rewrite in Rust", I believe that it's a smaller part of the appeal of Rust than it appears based on the…

You can do exploratory programming in Rust, it's just heavy on boilerplate code such as .clone() and Rc> which would be avoided when writing more idiomatically. Rust even includes support for dynamically typed references and downcasting via the Any trait. It's not as dynamic as Python/Ruby/JS etc. but it's not that far off either.

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

#216

Earlier quoted context omitted.

What kind of solution would you propose to folks like your boss? One positive aspect I see about "rewrite it in Rust" is that you can to some degree expect a random Rust project to not leak and crash and expose vulnerabilities quite as much as a random C++ project. It's silly, but "written in Rust" acts somewhat as a badge of safety and performance, whereas "written in Java" and "written in C++" each only carry one o…

How is a software written in Java having less assurances in terms of leaks/crashes etc compared to Rust? All Rust gives you is a borrow checker that isn't very smart, but means you don't need GC/VM, so you gain a bit of performance compared to Java. But if it's not software that needs to go fast, then Rust is not adding anything for you. And if you considered Java to begin with you probably don't need top tier perfor…

The most notable advantage of Rust compared to GC languages is low and stable memory use and predictable performance, that will not generally drop due to some random GC pause. Both of these can be of interest even wrt. software that doesn't "need to go fast" in any absolute sense.

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

#217

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.

FOKD - FOrmally Known as D.

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

#218
post #164

Earlier quoted context omitted.

I don't think Walter has ever intentionally talked down to anyone in my time, but his tone can be subtly belittling over some details. I don't think it's intentional but the argument always begins with explaining some detail as if you didn't know it existed even though you'd have to do be able to bring it up in the first place. This is not just me, I've had this discussion with a few people. One of a short list of co…

Time will tell how the maintainers of the fork will react to similar criticism. It's very easy to stand by the sidelines as a community member and to piss on the leadership, it's an entirely different thing to be in that position yourself. Ask GvR what it feels like to herd a band of cats over a period of decades. You need to be in it for the long run and you need to be utterly dedicated to make this really work.

> You need to be in it for the long run and you need to be utterly dedicated to make this really work.

There also has to be an escape hatch to make this work.

E.g., Linus can say that the __is_constexpr preprocessor hack is the product of a demented mind, and he'll merge that absolute monstrosity thanking the contributor.

As a leader you get the contributor community that you get. You can either make the development process workable for them, or you can risk the project languishing/forking.

Put another way: if a leader's concept of what their project ought to be/become veers too far from what the community is actively coding up to be merged, it's not going to go well.

No idea if this applies to D. But I'm absolutely certain Python's dev process has had plenty of escape hatches for resolving development issues. (And I'd guess there are also projects that have too many escape hatches, but I'm guessing that probably doesn't apply to D.)

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

#219

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…

I'm not too familiar with either Rust's or D's approach to lifetimes, but from some quick forum searching, it appears that adding Rust-like lifetimes to D would have required significant changes to the design of the language. Every potential feature has tradeoffs in terms of how it interacts with other language features, adds cognitive overhead, decreases compilation speed, complicates the design of the standard library, breaks backward compatibility, etc. I don't think it's reasonable to expect a large-scale overhaul just to support one feature you like from another language.

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

#220
post #77

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 is a frustrating language for me too. I never saw the need for it, really. I just stuck with the language constructs in C++ that makes it basically impossible for memory leaks/use after free/use outside of bounds to occur or if they do occur, explode loudly in debug environments. I haven't used new/delete in a personal project in like a decade; longer than Rust has been around. Now I'm working on a project where…

> I still don't need rust because I don't code like a crazy person.

This is not a foolproof argument because safety problems can easily result from unforeseen interactions among parts of the code that all seem to be OK and not "crazy" locally. A significant benefit of something like the borrow checker is that it can suss out these problematic interactions in a comprehensive way, even at the cost of forbidding some code patterns that would be perceived as safe in most cases. (Idiomatic use of Rust then requires you to either rewrite such code or stick it in an unsafe block and figure out what the preconditions are for it to be used safely.)

Post reply on HN