Live data from Hacker News

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

dpldocs.info

111–120 of 322 posts

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

#111

Earlier quoted context omitted.

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++.

I don’t disagree. Add in the GC and you’re competing with C#, which is an unwinnable battle considering the resources of MS. Dump the GC and you’re competing in a much more winnable battle with C++, Rust, and that’s it (when the decision was made anyway).

And Java, with GC implementations being able to manage TB sized heaps in pauseless server implementations, or tiny heaps with real time GC in embedded bare metal deployments.

D's GC problem is being a very old approach on how to design one.

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

#112
post #63

Earlier quoted context omitted.

I’m not sure I’ve ever seen him comment here on a D related post. Which I totally understand.

I've definitely seen him discuss D here when it comes up.

Only when D itself isn't the matter being discussed.

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

#113
I know that calling it "FreeD" is probably a bad idea but I would have thought it was real clever. I've toyed with the language before and it was always enjoyable, just lacked the library/compiler support that I need for the sorts of things I'd use D for so I've stuck with C, looking forward to trying again in a couple years if this sticks!

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

#114
post #97
post #94

Earlier quoted context omitted.

> A would be an excellent choice were it not completely un-googleable. APL is named after the book A Programming Language

The ultimate language will be TPL (the programming language)

TUPL, no?

Even better if it only worked with tuples.

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

#116
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 is for people who stick around, can come over hurdles, can take in new concepts and see the overall benefits. It has a steep learning curve that pays off.

For me there are three reasons why Rust is suitable for many usecases:

- performance

- safety

- static binary compilation with targeting different cpu architecture

After spending majority of my time with Python and Java in the last 10 years these are things i really learned to appreciate.

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

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

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

#118

Earlier quoted context omitted.

Your suggestions are moving backward, and GC by default and no macro made D intuitive and Pythonic that are big plus in any modern programming language construct. The non GC is not really needed unless you're working on OS control primitives but again D give you alternative unlike Go. Every modern languages should avoid macro like a plaque otherwise you will sooner or later create a ghetto inside your community not u…

Then, D will compete with GC languages that outclass it in ecosystem diversity and metaprogramming.(i.e. it will remain same niche language it was for decades). Having a huge runtime with GC doesn't seem appealing or efficient.

Fret not, Python just a fringe programming language for more than two decades, it only then become popular. If you have the right fundamentals success will eventually come your way.

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

#119
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…

>> What kind of solution would you propose to folks like your boss?

How do you want to play this boss? I can see you’re focussing more on the bigger picture and the code is just a means to an end, given that, how about you delegate technical leadership on the codebase to me to let you focus on the product & commercial aspects?

If no - maybe words come back to the effect of “it’s my pet/child, how very dare you” yadda yadda - then I can’t see a happy path beyond “thanks for the opportunity, all the best for the future” but there’s certainly room for many mediocre outcomes short of parting ways if that’s preferred.

If yes - “hey, we don’t have infinite money and we prob can’t afford to hire the help to do this to a gold standard so how about we agree these commercial milestones (once change delivery falls below X days on average, or once feature Y that you always wanted lands in prod, or once the defect rate drops below Z per week etc etc) - I get bonus $$$”

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

#120
post #110

Earlier quoted context omitted.

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++.

Easy, see the use of Oberon, Java, .NET in bare metal IoT deployments. PTC, Aicas, microEJ, Astrobe, Meadow,... The problem isn't having a GC, is its poor implementation.

> The problem isn't having a GC, is its poor implementation.

OTOH Java and .Net exist and have large investment (D is younger than C#), so for people who are fine with GC, there are already plenty of "C++ alternatives". What's left is people who can't or won't use a GC, and for them a GC'd language can not be an alternative.

Post reply on HN