On Friday, 5 June 2020 at 08:39:09 UTC, Russel Winder wrote:
> On Fri, 2020-06-05 at 12:44 +1000, Manu via Digitalmars-d wrote: […]
>> [...]
>
> For me writing GTK+ desktop applications, I'd rather use D than Rust or Vala (I do not actually use Vala at all as it is just too niche), but the developer experience with Rust is just so much nicer than using D. Writing Rust code is harder than writing the same functionality in D (except for asynchronous and futures based code, where Rust just wins over D hands down), but the D plugin to CLion and IntelliJ IDEA isn't anywhere near the capability of the Rust plugin. Writing all code with Emacs, Bash and lldb is just a terrible experience, despite the wonders of Emacs.

Please also have a look at Visual Studio Code and code-d extension. It works really nice and debugging also works great.

Kind regards
Andre

On Friday, 5 June 2020 at 09:08:23 UTC, Andre Pany wrote:
[...]
> Please also have a look at Visual Studio Code and code-d extension. It works really nice and debugging also works great.
>
> Kind regards
> Andre
+1
I am not a fan of Microsoft - to say it gently -  but VS Code, which works on Linux quite well, is the only MS program I use every day.

On 6/4/2020 7:44 PM, Manu wrote:
> ...

Regarding shared,

    void test(shared(int)* p) { *p = 1; }

dmd -preview=nosharedaccess test

    test.d(31): Error: direct access to shared *p is not allowed, see core.atomic

Isn't that what you wanted?

On Friday, 5 June 2020 at 04:55:36 UTC, FeepingCreature wrote:
> 
>
> And because my new language project isn't ready yet. ;-)
>
> IMO, D is the worst best language. It simultaneously goes so far in useful directions that it makes using any other C-like painful, but still falls so far short of what it itself shows is possible. (shared, immutable, copy constructors, the half-working lifetime tracking, great templates with horrible performance, mixin but no macros, ddoc but no introspection...) I think that's the reason why D people keep wandering off to make their own compilers. Lisp has somewhat the same property, but there's less impetus to go off and make your own Lisp because the base language is so very extensible.

Here is a concrete illustration of the above. Consider someone wants to accomplish a trivial code generation task:

void foo() {
  static foreach(i, ...) {
    static if (i == 3)
      outerDecl;
    localDecl;
    statement;
  }
}

Non-static foreach does not fit because of outerDecl. localDecl is problematic because 'static foreach' does not introduce local scopes. The poor programmer tries the most obvious:

{
   localDecl;
}

This does not work, because of the old bug https://issues.dlang.org/show_bug.cgi?id=3031, which was deemed not deserving a proper fix.

Next attempt - template mixin, which does introduce a special kind of scope:

void foo() {
  mixin template Local() {
    localDecl;
    statement;
  }
  static foreach (..)
    mixin Local;
}

This doesn't work because declaring mixin templates are not allowed inside functions. Work around by taking the mixin decl out of the function at the cost of cluttering the parent scope.

Then, the poor programmer is reminded that mixins cannot have statements. After a significant amount of cursing, the programmer, desperately trying to avoid the ugliness of string mixins and the inglorious lambda-statement hack, discovers this
https://github.com/dlang/dmd/pull/6760, reads the DIP and realizes that his issue should have been solved 3 years ago but was forgotten or deemed unimportant, who knows.

Of course, all this can be worked around with ugly hacks. However, if you multiply this experience by half the number of D's features, you will have the answer why people get frustrated.

I think the problem is that the designers of the features do not use them. Another problem is the "hardcore mechanical engineer" culture: if there's a working hack, no matter how ugly, use it and never look back.

On Friday, 5 June 2020 at 08:39:09 UTC, Russel Winder wrote:
> For me writing GTK+ desktop applications, I'd rather use D than Rust or Vala (I do not actually use Vala at all as it is just too niche), but the developer experience with Rust is just so much nicer than using D. Writing Rust code is harder than writing the same functionality in D

Same for me, writing in D is just so much more fun and quicker than writing it in Rust (at least for GTK applications since the GTK concept doesn't really map well onto Rust). Most advantages of Rust are kind of moot when using GTK anyway since that means refcounting all the things and trusting upon the D GC to handle the refcounting works really well for that. I do have to admit that I miss how infrequent SIGSEGVs are with Rust (read: somewhat impossible unless you have bad bindings/C libs), but since I don't have to manually manage memory in D too often it's not too bad in D either and in return I save loads of time while coding due to the capabilities I have in D that Rust takes away from me. Also, static-if and static-for rocks and at least in the way I use it doesn't cause my compilation times to easily go into the minutes for small programs (right, Rust? :)

On Friday, 5 June 2020 at 02:44:17 UTC, Manu wrote:

> Back on-topic; I still use D because I just can't stand C++, and I somehow fundamentally believe D can 'get there'... but god is it a hard and frustrating road! Eternally so close, but always juuuust misses the mark. Maybe one day we'll land the shot >_<

In my opinion there will always be that one missing feature that prevents D from getting there. In other words, if features were a stopping factor then how did anyone ever use C++ 10 years ago?

On Friday, 5 June 2020 at 10:15:25 UTC, Walter Bright wrote:
> On 6/4/2020 7:44 PM, Manu wrote:
>> ...
>
> Regarding shared,
>
>     void test(shared(int)* p) { *p = 1; }
>
> dmd -preview=nosharedaccess test
>
>     test.d(31): Error: direct access to shared *p is not allowed, see core.atomic
>
> Isn't that what you wanted?

There are quite a few bugs with the `-preview=nosharedaccess` switch, and before you ask, yes it's in bugzilla: https://issues.dlang.org/show_bug.cgi?id=20195

Regarding inline, here's what I believe Manu is complaining about: https://issues.dlang.org/show_bug.cgi?id=19570

I will add that rvalue references are also completely broken, but I'm not sure how relevant it is to Manu (it's certainly relevant for C++ interop, though):
- https://issues.dlang.org/show_bug.cgi?id=20706
- https://issues.dlang.org/show_bug.cgi?id=20705
- https://issues.dlang.org/show_bug.cgi?id=20704

On Friday, 5 June 2020 at 02:44:17 UTC, Manu wrote:
> 'Quickly'? 'Least amount of work'? Pfft... like what?

Oh boy I forgot that other people use a word work as a synonym for effort/time spent and that derailed everything. So I will try again.


You value (X). You see a lot of benefit of doing (X). Doing (X) have served you well over the years. (X) is good.

You write a proposal for D using (X). People do not immediately accept it so you do more (X) to convince them. If that didnt help you try to do (X) even harder. And if that didnt help you think to yourself that you just need to do (X) just a little bit harder.

Then you write another proposal and the pattern continues producing the same kind of problems again and again.

Maybe your proposals have enough of (X) and you have problems because you didnt do enough of (Y).

> `shared` is broken, I've done what work I can do alone, but if it's rejected, other people need to step in and make a counter proposal, <...> I know what we need to do with shared.

Whas it rejected or not accepted? Thats a big difference. Rejected means people thought its a bad idea. Not accepted might mean that people are not sure so they play safe. If its the later then changing proposal would not change the outcome.

> I don't know how to convince key folks that shared is really important any more > than I am able to say "shared is really important, and this opportunity depends > on it"...?

I know. Make sure that proposed changes do not negatively affect or block other valid ways of doing multithreading on all platforms(powerPC, GPUs, etc.). And describe how everything should work in all edge cases on all platforms. Then Walter would accept it.

Ofcourse you dont have to do that in one swing. You can start by writing a blog post describing lesions learned from game dev on how to do multithreading. What has been tried? What were the problems with those approaches? What is done now? How changes to shared would affect that? In a style of past, present, future covering as much cases as possible.
There are not that many people with the kind of experience you have. It would be nice if you could share it. Not only it will improve collective wisdom but also move us closer to a solution to shared.

Another approach that has value of its own and helps us move closer to fixing shared is to make compiler multithreaded. When compiler people(Walter) have to work with shared everyday it would be much easier to explain certain things.

P.s. My previous post was not intended to insult, belittle or otherwise negatively affect you. If that happened I am sorry and will try express my thoughts in different way

On Friday, 5 June 2020 at 09:08:23 UTC, Andre Pany wrote:
> On Friday, 5 June 2020 at 08:39:09 UTC, Russel Winder wrote:
>> On Fri, 2020-06-05 at 12:44 +1000, Manu via Digitalmars-d wrote: […]
>>> [...]
>>
>> For me writing GTK+ desktop applications, I'd rather use D than Rust or Vala (I do not actually use Vala at all as it is just too niche), but the developer experience with Rust is just so much nicer than using D. Writing Rust code is harder than writing the same functionality in D (except for asynchronous and futures based code, where Rust just wins over D hands down), but the D plugin to CLion and IntelliJ IDEA isn't anywhere near the capability of the Rust plugin. Writing all code with Emacs, Bash and lldb is just a terrible experience, despite the wonders of Emacs.
>
> Please also have a look at Visual Studio Code and code-d extension. It works really nice and debugging also works great.
>
> Kind regards
> Andre

+1.  Like Andre, I really like VS Code+code-d.  Then again I jumped to VS Code from a 70s era text editor that I originally wrote in VAX assembly language, not a patch on CLion.  My guess is that I was the only person in the world still using the editor whereas CLion, according to a recent survey of Rust programmers, is used by 1.1% of the 3997 respondents.  The same article has VSCode in first place at 34.9%.

As I've inferred from many of Russel's postings, the tools surrounding the language matter, a lot.  I agree completely.  It's easier for people to start using D, and continue using D, when the tools offload the mechanical.  Hats off to the D tool builders!

On Wednesday, 3 June 2020 at 11:12:08 UTC, aberba wrote:
> I personally can't use any other system programming language due to the expressiveness and familiarity of D. Its familiar and some syntactic expressiveness are just hard to get in other systems languages...feels easier to model code in D.
>
> I don't use D primarily for work (Node.Js due to packages and cloud support...web services), but D is my go-to system language. Personally, wished I could use D for everything.
>
> I like the community here better, I like the engagement and support. Yeah, it's not perfect but way better than anywhere else I've been.
>
> What are you?

I use D for toy or small personal projects. I only had the luxury to use it for work, to make a small tool to help to automate deploys on tomcat servers, downloading the WAR from a nexus server. And now these tool isn't necessary anymore (now it's all doing with a Jenkins taks doing mvn package + bash script + ansible)


Why? Well, what I like more of D it's the metaprograming power that gives CTFE + mixins and another little details that makes it great (slices, parallel for, NVI pattern, etc). However, I always have the sensation that it's unpolished and need to fix too many rough corners.