I like D, but sometimes it's look like for me too complicated. Go have a lot of fans even it not simple, but primitive. But some D futures make it very hard to learning.

Small list by me:
1. mixins
2. inout
3. too many attributes like: @safe @system @nogc etc

Which language futures by your opinion make D harder?

On 02/09/2018 02:54 AM, Suliman wrote:
> I like D, but sometimes it's look like for me too complicated. Go have a lot of fans even it not simple, but primitive. But some D futures make it very hard to learning.
> 
> Small list by me:
> 1. mixins
> 2. inout
> 3. too many attributes like: @safe @system @nogc etc
> 
> Which language futures by your opinion make D harder?
> 

Auto-decode.

Dub.

And yes, things like "inout", "auto ref" or whatever, and such, strike me as indicative of more fundamental design flaws. (Not "flaw" in the sence of "mistakes" necessarily, but "flaw" in the sence of "there must be a better way to design these things...")

Aside from that, I don't think features inherently make D complicated, but I do think there are features that are designed or implemented in overly-complicated ways. Or *missing* features, which by their absence make the langauge more complicated.

The biggest, by far, that comes to my mind is dealing with types:

- At runtime: Dealing with type infos at runtime is a mess compared to many other langauges (especially dynamic ones).

- At compile time: The mechanisms for dealing with type info at compile time seem...undesigned. It's kind of a clutter of various approaches and haphazard quirks, and std.traits is a testament that it's not very cleanly designed at the language-level.

- RT vs CT: The interfaces for dealing with types are completely 100% different depending whether you're working with runtime or compile-time.

Other things that come to mind:

Defining input ranges (one of my biggest pet peeves):

C# knocked it out of the park ages ago with its design for a stackless!!! (ie no-fibers) coroutine syntax. There's no reason the same approach couldn't be used in D for creating input ranges. But instead, D forces input ranges to be defined the same way as random-access ranges, which is a PITA (a necessary PITA for random-access, but unnecessary for mere generators like input ranges), and D provides no way around that without introducing the overhead of fibers. Even an old version of C# from ten years ago puts us to complete shame here.

And Algebraic types. Yes, we technically have them, but compared to something like Nemerle, D claiming to have algebraic or pattern matching is like C claiming to support OO: Umm...sorta...technically...kinda...but...uhhh...no, not really.

On Friday, 9 February 2018 at 07:54:49 UTC, Suliman wrote:
> I like D, but sometimes it's look like for me too complicated. Go have a lot of fans even it not simple, but primitive. But some D futures make it very hard to learning.
>
> Small list by me:
> 1. mixins
> 2. inout
> 3. too many attributes like: @safe @system @nogc etc
>
> Which language futures by your opinion make D harder?

This is a great question. The hard part of good language design is making things simple.

On Friday, 9 February 2018 at 08:27:21 UTC, Nick Sabalausky (Abscissa) wrote:

> Defining input ranges (one of my biggest pet peeves):
>
> C# knocked it out of the park ages ago with its design for a stackless!!! (ie no-fibers) coroutine syntax. There's no reason the same approach couldn't be used in D for creating input ranges.

I'm missing too the yield return and await syntax in D every time. In my current asp.net project I counted around 800 await calls. I don't even imagine how difficult should be to translate this in D style.

But back to the subject:
- pure @safe nothrow @nogc
- auto const ref
- __ctfe is a variable
- traits as a library solution;
- alias this;
- calling conventions are a best kept secret.
- everything is a range. If not, we will rangify it. Autodecoded eventually.
- no dedicated syntax sugar for ranges;
- no dedicated syntax sugar for coroutines;
- no dedicated syntax sugar for events;
- GC is evil. OO is outdated.
- last integer promotion rules.


And not a language feature but I hate dub. Just saying.

On Friday, 9 February 2018 at 13:10:16 UTC, rumbu wrote:
>
> And not a language feature but I hate dub. Just saying.

Why do people hate dub? I think it's a great package manager and build tool

On Friday, 9 February 2018 at 13:10:16 UTC, rumbu wrote:
> On Friday, 9 February 2018 at 08:27:21 UTC, Nick Sabalausky (Abscissa) wrote:
>
>> [...]
>
> I'm missing too the yield return and await syntax in D every time. In my current asp.net project I counted around 800 await calls. I don't even imagine how difficult should be to translate this in D style.
>
> But back to the subject:
> - pure @safe nothrow @nogc
> - auto const ref
> - __ctfe is a variable
> - traits as a library solution;
> - alias this;
> - calling conventions are a best kept secret.
> - everything is a range. If not, we will rangify it. Autodecoded eventually.
> - no dedicated syntax sugar for ranges;
> - no dedicated syntax sugar for coroutines;
> - no dedicated syntax sugar for events;
> - GC is evil. OO is outdated.
> - last integer promotion rules.
>
>
> And not a language feature but I hate dub. Just saying.

The GC is awesome, and trivially avoided. And once it is, programs crash and remind me of programming in C and C++ in the 90s.

At least LDC has address sanitizer now.

Atila

On Friday, 9 February 2018 at 08:27:21 UTC, Nick Sabalausky (Abscissa) wrote:
> On 02/09/2018 02:54 AM, Suliman wrote:
>> [...]
>
> And yes, things like "inout", "auto ref" or whatever, and such, strike me as indicative of more fundamental design flaws. (Not "flaw" in the sence of "mistakes" necessarily, but "flaw" in the sence of "there must be a better way to design these things...")
>
> [...]

Yeah, something like traits in Rust or typeclasses in Haskell would be a lot better. Fortunately, one can kinda-sorta get there with a library solution. Check out `@implements` in https://github.com/atilaneves/concepts


> And Algebraic types. Yes, we technically have them, but compared to something like Nemerle, D claiming to have algebraic or pattern matching is like C claiming to support OO: Umm...sorta...technically...kinda...but...uhhh...no, not really.

Proper sum types and pattern matching would be nice.

Atila

On Friday, 9 February 2018 at 13:34:01 UTC, tetyys wrote:
> On Friday, 9 February 2018 at 13:10:16 UTC, rumbu wrote:
>>
>> And not a language feature but I hate dub. Just saying.
>
> Why do people hate dub? I think it's a great package manager and build tool

Great package manager? Yes.

Great build tool? No. For anything that's not trivial it's an exercise in frustration, pain, tears, waiting for builds to finish, and workarounds for bugs.

Atila

On Friday, February 09, 2018 13:34:01 tetyys via Digitalmars-d wrote:
> On Friday, 9 February 2018 at 13:10:16 UTC, rumbu wrote:
> > And not a language feature but I hate dub. Just saying.
>
> Why do people hate dub? I think it's a great package manager and build tool

I don't know what all of the reasons are, but as a build tool, it needs work. It works well for the common case, but as soon as you need to do anything fancier than simply building every module in your project, it starts getting really hard to do with dub if it's possible at all. It really isn't very flexible. The other issue that gets complained about a lot is how slow it is, which if I understand correctly is primarily due to how much network traffic it has in order to check the status of repos, but regardless, it's generally far slower than simply using dmd or rdmd directly. I don't think that any of dub's problems are fatal, but I also don't think that dub gets a lot of attention, particularly since the guy behind it is the same guy who's behined vibe.d, and there's only so much of him to go around. It could really use more people taking the time to improve it - but that's true of far too much around here. Fortunately, in spite of that, dub has improved over time, but not quickly.

- Jonathan M Davis

On Friday, 9 February 2018 at 13:10:16 UTC, rumbu wrote:
> On Friday, 9 February 2018 at 08:27:21 UTC, Nick Sabalausky (Abscissa) wrote:
>
>> Defining input ranges (one of my biggest pet peeves):
>>
>> C# knocked it out of the park ages ago with its design for a stackless!!! (ie no-fibers) coroutine syntax. There's no reason the same approach couldn't be used in D for creating input ranges.
>
> I'm missing too the yield return and await syntax in D every time.

What's wrong with the library solution from std.concurrency?

> But back to the subject:

All good point. A few questions:

> - alias this;

Do you mean no multiple alias this or the problem with overloading?

> - everything is a range. If not, we will rangify it.

> Autodecoded eventually.

No one likes it, but you can opt-out with byCodeUnit - that doesn't work for you?

> - no dedicated syntax sugar for ranges;

What do you expect here?
(also it's not entirely true - foreach already supports ranges)

> - no dedicated syntax sugar for coroutines;

What syntax sugar that can't be done by a library do you expect?

> - no dedicated syntax sugar for events;

What syntax sugar that can't be done by a library do you expect?
await?