On Monday, 10 August 2015 at 20:20:36 UTC, Tofu Ninja wrote:
> On Monday, 10 August 2015 at 19:34:26 UTC, rsw0x wrote:
>> On Monday, 10 August 2015 at 19:31:55 UTC, David Gileadi wrote:
>>> On 8/10/15 12:25 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>" wrote:
>>>> [...]
>>>
>>> …[insert your language here] has a long way to go… :)
>>
>> Which is why I think people are attracted towards D. It's very close to being "there". The large elephant in the room is the garbage collector. Every way to work around it feels like a massive, ugly hack.
>
> I am hoping once std.allocators gets done, language support for it will get added. Some way to get new and delete to forward to specific allocators.

overload new. It's "deprecated" but I used it the entire time I was required to use D without Phobos because it was just a massive pain.

>
> And some way to define a scope that uses an allocator such that every thing in that scope that gets allocated uses that allocator, including allocations down the call tree.

This exists, you can use a proxy GC.

On 11 August 2015 at 01:15, jmh530 via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Monday, 10 August 2015 at 14:13:53 UTC, Manu wrote:
>>
>> I really hope this is a top-priority goal for the switch to DDMD.
>
>
> My understanding is that 2.069 is supposed to bring DDMD support. I think there has been a lot of heated discussion about something that really isn't that far away. Nevertheless, I think you've made your case well about sort of merging LDC and DMD.
>
> One big positive for DMD is that it is very easy to install on Windows. Just about anyone can get up and running quite easily. It doesn't require the installation of MSVC (which I can't stand) or Min-GW at all. If DMD and LDC are sort of merged in the way that you say, I just hope care is taken to ensure that it is easy for people to get started with it.

I think some care would be taken to bundle the distribution so it's both minimal and convenient for users to install and get started with.

On Sun, Aug 9, 2015 at 12:33 AM, Walter Bright via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On 8/9/2015 12:18 AM, Iain Buclaw via Digitalmars-d wrote:
>
>> If the libraries were shared, this would reduce linking time, which in
>> various
>> benchmarks I've done is where most small projects spend the majority of
>> their
>> time doing.  But no one has as of yet come up with a feasibly
>> implementable idea
>> to do that.
>>
>
> We ship Phobos as a shared library on Linux, OSX and FreeBSD.
>

on OSX I only see libphobos2.a (including dmd 2.068)

On Monday, 10 August 2015 at 19:31:55 UTC, David Gileadi wrote:
> …[insert your language here] has a long way to go… :)

Yes, the real culprit is getting really good IDE support, and for that one need to write a high quality analyzer that can provide more information than a compiler.

As far as the language goes, I'd prefer a minimalistic core language backed up with a normalizing and caching solver. I don't really think fast initial compile time is all that important, if he compiler caches intermediate results intelligently I think one can get decent compilation speeds still.

On Monday, 10 August 2015 at 05:23:20 UTC, Walter Bright wrote:
> On 8/9/2015 9:26 PM, Tofu Ninja wrote:
>> On Sunday, 9 August 2015 at 20:51:32 UTC, Walter Bright wrote:
>>> On 8/9/2015 4:38 AM, Manu via Digitalmars-d wrote:
>>>> On 9 August 2015 at 15:31, Walter Bright via Digitalmars-d
>>>>>
>>>>> I agree, and now we ship a Phobos DLL, resolving that issue.
>>>>>
>>>>
>>>> Really? Where is it? (I can't see it in the distribution).
>>>>
>>>
>>> Should be in the bin directory.
>>>
>>
>> There is no Phobos dll, only Phobos lib.
>
> There's linux/lib32/libphobos2.so, for example.

But that is linux. You can't say "phobos dll" because everyone then expects dlls to work on windows, which still isn't the case. Its correct that we have a shared library version of phobos on linux, but a shared library version of phobos on windows is still in the future. I'm currently working on it, but there are so many issues with the language design, the export keyword, the module level visibility system the unittests etc etc that its going to take some more time. Also the front end transition from C++ to D hits me hard also.

On Monday, 10 August 2015 at 19:34:26 UTC, rsw0x wrote:
> On Monday, 10 August 2015 at 19:31:55 UTC, David Gileadi wrote:
>> On 8/10/15 12:25 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>" wrote:
>>> [...]
>>
>> …[insert your language here] has a long way to go… :)
>
> Which is why I think people are attracted towards D. It's very close to being "there". The large elephant in the room is the garbage collector. Every way to work around it feels like a massive, ugly hack.

Yes, it is not a good fit for D. Although, I find the Pony-lang approach interesting, but that is an actor language so it should not be compared to D, but to vibe.d.

Pony uses a per heap GC, a cross actor GC, and actor collection (collecting the whole actor and heap when the actor cannot receive more messages). Each actor (fiber in D) does not have a stack, the stack is per thread so I believe you "yield" when the stack has been unwound, they only use C-ABI when calling C functions.

But they also have an advanced pointer type system that can distinguish between at least 6 different reference-aliasing situations (or was it 12?).

https://www.youtube.com/watch?v=KvLjy8w1G_U

Anyway, it is refreshing. Maybe D can pick up some ideas from Pony.

On 8/11/2015 12:57 AM, Benjamin Thaut wrote:
> Also the front end transition from C++ to D hits me hard also.

It's going to hit everyone hard who works on the front end.

On 2015-08-11 09:08, Timothee Cour via Digitalmars-d wrote:

> on OSX I only see libphobos2.a (including dmd 2.068)

It's not supported on OS X.

-- 
/Jacob Carlborg

On Tuesday, 11 August 2015 at 00:56:57 UTC, Manu wrote:
> On 11 August 2015 at 01:15, jmh530 via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> One big positive for DMD is that it is very easy to install on Windows. Just about anyone can get up and running quite easily. It doesn't require the installation of MSVC (which I can't stand) or Min-GW at all. If DMD and LDC are sort of merged in the way that you say, I just hope care is taken to ensure that it is easy for people to get started with it.
>
> I think some care would be taken to bundle the distribution so it's both minimal and convenient for users to install and get started with.

Afaik DMD for Win64 requires the MS linker, so good luck without Visual Studio then. Same goes for LDC on Win64, although an LLVM COFF linker is under development. Serious system programming on Windows without MSVC and its C runtime? Not really an option; MinGW appears to be a dead end and never really fitted the Windows eco-system.

On Wednesday, 12 August 2015 at 13:32:10 UTC, kink wrote:
>
> Afaik DMD for Win64 requires the MS linker, so good luck without Visual Studio then. Same goes for LDC on Win64, although an LLVM COFF linker is under development. Serious system programming on Windows without MSVC and its C runtime? Not really an option; MinGW appears to be a dead end and never really fitted the Windows eco-system.


Well I'm not sure what percent "serious system programming" is done by other people, but I don't do any. I'll take your word that the MS linker is required.

Regardless, my point is more about the importance of a seamless installation on Windows than necessarily about what is required or not.

It is easy to get started with DMD on Windows, roughly equivalent to python or R (what I more commonly program in). This makes it easy for people to get started learning D and playing around with RDMD. That's a good thing. By contrast, it seems quite complicated to get LDC or GDC working on Windows. I see explanations of how to build from source. There also appears to be a binary on the github page, but I haven't gotten it working (I didn't exactly try that hard though). I just hope that if DMD is replaced or moved to using LLVM, then care is taken to ensure that installation remains as simple as it currently is.

This isn't unique to D. I just tried to install the Clang Windows binary and I got a message about MSVC integration failing. I have Visual Express 2008, so I figure maybe a newer version is required, but it doesn't say anywhere on the download page what version is required (the building page says VS 2013 is, but shouldn't the download page clearly explain that?). Moreover, it doesn't bring up any kind of option for me to download and install what is missing.

I would consider the installation of Lyx to be a good example of a seamless installation. Lyx requires MiKTeX, so if it detects it's missing during installation, then it will download it. It might also update your version of MiKTeX also.