On Sunday, 26 August 2018 at 19:28:30 UTC, Radu wrote:
> On Sunday, 26 August 2018 at 16:09:35 UTC, lurker wrote:
>> [...]
>
> Yeah right... I'm sure this is what everyone experienced.
>
> This thread has become the trollers trolling playground.

no, i used to use d1 a lot and then d2 changed everything with it promise. but it turned into skript like monster, that doesn't work very well with tons of features. d2 is unreliable, doesn't install correct, dll problem .....
no company i ever worked at, used linux. they all use vs with windows. they want to make money and not go for the experiments of some compiler freaks.
it is important that you can have a quality experience on windows with vs, be able to use dll's and have a stable compiler with predictable use; if possible be able not to use the gc, but the gc wouldn't even be hanger.

well, you are correct, i have a different opinion and experience with d2 - so i must be a troll.
anyway, radu, i wish you good luck on a larger commercial program on windows with d2.

over and out.

On Sunday, 26 August 2018 at 19:28:30 UTC, Radu wrote:
> On Sunday, 26 August 2018 at 16:09:35 UTC, lurker wrote:
>> [...]
>
> Yeah right... I'm sure this is what everyone experienced.
>
> This thread has become the trollers trolling playground.

Radu, when i started using this forum, one of the first questions i asked

How do you used D?
https://forum.dlang.org/thread/vyrjquwvwohapjnlmvvv@forum.dlang.org

And the majority replied that they are using it for personal and hobby projects

Who is really trolling who?

On Sunday, 26 August 2018 at 20:21:07 UTC, Ali wrote:
> On Sunday, 26 August 2018 at 19:28:30 UTC, Radu wrote:
>> On Sunday, 26 August 2018 at 16:09:35 UTC, lurker wrote:
>>> [...]
>>
>> Yeah right... I'm sure this is what everyone experienced.
>>
>> This thread has become the trollers trolling playground.
>
> Radu, when i started using this forum, one of the first questions i asked
>
> How do you used D?
> https://forum.dlang.org/thread/vyrjquwvwohapjnlmvvv@forum.dlang.org
>
> And the majority replied that they are using it for personal and hobby projects
>
> Who is really trolling who?

The experience described by OP makes one question why the hell this language still exists and still has users.

Plus that I found it extremely offensive to the people working to make Dlang better.

On your little divergent line. Not everyone answers forum polls and not everyone working on commercial projects wants or can comment on them.

I hope that at least 10% percent of the energy spent on venting on the forums can be spent on bug reports, PRs and some donations.

On 8/26/2018 12:34 PM, Manu wrote:
> I work at a company with a thousand engineers, all VS users, D could
> find home there if some rough edges were polished, but they
> *absolutely must be polished* before it would be taken seriously.
> It is consistently expressed that poor VS integration is an absolute
> non-starter.

I will tiresomely ask again, do you have a list of each and every aspect of the poor integration?

On 8/26/2018 8:43 AM, Chris wrote:
> I wanted to get rid of autodecode and I even offered to test it on my string heavy code to see what breaks (and maybe write guidelines for the transition), but somehow the whole idea of getting rid of autodecode was silently abandoned. What more could I do?

It's not silently abandoned. It will break just about every D program out there. I have a hard time with the idea that breakage of old code is inexcusable, so let's break every old program?

> But what for was it introduced at all and why wasn't it thought through properly right from the start?

Because nobody thought about that issue before. A lot of things only become apparent in hindsight.

On Sunday, 26 August 2018 at 20:55:04 UTC, Walter Bright wrote:
> On 8/26/2018 12:34 PM, Manu wrote:
>> I work at a company with a thousand engineers, all VS users, D could
>> find home there if some rough edges were polished, but they
>> *absolutely must be polished* before it would be taken seriously.
>> It is consistently expressed that poor VS integration is an absolute
>> non-starter.
>
> I will tiresomely ask again, do you have a list of each and every aspect of the poor integration?

Not to put words in his mouth, but:
* rvalue references: see recent DIP
* https://github.com/ldc-developers/ldc/issues/2800 Really a DMD issue
* https://issues.dlang.org/show_bug.cgi?id=19179

probably more.

On 8/26/2018 1:55 PM, Walter Bright wrote:
> I will tiresomely ask again, do you have a list of each and every aspect of the poor integration?

I know you don't like filing bug reports. I'll make it easy for you.

Every time someone you work with says:

"I can't use D because ..."
"I'm abandoning D because ..."
"D sux because ..."

Just append a note of it to a text file. It doesn't matter what the reason is, any information is valuable, including:

"... because Walter killed and ate my dog"
"... because my apartment contract stipulates no pets, no smokers, no D programming"
"... because I can't take D jokes anymore"
"... because Walter won't stop droning on with his boring Boeing anecdotes"

Now and then, just email me the file.

On Sunday, 26 August 2018 at 22:44:05 UTC, Walter Bright wrote:
> On 8/26/2018 8:43 AM, Chris wrote:
>> I wanted to get rid of autodecode and I even offered to test it on my string heavy code to see what breaks (and maybe write guidelines for the transition), but somehow the whole idea of getting rid of autodecode was silently abandoned. What more could I do?
>
> It's not silently abandoned. It will break just about every D program out there. I have a hard time with the idea that breakage of old code is inexcusable, so let's break every old program?
>
Can I just throw in here that I like autodecoding and I think it's good?
If you want ranges that iterate over bytes, then just use arrays of bytes. If you want Latin1 text, use Latin1 strings. If you want Unicode, you get Unicode iteration. This seems right and proper to me. Hell I'd love if the language was *more* aggressive about validating casts to strings.

On Sun, 26 Aug 2018 at 14:00, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On 8/26/2018 12:34 PM, Manu wrote:
> > I work at a company with a thousand engineers, all VS users, D could find home there if some rough edges were polished, but they *absolutely must be polished* before it would be taken seriously. It is consistently expressed that poor VS integration is an absolute non-starter.
>
> I will tiresomely ask again, do you have a list of each and every aspect of the poor integration?

Tooling specifically?

Just to be clear, when I say "poor VS integration is an absolute
non-starter", I'm not necessarily saying that's where we are... I'm
just saying that's a fact.
Where I think we are today is at MVP, which is a hard fought victory in itself.
I think we've reached the point with VS integration that people won't
question it and reject it on the spot... but we have entered a place
where people feel that it's lacking quality compared to the tooling
they're used to.

Debug experience is worlds better than it's been, by contrast it's
very usable today, and you'll notice I haven't been complaining about
it... but it's still imperfect.
You should try using VisualD to debug DMD some time. You'll quickly
discover edge cases trying to evaluate all the relevant state while
stepping around. C++ RTTI is a problem (can't identify derived type in
debugger), globals are a problem, TLS is a problem.
The minor edge cases emerge frequently enough that they convey a sense
of immaturity. I'll start taking note everything I encounter a minor
debugging issue.

One specific issue I frequently encounter is with scope closure. I'd
really like to see the line of the closing '}' being emit as the line
where all destructors are called. The workflow in C++ for example:
    - Place breakpoint on the line of the closing '}' for a scope.
    - Debugger stops at that line prior to execution of scope closing
destructors, you can use step-in and enter the destructors that are
scheduled to call at the end of scope.
    - It's very awkward to break and step through destruction paths
without being able to place such breakpoints at end-of-scope.
    - Developers expect this, and are surprised when it "doesn't work".
I added a bugzilla for this issue 6 or 7 years ago... but I can't find it.

We could really use robust tools to produce a matching C++ .h file
from the extern symbols in a D module, and likewise a .di file from a
C/C++ header.
This category of tooling has many existing instances, it's
overwhelming. As far as I can tell, they're all experimental, or
broken, or designed only to target a specific application (DMD), etc.
I think it would be an advantage if there were *one* tool, that works,
in both directions, which is advertised, recommended, and maintained
by the core group.
I've evaluated them all before at various points in time, but the
landscape keeps shifting. Someone, please give me a prominent
hyperlink to the solution that *works*, and instructions. I don't have
energy to re-do comprehensive evaluations on this front, I'm spent.
Agree on one, make it the official one, and then track bugs against it
in bugzilla?

FWIW, my recent flurry of extern(C++) related PR's on DMD are only
made possible by the current state of the VS tooling. There is no way
I would have taken the time to do that work if the VS tooling wasn't
where it is. Those PR's are a direct result of VS tooling reaching
relative maturity; they would not have happened if the VS project
didn't just load and the debugger just worked.
The bar for tooling is very high, and we VS developers are quite
precious, and soft ;)

VisualD:
  Installer needs to be signed alongside DMD installer.
  Autocomplete/Intellisense is very unreliable. I don't think it has
clear visibility through enough meta constructs. Today's solutions
appear ad-hoc, I suspect they could receive a lot more assistance from
DMD.
  Go-to definition must _always_ work.
  Syntax highlighting only performs a fraction of what VisualAssist
does. Colleagues that have been experimenting with D consistently
complain that they feel colour blind.
  Find-all-references locate all symbol references in a project
  Refactoring tools (rename symbol throughout project, etc)
  Suggest and cleanup spurious imports (like C# tooling)

Rainer has done amazing work; he's tirelessly helpful, but it feels
unfair to dump this whole load onto him.
I'm not sure who or how to make these things a priority for development.

A robust 'intellisense' solution (MS nomenclature) in the form of a
library would help everyone.
It should support:
  * Comprehensive syntax highlighting which is *correct*, not just best-guess
  * Auto-complete; when I press '.' what are all valid identifiers,
and no spurious entries that aren't. Current tooling misses heaps of
stuff, and also tends to pollute the list with a lot of junk.
  * Go-to definition (ie, locate symbol) must reliably work
  * Refactor tools; eg, rename identifier throughout code
  * Suggest imports when calling functions that aren't in scope
  * Cleanup spurious imports

People learn to lean on their tooling very heavily, and they'll feel a
strong sense of loss. This puts a further burden on 'D the language'
to be _that much better_ to compensate for any such sense of loss in
tooling.
The last few experiences I list are imperfect in C++, D can
theoretically (and should) do a much better job, since scoping and
language structure is better, and there's no text includes and macros.
One great opportunity for my current project is that we're asking C#
programmers to use C++. They *hate* C++ even more than C++
programmers.
This is actually a really interesting opportunity to show them how
they can write native code and not have to hate C++... but C# sets the
bar for tooling very high.
If we were able to respond with similarly quality tooling, we'd have a
horde of C# programmers insisting we prefer D to C++ ;)


There's more things than that though.. I'll dump a list of things that are on the front of my mind recently.

Language:
  There's the namespace thing and the ref DIP. Please just add support
for a non-scoped string namespace beside the existing solution. We
know I can't reason this with you... just... please do it for all of
us that actually use it. I'll buy you a beer.
  Andrei's copy-ctor, and the move-ctor DIP would be super-welcome
conclusions. Copy-construction is a problem. There's a set of
languages issues in this space that Andrei knows well, and they're
very important.
  I'm finding that 'const' is a practical problem. I don't know what to do.
    - Conventional wisdom; "don't use const in D", doesn't work when
interacting with C++, which uses const successfully and aggressively.
    - I use a head-const hack, which is a shim that wraps pointers and
forcefully casts-away const (technically undefined behaviour; in
practice, it works)
    - C++ people lose their mind when they see this. It would be
possible to pacify them with demonstration that D's const is superior,
but I don't know how to produce that evidence.
    - I used to buy into D's const philosophy, but I've come to
conclude that C++ got it right. Radical solutions should not be off
the table...
  ARC? What ever happened to the opAddRef/opDecRef proposal? Was it
rejected? Is it canned, or is it just back on the bench? (GC is
absolutely off the table for my project, I have no influence on this)

On DMD:
  My project is 100% DLL based. DLL's must work flawlessly.
  For STL interaction (which I'm concluding now):
    - This ABI crash is blocking me:
https://issues.dlang.org/show_bug.cgi?id=19179
    - We need a version to detect which CRT was selected at compile
time so we can emit matching data structures in our code.
    - MS .obj files have _ITERATOR_DEBUG_LEVEL definition emit to the
object file. I think we need a pragma to emit such tokens to the
object. I would make the STL modules emit the _ITERATOR_DEBUG_LEVEL as
the code was generated using said pragma.
    - https://issues.dlang.org/show_bug.cgi?id=18999
  For this project, I would ban GC, perhaps attempt using -betterC. I
have little practical experience here... but reports are often
unhappy. I'll find out I guess.
  This issue: https://issues.dlang.org/show_bug.cgi?id=18896

  Less important:
    This emerged again recently: https://issues.dlang.org/show_bug.cgi?id=18906
    Workarounds for this are problematic:
https://issues.dlang.org/show_bug.cgi?id=18845
    I wasn't able to conclude some mangling issues during my recent
effort, they interacted awkwardly with the build/test scripts, and
DMC:
      * https://issues.dlang.org/show_bug.cgi?id=18997
      * https://issues.dlang.org/show_bug.cgi?id=18958

I don't think this is exhaustive... but they're at close reach.

On Sun, 26 Aug 2018 at 15:55, Nicholas Wilson via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Sunday, 26 August 2018 at 20:55:04 UTC, Walter Bright wrote:
> > On 8/26/2018 12:34 PM, Manu wrote:
> >> I work at a company with a thousand engineers, all VS users, D
> >> could
> >> find home there if some rough edges were polished, but they
> >> *absolutely must be polished* before it would be taken
> >> seriously.
> >> It is consistently expressed that poor VS integration is an
> >> absolute
> >> non-starter.
> >
> > I will tiresomely ask again, do you have a list of each and every aspect of the poor integration?
>
> Not to put words in his mouth, but:
> * rvalue references: see recent DIP
> * https://github.com/ldc-developers/ldc/issues/2800 Really a DMD
> issue
> * https://issues.dlang.org/show_bug.cgi?id=19179
>
> probably more.

I feel like the question was about tooling specifically... but yes, all of those! ;)