[tastyminerals]

Noice! Reading through the release notes leaves a feeling of D being a mature language long enough.

If you're looking for magnitutes faster scripting alternative to Python like once me, take a peek!

[throwaway_pdp09]

I'll read through the article but is D really like python in any way? functionals, closures, comprehensions, decorators etc.?

[tastyminerals2]

Anonymous lambdas instead of comprehensions, delegates instead of closures. D does not have decorators in the sense Python does, well function attributes might come close. What I do enjoy in D syntax-wise is UFCS: https://tour.dlang.org/tour/en/gems/uniform-function-call-sy...

Array slicing, ranges, compile-time execution. Probably the most succinct and easy-to-read syntax out of many compiled languages. It's an investment (as with any other language) but the learning curve is not steep if you get scared away by C++ or Rust for that matter. Julia comes to mind too in terms of syntax but no UFCS and its interoperability with C++/C looks like a lot of work compared to D.

[ttymck]

UFCS is awesome, I had no idea it existed! Implicit classes are my favorite feature of scala[1], I agree .chain syntax is infinitely more readable.

[1] https://riptutorial.com/scala/example/7538/implicit-classes

[tastyminerals2]

Unlike in Scala, you can chain your custom methods in D.

For example, seqOfChars.map!(a => a.toLower).filterIfNotDigitChar.sort.uniq; is simply not possible in Scala.

Here is a great presentation about fp in D: http://beza1e1.tuxen.de/stuff/FunctionalD.pdf

[rbonvall]

It is possible in Scala: https://scastie.scala-lang.org/k7bHR6EWS7qXvaC8gIj3VA

(Unless you mean something different).

[tastyminerals2]

True. I forgot about implicits (because I try not to use them :).

Unfortunately it looks more like a kludge tbo. Sort and uniq get also hidden in a class which can be tucked away from your eyes and this is never good.

[qznc]

Thanks for calling my presentation "great". I don't design my slides to work without me talking though.

The official tour has a short page about FP as well: https://tour.dlang.org/tour/en/gems/functional-programming

Anyways, since Walter is probably reading this: Any new insights around this quote five years later?

> I know a lot of the programming community is sold on exclusive constraints (C++ concepts, Rust traits) rather than inclusive ones (D constraints). What I don't see is a lot of experience actually using them long term. They may not turn out so well. –Walter Bright

[hellofunk]

It would seem that D and Nim have many similar goals and features.

[tastyminerals2]

Yes, they are frequently compared. If you like style-insensitive (case insensitivity, underscore ignored) languages with hacker mentality, Nim is for you. This is simply a no-go for me. I briefly tried Nim before even knowing about D and it never stuck with me due to awkward syntax (subjective). Later I learnt that Nim (being a younger language) frequently breaks backward compatibility. Maybe it changed now but all the above was enough to pass it and move on.

[pjmlp]

What I dislike is the {. .} annotations, Active Oberon also followed that path and I don't find it that great.

[throwaway_pdp09]

Some context would be nice - can you say a little more on that annotation please.

[bachmeier]

The way to interpret that statement IMO is that D is a good alternative to using a scripting language. I use it that way all the time - it's almost completely replaced Ruby, which was my previous scripting language of choice.

[macleginn]

What about the standard library?

[qznc]

Not as comprehensive as Python.

However, you can write scripts which pull in packages from the internet called "single-file packages": https://dub.pm/advanced_usage

Just tried it myself for the first time:

    #!/usr/bin/env dub
    /+ dub.sdl:
    name "hello"
    dependency "requests" version="1.1.5"
    +/
    import std.stdio : writeln;
    import requests : postContent;

    void main() {
      auto content = postContent("http://httpbin.org/post",
          ["name": "any name", "age": "42"]);
      writeln(content);
    }

On Linux, put this into a file, chmod +x it, and execute. The first time it will take a while (downloading and compiling packages). After that on my crappy laptop it takes:

    0.66user 0.06system 0:01.25elapsed 57%CPU
    

That is a lot more convenient than venv in Python.

[badsectoracula]

> D being a mature language long enough.

I do not follow D closely, but i get the impression that the language breaks backwards compatibility every now and then - i remember some posts here or Reddit some months ago by someone complaining that Walter Bright introduced some changes to the language that broke existing code.

IMO a mature language is a language that you can depend on for your existing code to keep working in a timespan of decades - like C and C++ for example. A language that willingly breaks backwards compatibility is a toy, not something to be taken seriously for long term work.

[qznc]

The Wikipedia page history section [0] talks about stability. The most relevant part is this:

> The release of Andrei Alexandrescu's book The D Programming Language on June 12, 2010, marked the stabilization of D2, which today is commonly referred to as just "D".

In other words, D is backwards compatible for 10 years now. At least, I don't know any breaks and the little code I have in D never broke.

The transition from D1 to D2 did break backwards compatibility in 2007. The change is comparable to the Python2 to Python3 transition but in a much smaller community. Outdated news from that time still pop up sometimes. Maybe you heard something related to that?

[0] https://en.wikipedia.org/wiki/D_(programming_language)#Histo...

[badsectoracula]

So basically if i write some D code now it'll keep working (assuming no OS ABI changes) and compiling in 20 years from today? I'm ok with very minor changes due to compiler bugs or whatever.

I wonder what that complain was about then.

[Zardoz84]

I have code that I wrote on D like in early 2010's, and keeps working with very minor changes.

[pjmlp]

Then I guess C and C++ are toys as well, given there are a couple of breaking changes.

K&R C, gets, Annex K, VLA, gone by now in C17.

gets, exception specifications, external templates, std::auto_ptr now gone, RVO semantics changed, and a couple of other minor semantic changes by C++20.

[badsectoracula]

Nobody has removed support for gets nor VLA (of those that bothered to add them in the first place) or anything else they provided.

TBH i'm not sure about modern C++20 since that has been a shitshow anyway.

[pjmlp]

Apparently you have to update yourself with ISO C contents.

Hint, there are more C compilers out there than clang and GCC.

[badsectoracula]

I know, i've tried a bunch of them and have several C compilers installed but AFAIK none has removed support for gets or VLA (or anything else they bothered to implement). When i wrote "none" i wasn't referring to the standard but to the actual compilers. I do not care what the standard says is deprecated or to be removed, what i care is what compilers actually do since that is what affects existing code.

[MaxBarraclough]

Have VLAs really been removed from the C language? I can't find a source for this.

[schlupa]

What happens some times is that changes in the compiler fixes issues that were not well defined in the specification, or were bugs in the implementation. Programs that used the feature wrongly or that were in fact buggy then break when compiled with the better specified feature. It's comparable to compiling a K&R conforming C program with C89 or C99 enforcing: it will reveal bugs that were none in K&R (type punning, uninitialized variable, prototype violations, etc.).