D Language Front-End Proposed For GCC 8, 800k Lines of Code

[ldo17]

Simple lambda that takes two arguments, adds them, and returns the value:
C++:

[](auto a, auto b) { return a + b; }

Rust:

|a, b| a + b

D:

(a,b) => a + b

Python:

operator.add

[ldo17]

... except that it uses a garbage collector by default...

Any option to use automatic reference-counting as a first resort, before falling back to GC? This is how Perl and Python work. This should not be as cache-hostile as insisting on pure GC.

[reepca]

Python:

operator.add

Forth:

' +

Common Lisp:

#'+

Scheme:

+

I suspect the intent was to show the syntax for creating lambdas, though, not for getting a function that does the addition operation, in which case we're both putting the wrong stuff. Neat thing about forth is that lambdas become unnecessary for most uses - since there aren't named parameters (unless you go the route of local variables, which are generally discouraged), the difference between some arbitrary sequence of instructions and a function ("word" in forth terms) containing them is basically nonexistent. Closures are a bit of a different story, of course.

[carewolf]

English not your first language?


That are incredibly verbose and ugly just like the rest of the language. e.g, look at the lambda syntax

Simple lambda that takes two arguments, adds them, and returns the value:
C++:

[](auto a, auto b) { return a + b; }

Rust:

|a, b| a + b

D:

(a,b) => a + b

The C++ code is typed even if you chose to throw that away here. That makes it safer and slightly more verbose.

[peppercats]

The C++ code is typed even if you chose to throw that away here. That makes it safer and slightly more verbose.

all three of them are typed...

[cj.wijtmans]

The C++ code is typed even if you chose to throw that away here. That makes it safer and slightly more verbose.

it would be cool if c++ added => statement functionality to replace { return statement; } but i think the rest should stay.

[carewolf]

all three of them are typed...

Typing doesn't do much if you don't specify it explicitly. Type-checking is a system to match type expectation to type reality, type inference is dropping the type-checking and just use the inferred types.

[GreatEmerald]

Any option to use automatic reference-counting as a first resort, before falling back to GC? This is how Perl and Python work. This should not be as cache-hostile as insisting on pure GC.

Not sure about that, but I do know that they are looking at ways to decrease GC overhead (by making smarter GCs etc.) while simultaneously making more of the Phobos library not depend on it. IIRC Facebook uses D with GC off and it works real fast and scales well.

[profoundWHALE]

If I remember correctly, D is meant to be what C++ should have been, and Rust is meant to surpass C, and Go is to replace Java.

[kayosiii]

Just to clarify, RAII as an idiom doesn't contradict something that's garbage collected. D can use RAII extensively while still being garbage collected.
The language used to not be garbage collector oriented but various functionalities require a garbage collector currently such as string splitting. Yeah, it's fast to allocate but collection is actually pretty slow still (unless they've changed it in the past few years). If it's a real-time application, it's extremely important to remember it's garbage collected since you will fight the GC any time it's collecting unfortunately. If you wish to avoid the GC, there are various rules in which you have to follow and nothing within the compiler or current standard library (phobos still?) to enforce it.

D uses the attribute @nogc to check at compile time that your code does not touch the garbage collector. Currently the standard library isn't as @nogc friendly as one would like but there is a long term plan to deal with that. std.experimental.allocator defines an interface that allows the user to specify what allocation scheme a library function will use and a bunch of primitives that you can construct a specific memory allocator from. Phobos (the standard library) is bit by bit being rewritten on top of this interface.

Rust is safer than D in my opinion since it uses language rules to guide the user to correct usages of the allocator rather than doing it pragmatically at runtime (which will still have a chance of memory leakage on abuse anyways). I'm not particularly fond of the Rust syntax honestly but it's currently what I would call the most probable"Next" language because of its approach. I can build a real-time application in Rust without having a few hundred lines of complicated code (possibly more) fighting the GC anytime it collects while I gain semantics that help me from fucking up memory management.

I am waiting for D to actually implement it's planned safety features before judging this one (current plans here https://www.youtube.com/watch?v=iDFhvCkCLb4). In defence of D's GC. it's deterministic (the only thing that causes a GC pass is when you allocate), for realtime work you run your realtime work in it's own thread and detach that from the garbage collector. If you are interested in some current patterns for realtime D code - have a look at this https://github.com/AuburnSounds/dplug if you want to see what current realtime code using D looks like. In future std.experimental.allocator should make things a good deal easier (including having standard components you can build a custom memory allocator out of.