On Mon, 2016-06-06 at 06:50 +0000, poliklosio via Digitalmars-d wrote:
> 
> […]

> Please, elliminate GC.

Let's not. It is a USP against C++ and Rust. It forges a new route to traction, cf. Go, Java, etc.

> This also hurts the open source community. Why would I
> write/opensource a high performance library if I know that
> projects like AAA games are not going to use it anyway due to GC
> in D? On the other hand if I can write a library that guarantees
> to not use and not need garbage collector then even C and C++
> projects can use it.
> With GC, D doesn't play nice with existing C/C++ code.

There may be some instances where this is the case. Let them use C++ or Rust. Fine. If AAA games people want C++ they will use C++, for D they are a lost market. That is fine, there is nothing wrong with that. See what happened with Go.

And anyway D has a GC if you want and a no-GC if you want. Thus this is not actually an issue anyway.

> 
> > * Tooling is immature and of poorer quality compared to the competition.
> 
> Quality is an issue, but I thing a bigger problem for adoption is
> just the time it takes a new user to set the dev environment up.
> If you look at those pages:
> https://wiki.dlang.org/Editors
> https://wiki.dlang.org/IDEs
> most of the tools use dcd, dscanner and dfmt to provide the most
> important features like auto-completion, autoformatting etc.
> The problem is that dcd, dscanner and dfmt are not bundled
> together so it takes a long time to actually install all this
> together. Note that discovering what is what also takes a lot of
> time for a new user.
> I tried to do this recently and it took me 2 days before I found
> a combination of versions of dcd, dscanner, dfmt, dub and an IDE
> that work together correctly on Windows. My example is probably
> extreme but is a lesson.

Agreed. the editor, support, toolchain thing is an issue. Whilst some of us can cope with putting the bits together, this is not a route to traction for the language.

> May I suggest bundling the official tools with dcd, dscanner, dfmt and dub to create a Dlang-SDK.

Having a small selection of "all in" bundles is a good idea. Better is
a tool for creating an installation from the bits.

> Then the user would only have to install
> - Dlang-SDK
> - An editor
> And everything would work. This would reduce the time from a few
> hours (with a very large variance) to 30 minutes. Then maybe
> people who try D in their free time without being strongly
> indoctrinated by Andrei will not quit after 30 minutes. :)

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Mon, 2016-06-06 at 07:00 +0000, Andre Pany via Digitalmars-d wrote:
> On Monday, 6 June 2016 at 06:29:27 UTC, Andrei Alexandrescu wrote:
> > On 6/6/16 6:17 AM, Andre Pany wrote:
> > > to be usable for companies which want to create economic
> > > software,
> > > in my opinion D lacks std.decimal.
> > 
> > Do C, C++, Java, Go, or Rust have a standard decimal type? -- Andrei
> 
> With java 7 there is the big decimal library in java: https://docs.oracle.com/javase/7/docs/api/java/math/BigDecimal.html
> 
> Kind regards
> André

It is such a real pain to use though, at least from Java.

A number of finance organization specifically went with Groovy to avoid the hassle: Groovy uses BigDecimal as the default floating point type and provides sensible expression syntax (unlike Java). These companies were overjoyed when Groovy got a static compile mode. :-)  Kotlin can also do the right thing with BigDecimal, and does.

So yes the Java Platform has a usable BigDecimal, but Java does not. Fortunately there are other languages on the Java Platform.

BigDecimal is a "Huge Win"™


-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Monday, 6 June 2016 at 07:44:22 UTC, Mike Parker wrote:
> I've never understood this. DMD started out on Windows exclusively. Linux and other platforms came later. It has a Windows installer that will find the MS tools if you need to use them, the zip package works out of the box, the compiler ships with a minimal (and admittedly outdated) set of Win32 libraries that work with OPTLINK... Where does this impression come from that Windows is a second-class citizen?

The Windows build for DMD, etc. seems to require tools that Microsoft no longer distributes publicly. I asked about this, but no one replied...
    http://forum.dlang.org/post/lzmnllscqyyuqlusrwwe@forum.dlang.org

On Monday, 6 June 2016 at 08:17:44 UTC, ixid wrote:
> On Monday, 6 June 2016 at 07:44:22 UTC, Mike Parker wrote:
>> Where does this impression come from that Windows is a second-class citizen?
>
> 64-bit support seemed to take forever to reach Windows.

Well, that was only because the backend didn't support it initially. It didn't support Linux, FreeBSD or Mac either. My understanding is that implementing 64-bit support for those platforms was fairly easy once support for 32-bit was in place. 64-bit on Windows was a much tougher nut to crack so it took a long time, but Walter did get it done. So... what's the problem?

On Monday, 6 June 2016 at 08:00:30 UTC, Laeeth Isharc wrote:
> Hi Ethan.

Ahoy.

> But don't you think that as a language D has intrinsically matured quite slowly?  Sociomantic began in 2008,or 2009,whenever it was,  but at the time given where the language was that must have been quite a courageous decision if one thought one might be using it to process large amounts of data.
>
> These is nothing wrong with maturing more slowly - indeed maybe more complex creatures take time for everything to come together. Things develop at their own pace.

Maturing slowly tends to be a counterpoint when I talk about it. And it's purely down to an information war thing. Compare to how C++ matures. And by matures, I mean the old dinosaur becomes more and more fossilized with age and is kept animated by cybernetic enhancements bolted on to the side in a haphazard manner. There's a lot of people I know that are fine with that because of entrenchment.

D is still ahead of the pack in terms of features. Communicating that, and why you should buy in to the better way, is a bit of a challenge. A colleague of mine complained that strings use another whacky operator (~) to join strings and it's just another way of doing string work, which came about because he hadn't looked deep enough in to the language to realise it's just normal array concatenation.

Yet despite being ahead of the pack, its slow adoption doesn't speak well for it. But there is precedent for slow adoption, at least in gaming. C++ was virtually unused until after the turn of the century, and now it's deeply entrenched. Moving to C++ was a pretty clear path forward for C programmers. Moving forward from C++? There's options (Rust, Swift, C#, D). And the other options have a far greater mindshare than D at the moment.

On Monday, 6 June 2016 at 07:18:56 UTC, Guillaume Piolat wrote:
> - well there is an AAA game using it now,

Replying solely to highlight that Unreal Engine has garbage collected since forever; and Unity is a .NET runtime environment and all the GC frills that come with it. GC in the AAA/indie gaming space is hardly a new concept.

On 6/6/2016 1:15 AM, Russel Winder via Digitalmars-d wrote:
>> * Safety has holes and bugs.
>
> Then so does C, C++ and Rust, so this is just a comment made because it
> can be made and sounds bad. Bad enough to salve the conscience of the
> speaker as to why they are not already using D.

It's pretty clear when they say that, and then continue using C++ which has no safety, that safety isn't the real reason.

Reminds me of an anecdote Andrei is tired of. In the 80s, a C++ developer said that compilation speed, speed, speed is the most important thing in a C++ compiler. This went on until it was pointed out to him that he was using Microsoft C++, which was the slowest at compiling by a factor of 4.
Clearly, what was actually most important to him was a name brand compiler (social proof), but he needed a more palatable reason, so he just latched on to one without much thought.

We have to be careful about being led down the garden path by people who say "I'd use your product if only it did X." I have a lot of experience with that, and it's very rare that they'll use it if you do X. They'll just respond with "yeah, ok, but what I really need is Y." This process never ends. Sometimes it's because they're embarrassed by the real reason, sometimes they just take pleasure in you dancing to their tune.

Paying attention to our existing users is a much more reliable source of information.

On Monday, 6 June 2016 at 09:07:32 UTC, tsbockman wrote:

> The Windows build for DMD, etc. seems to require tools that Microsoft no longer distributes publicly. I asked about this, but no one replied...
>     http://forum.dlang.org/post/lzmnllscqyyuqlusrwwe@forum.dlang.org

It would seem that most of the people who want to build custom DMD binaries are Linux users, so the Windows build system doesn't get the attention it should. Perhaps if more people were trying to build on Windows, it would be a different story (because we'd surely have more PRs). What we need is someone who lives and breathes Windows development to maintain it so that it uses whatever MS toolchain is available on the system and is always up to date. Still, I don't see that this makes Windows a second class citizen. Again, DMD works out of the box on Windows.

On 6/6/2016 2:07 AM, tsbockman wrote:
> The Windows build for DMD, etc. seems to require tools that Microsoft no longer
> distributes publicly. I asked about this, but no one replied...
>     http://forum.dlang.org/post/lzmnllscqyyuqlusrwwe@forum.dlang.org


Building dmd with Microsoft C++ isn't an official build. Building it with DMC++ is, works fine, and does not depend on Microsoft tools.

RefCounted does not work for classes, only for structs. Reason against adoption at least for me ;-).