Live data from Hacker News

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

dpldocs.info

161–170 of 322 posts

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

#161
post #77

Earlier quoted context omitted.

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…

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 amount of code actually written: the main excitement is from people who never really ventured from heap+gc languages into manual memory management but who love the idea of being able to write gc-less native code. And many of them would rather write it slowly, one borrow-check at a time, than with all the memory bugs they created dipping their feet in naive C/++. Those people rarely write much Rust, but their excitement infects some in malloc/free land and for them a rewrite is super attractive because it skips the entire explorative part of software development that is really not the strong point of Rust.

(yes, this is pure projection, not only was I describing what draws me to Rust, I also failed to pick up on the codebase of my previous boss, too much "how can we make this entire thing less slow and error prone" and too little "cram in requirement X, even if it might turn out to become requirement Z because it pushed the codebase over the edge to terminal unmaintainability")

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

#162
post #105

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.

There are a lot of high profile Rust adoption stories where the developers involved are C and C++ experts. E.g. Rust in the Linux kernel, Rust in the Windows kernel, Rust in Firefox, Rust in Android.

I think the Rust in Firefox is probably the strongest in that list. Rust in Linux is just advocates trying to get adoption (not regular kernel contributors electing to use it).

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

#163
post #103

Earlier quoted context omitted.

which just means a different person is guiding the project

It’s about the policies and the culture that the leadership evokes, just like the leader of a country. It does matter who is in charge.

Sure. But the existing option is the inventors who started the project from nothing and have committed decades of their life.

Just like politics like you said, outsiders often think it's easy to come in and fix everything.

Dividing the community makes sense if things are going off the deep end or no longer being supported. It doesn't make sense in hopes of getting a slightly more efficient approval process.

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

#164
post #149
post #7

D is such a sad case of how a good technical product can fail due to poor leadership and decision making. A language is more than just a compiler, it's also an ecosystem and a community. D's community is actually very welcoming but man, watch some of the DConf videos and Q&As on Youtube and it's cringe seeing key leaders talking down to people, or dismissing people's concerns, or just have this ego about themselves l…

> it's cringe seeing key leaders talking down to people, or dismissing people's concerns, or just have this ego about themselves like they know what's best and everyone should shutup and just go along with them. That's not the case. The job of language designers is to say "no" all the time and Walter is certainly a model with how to speak with users.

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 complaints of this kind it must be said.

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

#166

What's Walther's take on the many gripes with the D leadership?

He pretty much derailed the D forum forking thread into remotely related tech discussion. This was weird to observe tbo, in the end my take is that he doesn't seem to bother much and would rather continue living in his version of the story.

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 pretty good. As a Linux user working on top of C libraries, the experience is incredible. That's not the case for everyone.

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

#167
post #77

Earlier quoted context omitted.

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 am yet to see someone who can't make memory safety mistakes in C++. You might want to start a tutorial series on how to do that. If this skill can be taught that is, and isn't genetic.

nobody is perfect, but some people create mnay less leaks than others. Modern C++ is the rules those who create few leaks follow.

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

#168
New governance models start with discussions about governance by a quorum of interested parties, not by dictating a new set of features or the decision to leave some out. That's just a change of regime, not a change of model.

I'm sure that there are legitimate gripes and D's reliance on Walter as gatekeeper may be too strict for some but the way this fork has started out doesn't bode well for the long term. Forks succeed only if they are carried broadly, you'd need to more or less pull a majority of the folks in the D community along rather than just a handful of prolific but ultimately low in number individuals because there is a fair chance that both your fork will fail and that you further fragment the mindshare of the original to the point that it too looses any viability that it still had.

You also need to be able and willing to support it for decades.

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

#169
post #164
post #149

Earlier quoted context omitted.

> it's cringe seeing key leaders talking down to people, or dismissing people's concerns, or just have this ego about themselves like they know what's best and everyone should shutup and just go along with them. That's not the case. The job of language designers is to say "no" all the time and Walter is certainly a model with how to speak with users.

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.

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

#170

Earlier quoted context omitted.

Sorry don't get your points, latest D compiler does support C native in addition to the much safer DasBetterC. D is even better you can do all things seamlessly in the same D ecosystem supported by GCC compiler suite by not even going to another language eco-system. Heck, D can be even be faster than Fortran and C++ for native HPC library seven years ago where Rust and Julia still revert to them for HPC routines unti…

Exactly, you achieve this by not embracing the GC, wich is not what this fork wants to do.. And Python's selling point isn't the fact that it has a GC, it's its interpreted/dynamic nature D is pragmatic about memory allocation strategy, this fork won't be

> D is pragmatic about memory allocation strategy, this fork won't be

Better than a pragmatic approach to memory allocation is to not have to think about it at all. For many applications, you can use the GC and not even know anything about memory allocation.

If you embrace the GC, you make a lot more progress, since you can add things to the standard library and the language quickly and easily. Users not wanting a GC should use something else. Catering to users that don't want a GC imposes a big tax on everything and everyone.

Embracing the GC doesn't mean they're going to strip out the reference counting and unique pointers already in the standard library.

Post reply on HN