zombinedev

Regarding GtkD, you may find this blog interesting: https://gtkdcoding.com/

> I hate code like `1.writeln`

Meh... after not more than my first month into D this syntax grew on me and now I just use `1.writeln` everywhere. More than a few years later, I can't think of a single issue this has ever caused me.

It's ok now, as far as I can see.

Initially coming from C++ background, e.g. I had good understanding of its ownership model with move vs copy semantics (unique_ptr vs shared_ptr), I read many Rust blogs, watched a couple of tech talks and read several chapters of the book, so everything looked super promising. I even spend reading about linear and affine type theory.

But I can testify that spending my first days with Rust was a struggle the whole way. It's probably because D had spoiled me a lot by the time I got to Rust. After some time I lost interest as Rust didn't offer anything that I was actually missing in D, while D had much to offer in the areas of things I liked.

You're mistaken. By default D statically links all D dependencies (leaving only libc and possibly OpenSSL (if you need it)) to be dynamically linked (which has it's advantages), but if you want you can statically link all dependencies (including the C ones), just like you can with C or C++. D produces the same format of object files as C/C++ which makes this just as easy.

To escape the shit show that C and C++ are in their unique ways. In my experience, one of the worst things was working on a proprietary 1M+ LoC codebase. Everything was so painful (despite the feats of engineering being put in the internal infra to support the development processes and the great team members I worked with) that I'll never go back to anything like that if I have the choice.

I'm also dissatisfied with some of the design decisions accepted into C++11/14/17/20. (Some were fixable and just plainly shortsighted IMO, but others probably not, due to the language legacy).

Don't get me wrong, I love learning from the C++ community (conferences, tech talks, blogs and checking out how open-source projects that I'm interested in are implemented), but once that I had tasted the power and freedom of D going back to C++ feels like a huge step in the wrong direction.

And also being not only a user, but a contributor is immensely empowering. A PR to the standard library, runtime, compiler or package manager can take anywhere from days to mere hours (depending on the complexity of change), while attempting a change with a similar impact to C++ would likely take anywhere between months to years. And yes, I can see the value of the ISO C++ standardization process, but it's definitely not for me.

If you have a half million codebase that you need to migrate, I would say that every heavily used Extended Pascal feature is required to be easily translatable. If it's simply possible but the translation is not direct or easy, then the maintainers may be better off staying with Ext Pascal than maintaing a half million uglified code base.

It is not described in the betterC page as these features are not new for D. The betterC page only describes the differences versus the full D feature set.

Documentation for the individual features mentioned:

http://dlang.org/spec/function.html#safe-functions

> array overflow checking

http://dlang.org/spec/arrays.html#bounds

> guaranteed initialization of locals

http://dlang.org/spec/type.html http://dlang.org/spec/declaration.html#void_init

> no more stray pointers into expired stack frames

DIP1000 describes D's scoped pointers approach to memory safety - https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md. This is work in progress and the document doesn't reflect latest state of things. Conceptually, scoped slices/pointers/references are similar to concept of borrowing that you guys have in Rust.

D provides the same low-level access as C. Heck, in D you can even use inline assembly, so there are really no barriers to what you can achieve. MMaping files and casting their contents to structures is often used technique. The GC only one of the many ways of getting memory in D. You'll just have to manage the other ways yourself like in C or C++ ;)

D has quite good multi-dimensional array support, though probably not as flexible as Python. One of the best libraries in this area is ndslice (part of mir-algorithm) - http://docs.algorithm.dlang.io/latest/index.html. See the "Image Processing" example to get a sense of API - http://docs.algorithm.dlang.io/latest/mir_ndslice.html. mir-algorithm is the base for the high-performance glas implementation written in pure D that outperforms libraries with hand-written assembly like OpenBLAS in single-threaded mode (multi-threaded is not yet ready). See http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/.... (Note that this blog post is bit outdated - since then the author rewrote large parts of the library, IIRC.)

If you're interested in high-performance scientific computing, then I guess you'll pleased to know that many use D for this domain, specifically for its high-performance and also high-level features that make prototyping as easy (if not easier) as in Python. In addition to good C/C++ interop, there are also libraries for interfacing with Python and R. Be sure to check http://blog.mir.dlang.io/, https://github.com/kaleidicassociates/lubeck, https://github.com/libmir, https://github.com/DlangScience and https://www.youtube.com/watch?v=edjrSDjkfko

Yes, in this example, but once you start looking at more interesting pieces of code it becomes close to impossible for C beat D without heavy use of macros on the code readability front. Check the runnable examples on the front page - http://dlang.org/.

RAII in not removed by design. It is just work in progress. It will be added to -betterC when its implementation is more mature for this mode.

Can you compare your D vs Nim experience in more detail? What are the key points that you like better about Nim?

I think the main factor is that the primary contributor to GDC (Iain) made a giant push for this to happen in the last 6-12 months. Just look at this graph: https://github.com/D-Programming-GDC/GDC/graphs/contributors

Great work, Iain!!!