Earlier quoted context omitted.
> languageS that Come and go, And then are swift to become popuLar, but then Are > languageS Come And popuLar Are > S C A L A Did I do that right?
I think you hit that Node, with a ruby of a pun, and are on the right railroad tracks my friend.
The reference D compiler is now open source
161–170 of 313 posts
Re: The reference D compiler is now open source
#162Please don't get me wrong, as I don't want to start a flame here, but why do they call D a "systems programming language" when it uses a GC? Or is it optional? I'm just reading through the docs. They do have a command line option to disable the GC but anyway...this GC thing is, imho, a no-go when it comes to systems programming. It reminds me of Go that started as a "systems programming language" too but later switch…
D's garbage collector is both written in D and entirely optional, that alone should qualify it as a systems language.
The gc can be disabled with @nogc, the command line flags are only if you want to disable it for the whole program or if you want warnings as to where the allocations happen. https://godbolt.org/g/IQ0O06
Re: The reference D compiler is now open source
#163Earlier quoted context omitted.
> Each of dmd/gdc/ldc has their individual strengths and styles. I'd be really interested to hear a comparison of those from someone experienced with D and its community.
Professional D coder here. - DMD is by far the D compiler with the shortest compile time. It's actually so fast that it comes with a utility, 'rdmd', which compiles-then-execute a D program. Say goodbye to shell/perl/python scripts, now you can have compile-time checks without an explicit/slow compilation step. We use it for automation tasks. - GDC is the compiler of choice when it comes to supporting multiple target…
(Disclaimer: LDC developer and former maintainer here.)
> GDC is the compiler of choice when it comes to supporting multiple targets and cross-compilation.
That entirely depends on what your targets are. GDC has some claim to "support" more architectures than LDC in that it can generate code that interfaces with C for just about every target GCC implements. However, this is only part of the story – "support" is a dangerous word to use here, as full-blown D runtime support is much more limited.
If you look at the most common platforms for desktop and mobile applications, LDC is definitely in the lead – in particular, LDC targets Windows/x86 (both 32 and 64 bit), macOS, iOS and Android/ARM, neither of which GDC supports. Some other platforms like AArch64 or PPC64 are beta quality on LDC, but have not received significant work on GDC. Both compilers support Linux/ARM (but admittedly GDC might be a bit more stable there).
> The generated code is fast (more than LDC)
[citation needed] This doesn't match my experience. More often than not, GDC and LDC are pretty much head to head, apart from small differences either way from the different backends (GCC vs. LLVM). In addition, LDC can benefit from some (minor) D-specific additions to the backend optimizer and some target-specific standard library optimizations, though, and sometimes has performance fixes that have not landed in GDC yet.
weka.io (one of the biggest D deployments, high-performance software-defined storage) and the Mir numerics library (very competitive performance numbers) both use LDC. If you have a real-world example where GDC generates significantly better code than LDC, please consider reporting it on the LDC issue tracker so we can look into fixing it.
Re: The reference D compiler is now open source
#164Earlier quoted context omitted.
Professional D coder here. - DMD is by far the D compiler with the shortest compile time. It's actually so fast that it comes with a utility, 'rdmd', which compiles-then-execute a D program. Say goodbye to shell/perl/python scripts, now you can have compile-time checks without an explicit/slow compilation step. We use it for automation tasks. - GDC is the compiler of choice when it comes to supporting multiple target…
How good is D for: -iOS? -Android? -Windows?
Ios kind of works but is lacking bitcode on mobile devices.
Lacking a bit wrapping of system and gui calls but for android see dlangui and Jni is not so bad.
It's very practical to write libraries in D. Possible to write whole apps, but I wouldn't start there for now.
Re: The reference D compiler is now open source
#165Earlier quoted context omitted.
Professional D coder here. - DMD is by far the D compiler with the shortest compile time. It's actually so fast that it comes with a utility, 'rdmd', which compiles-then-execute a D program. Say goodbye to shell/perl/python scripts, now you can have compile-time checks without an explicit/slow compilation step. We use it for automation tasks. - GDC is the compiler of choice when it comes to supporting multiple target…
How good is D for: -iOS? -Android? -Windows?
On Windows it's fine, but same library packaging problems as for C++...
Re: The reference D compiler is now open source
#166Earlier quoted context omitted.
Also, how does D compare to Rust? (If I'm going to learn a new system programming language, which one should I pick?)
My early impression with Rust is that it's more ambitious than it is capable of delivering. Lifetime annotations in particular are incredibly ugly. It's the kind of thing that makes me think: "...ok, so this is why other languages don't simply do static lifetime checks" and I guess I expected Rust to be the solution for that problem; it is instead not a solution, but the deliberate decision: "let's do static borrow c…
Note that the vast majority of lifetimes in Rust are elided so that no explicit annotation is required. When the compiler can't figure out the annotations, or if you're declaring a type that contains a borrow, then you need annotations.
The annotations have, for the most part, faded into the background for me. I don't find them to be particularly pervasive in the code I write, and when I do need them, it's usually to fix a reasonably straight-forward case where the compiler failed to elide them. With that said, in the years I've been using Rust, I have committed one or two lifetime-related bugs. (No memory unsafety resulted, of course, but it did result in data being annotated with a shorter-than-actual lifetime.)
> In short, I thought Rust was "we solved the pain of this difficult thing."
Part of the pain that Rust purports to solve is the significant reduction (and debugging thereof) of memory unsafety errors. In return, you must deal with the pain of an ownership and borrowing system, which might present challenges to patterns you may have used in another language. The benefit is that you have a compiler to tell you when you've mis-stepped instead of an end user filing a bug report (or worse).
Re: The reference D compiler is now open source
#167Anybody worked on performance critical stuff in D? How good is its GC?
Weka.io develop a software-defined distributed storage system in D with latencies well below a millisecond (over Ethernet). They use the GC in some parts, but avoid it on the hot path as much as possible as it is a simple pause-the-world mark-and-sweep collector.
All in all, the GC isn't as much of an issue for high-performance applications as is sometimes claimed, but all the recent work towards reducing the dependency on it has of course been done for a reason – in performance-critical code, you often don't want any allocations at all (GC or not), and the large jitter due to collections can be a problem in some situations.
Re: The reference D compiler is now open source
#168And best of all, it's the Boost license! Here it is: https://github.com/dlang/dmd/pull/6680
Does that mean that the backend can be rewritten in D at some point? Speaking of which, there could be a standard D intermediate language (Or is there one? I've never at the glue code in between the frontend and backend/s)
Re: The reference D compiler is now open source
#169Earlier quoted context omitted.
> languageS that Come and go, And then are swift to become popuLar, but then Are > languageS Come And popuLar Are > S C A L A Did I do that right?
I think you hit that Node, with a ruby of a pun, and are on the right railroad tracks my friend.
Yes, he's certainly Going Forth.
Re: The reference D compiler is now open source
#170Earlier quoted context omitted.
Why does gc disqualify a language as a system's language? P.S. I think of a system's language as one that runs directly on the machine, e.g. Swift, C, go. They operate at the "system" level.
Could one write a driver in D?
Yes – there are a number of research and/or hobby projects that implement kernels, drivers, etc. in D.