Live data from Hacker News

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

dpldocs.info

191–200 of 322 posts

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

#191

Earlier quoted context omitted.

Python is a interpreted language, and is both strongly/dynamic typed D is a native strongly typed language You don't make game engines in Python, and certainty not drivers, python devs fall back to C when they need performance, this should give you a hint

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…

Julia depends on OpenBLAS by default, but faster pure-Julia packages are available, too.

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

#192

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.

Is the field of competition so ripe here? I'm seeing Go, but what else?

It seems a lot of the other languages:

- don't have an easy compilation story (interpreted, VM, compilers as secondary implementations)

- lean more on the functional side (Ocaml, Haskell)

- otherwise clash with the common BCPL-family mindset (Oberon, arguably Go)

There definitely seems room for an "easier C++". Heck, given how popular Rust is due to backing and support from the functional crowd, leaning into ease of use and imperative programming might be a sufficiently large niche.

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

#193

[flagged]

This is a nasty comment, and lacks any references to those github PR discussions. It comes across very much as somebody who has no experience in managing even halfway large projects. I've been writing a compiler and I put in a lot of work to keep things simple, manageable and comprehensible, and therefore most likely correct. If I hadn't, I'd be stuck in a swamp of bad code and spending more time fixing old problems…

It is, and written mostly out of disappointment after reading the pr discussions. I still believe that Walter should have at least addressed it instead of going circles and acting as if nothing is happening. It is clear that what has been behind the scenes for years just poured out now and unsurprisingly it doesn’t look nice. We can talk volumes about how hard it is to manage large projects and keep everyone happy when in the end nobody cares if there is no progress. Weka ppl pretty much upfront said it.

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

#194
post #123

Earlier quoted context omitted.

According to the followup a week later[0] it seems OpenD is doubling down on GC: > One of the guiding principles of this fork is to embrace the GC as a successful design rather than to shun and avoid it. [...] I have harshly criticized @nogc in the past as putting a disproportionate burden on library authors while being the wrong answer to what can be a perfectly fair question. [0] https://dpldocs.info/this-week-in-d…

The GC works fine. Why waste energy to duplicate the functionality that requires it? Programmers who don't want the GC are already using C++ or Rust instead. The GC is one of those tools that makes programming in D productive. The lack of libraries and modern tooling is the part that ruins it. That's why you get software written in Go and Java instead of D. I'd love to use it for embedded work instead of C and C++, e…

> Programmers who don't want the GC are already using C++

Sure, but this was in a response about D substituting C++.

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

#195
post #90
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…

If you're put off by key leaders talking down to people, I think you'll want to spend some time in Nim's forum and issue tracker before considering it as an alternative. (YMMV, of course, but I was put off by what I found.)

FYI, some members of the Nim community are working on a fork, for apparently similar reasons as OpenD (community-led development). https://github.com/nim-works/nimskull under active development and not ready for general consumption though, from my understanding.

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

#196

Earlier quoted context omitted.

This is a nasty comment, and lacks any references to those github PR discussions. It comes across very much as somebody who has no experience in managing even halfway large projects. I've been writing a compiler and I put in a lot of work to keep things simple, manageable and comprehensible, and therefore most likely correct. If I hadn't, I'd be stuck in a swamp of bad code and spending more time fixing old problems…

It is, and written mostly out of disappointment after reading the pr discussions. I still believe that Walter should have at least addressed it instead of going circles and acting as if nothing is happening. It is clear that what has been behind the scenes for years just poured out now and unsurprisingly it doesn’t look nice. We can talk volumes about how hard it is to manage large projects and keep everyone happy wh…

OK, so please show me those discussions and change my mind.

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

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

> D went from a language that I remember back in 2015 was often promoted on places like reddit and here as a fresh alternative to C++ that was constantly evolving

I wrote a blog post in 2012 about D [1]. In my personal experience, the high point of D was around 2008-2009. It was already declining in popularity in 2012, IMHO, due to intense clashes within the D community and the rise of Go, Rust and C++11 outside the community. D remains one of my favorite languages but I agree with you that Rust, Nim or Zig is the better choice for most programmers today.

[1] https://attractivechaos.wordpress.com/2012/02/28/timeline-of...

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

#198
post #186

Earlier quoted context omitted.

Don't we consider a C/C++ replacement "successful" when it was able to capture enough share of prior C/C++ uses, not the entire share? I never thought C or C++ could be completely gone out of sight, even COBOL is technically alive today (on life support). To be clear, I meant that D could have been in the position of Rust today if done right.

I wouldn't consider a C++ (or C) replacement PLₓ successful until the people working on big compiler toolchains—many of whom are committed alternative programming language advocates themselves (consider the origins of e.g. Swift and LLVM)—decide that, moving forward, those will be written in PLₓ rather than C++. (Note that the bar I'm establishing here is not merely to have a self-hosted compiler (see many toy compil…

While I do hope that future, it is an unreasonably high bar because the main value of LLVM is that you don't have to make everything again to make your own PL implementation. For the same reason contemporary web browsers are unlikely to be fully rewritten in any other language unless they get completely displaced by newer browsers. (At least LLVM has a better chance of being replaced...)

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

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

Memory safety issues in C++ have two main causes. One is object lifetime. The other is pointers. If at all possible you want to design your program such that object lifetime is completely obvious and predictable. Use sentinels and tombstones instead of null pointers. Use arenas wherever possible. During debug use an allocator that doesn't reuse memory (just mark the pages as no access so you will segfault when trying to read/write in previously freed memory). When object lifetime is complex you can give objects a "color" during allocation and then make rules that you can verify that objects of one color can never have pointers to objects of another color, or that an object can never contain a pointer to a younger object. You can eliminate entire categories of memory problems this way. Instead of pointers use indices and a getter function. In debug mode the getter can check if the right locks are held, scan the heap for incorrect pointers, check for ownership flags, etc. Actually take advantage of the virtual memory tools provided to you by the operating system. Threadlocal memory. Fork tasks into different processes. Actually use mprotect and the like.

Zero memory safety mistakes is a tall order. But the overwhelming majority of memory errors we see in the wild can be easily prevented by good practices. And for the memory errors that do happen stack protection flags make a big difference (https://developers.redhat.com/articles/2022/06/02/use-compil...).

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

#200

Earlier quoted context omitted.

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…

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 more like the last desperate effort to change things.
Post reply on HN