Live data from Hacker News

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

dpldocs.info

181–190 of 322 posts

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

#181

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 general purpose programming language similar to Python but most would agree that in computing sense it is more general than Python since the latter is rather limited in hardcore HPC domain (bit twiddling, etc).

The fact that most of today's programmer or in the future will be just fine and better off with GC based languages compiled or interpreted, as modern drivers are better off with auto transmission than the manual. Heck, even F1 drivers now compete in auto transmission (DCT).

The fact that D is embracing GC as a default is not a disadvantage but it is advantage for majority of the programmers [1]. Imagine a world in the near future where D is as popular as Python due to its intuitive syntax thus more library will be written for D and thus the library eco-system is flourishing regardless you are using enabled the GC or not with D [2]. Imagine a world where you don't need to write in Python and interface in a wrapper for library in foreign language that only selected few can understand because most of original library authors have passed away since the core are using language originated from the 50s and the library was developed in the 70s [3]. Imagine a world where only programming language with GC can be JIT to wasm [4].

[1]Go: What we got right, what we got wrong:

https://news.ycombinator.com/item?id=38874952

[2]Stop Designing Languages. Write Libraries Instead:

https://lbstanza.org/purpose_of_programming_languages.html

[3]Programming in Modern Fortran:

https://cyber.dabamos.de/programming/modernfortran/blas.html

[4] WebAssembly Garbage Collection (WasmGC) now enabled by default in Chrome:

https://developer.chrome.com/blog/wasmgc

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

#182
I fail to see any negative aspects of having multiple compiler implementations around.

IMHO that's the main reason why C became so popular, compilers are free to explore into different directions, language extensions that have proven their worth will eventually be picked up by other implementations, and sometimes even make it into the standard without being butchered too much by the committee agreement process.

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

#183
post #177

Earlier quoted context omitted.

I'd get what I import (explicitly). If I import conflicting extensions then its my fault for doing so and (only) my program fails to compile.

You cannot import specific inherent methods. What you can do though is use the extension trait concept and import those traits. If you import both traits you get an ambiguous function error and are asked to resolve which trait you want ` ::fudge(...)`.

Ah, I was not aware of extension traits. Thanks for pointing out.

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

#184

[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 than extending the language.I'd say are spent about 30% of the time re-factoring just for this.If I open source my work, I will reject code that is not up to my standards for the same reason that Walter does.

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

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

Or Go... Or among the new kids on the block - Mojo.

Heck, even .NET is pushing NativeAOT (their brand name for native code compilation) hard these days. Still with sizable gaps but closing for every new release, and you can now develop full fledged desktop apps or a web service and have it be self-contained with native code.

I think .NET in particular is a harbinger for D. When even a "managed language" platform at its core goes native code, and with Microsoft's industry backing giving an entirely different angle of attack than D's minimal defense, you just know it's over. D will live on but in the way Amiga, SNES, ZX Spectrum lives on among enthusiasts.

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

#186

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.

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 compilers). I'm talking about a hypothetical future milestone where the software world's core infrastructure comprising LLVM/Clang and* GCC is written in the "replacement language", i.e. the compilers for a bunch of other (non-PLₓ) languages—including C and C++—are written in PLₓ as well. The backends, at least.)

* "or"?

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

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

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

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

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

Java is slow is a really old myth. It was once upon a time. Ofc there are caveats but looking at your average developer ... You will be fine.

On the other hand I would forbid an average developer the use of c/c++ and similar. It is just not worth it.

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

#190
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

I've had the same experience - I spent 6 months last year really digging into Rust and came to the conclusion that for the software I'm writing it's trying to save me from problems that I just don't run into enough to make it worth it.

I ended up jumping over to Zig and have been really enjoying it. I ported the same hobby 2D game engine project from C++ to Rust, and then over to Zig. A simple tile map loader and renderer took me about a week to implement in Rust and 3 hours in Zig. The difference was a single memory bug that took 15 minutes to figure out.

Post reply on HN