My two cents

Ecstatic Coder ecstatic.coder at gmail.com
Fri Oct 20 19:18:15 UTC 2017


On Wednesday, 18 October 2017 at 08:56:21 UTC, Satoshi wrote:
> Hi,
> I had been using D for almost 6 years and I want to share my 
> opinion with you.
> I don't want to blame anyone but I'll focus more on bad things 
> and possible improvements.
> And this is just how I see D from my perspective.
> (Sorry for my English, I'm too lazy to take the lessons).
>
>
> First, D started as a great new language with the best from all 
> languages. But now D seems more and more conservative. New 
> syntactic sugars aren't added just because they can be found in 
> phobos. (this was Walter's answer when I asked for maybe monad 
> syntactic sugar).
>
> OK, what I'm missing in D and what I think is wrong?
>
> syntactic sugar for:
> tuples
> maybe monad (why we cannot have same syntax as in C#?)
> conditional dereferencing and stuff about that (same as in C#)
> foo?.bar;
> foo?[bar];
> return foo ?? null;
>
> async/await (vibe.d is nice but useless in comparison to C# or 
> js async/await idiom)
> I want to create function returning Promise/Task and await 
> where I want to.
> e.g.
> auto result = device.start(foo, bar); // This is RPC to remote 
> server returning Task!Bar
> // do some important stuff
> return await result; // wait for RPC finish, then return it's 
> result
>
> I want to do this and not any ugly workaround about that.
>
>
> @trusted, @safe, @system - why we have 3 keywords instead of 
> one? And why it's so complicated to use?
>
> First, we should have one 'unsafe' keyword.
> Second, everything should be safe by default.
> 3rd, if we want to declare @system func, use 'void foo() 
> unsafe;'
> if we want to declare @trusted func, use
> void foo() {
> unsafe {
>
> }
> }
>
> This fulfills the D's idiom in better way, because we should be 
> defining unsafe sections as small as possible.
>
>
> C# properties instead of existing ones.
> function and property should be two different things.
> Calling function without () or assigning to it by = is a ugly 
> behavior and should be avoided.
>
> implement this thing from C# (just because it's cool)
> new Foo() {
>   property1 = 42,
>   property2 = "bar"
> };
>
>
> Reference counting when we cannot use GC...
>
>
> Commercial usage, shared libraries and stuff
> There isn't any handy tool to download, manage and publish 
> closed source stuff.
> dub is great for simple solutions but useless in big projects 
> with multiple targets, configurations, etc.
> Everything is primary focused on opensource development (but 
> everyone here wants to see D as a next successor of C++ in 
> commercial sphere).
>
>
> Still cannot easily develop closed source dlls on Windows. On 
> Linux every symbol is public by default, but on Windows not so 
> it's needed to export them manually.
>
>
> Unable to publish closed source library without workaround and 
> ugly PIMPL design.
>
> Add dll/so usage without header files
> (export enums, templates and stuff right into dll/so and let D 
> compiler to import these stuff from it)
>
>
>
> For me, it seems like Walter is solving edge case problems like 
> return ref parameters and return functions but is unable to add 
> some basic stuff.
>
>
> Thanks for your time.
> - Satoshi

Interesting proposals, but IMHO, the only ESSENTIAL feature 
missing in D is the possibility to program in D using a built-in 
reference-counting based variant of the standard library.

If D really sells itself as a C++ alternative, then it MUST be a 
true C++/Rust competitor.

So using stuff like strings, slices, maps, reference classes 
should be made possible without GC.

You just need a few qualifiers to say if a class instance is 
owned by a reference (behavior by default) or just pointed by a 
weak reference (i.e a pointer with automatic deferencing).

That ALONE would make D a better competitor to C++ on its grounds.

Add full binary compatibility at the linker level with C++ 
library and you may now have a real opportunity to "win" the war 
against C++ and Rust.

Or you can just wait that C++ improves enough (modules, etc) so 
that D provides too few advantages to be an interesting 
alternative...








More information about the Digitalmars-d mailing list