Julia vs. D?

[jmh530 via Digitalmars-d]

The downside about calling embedding Julia is C is that 
everything's a pointer to the heap and you have to manually call 
the garbage collector. If the same thing were implemented in D, 
then D can handle the garbage collection as per normal. It seems 
like D is a better fit for Julia than C in that regard.

On Friday, 12 December 2014 at 06:57:24 UTC, Laeeth Isharc wrote:
> On Wednesday, 7 May 2014 at 14:57:36 UTC, Chris wrote:
>> On Wednesday, 7 May 2014 at 12:05:10 UTC, bachmeier wrote:
>>> On Wednesday, 7 May 2014 at 09:16:01 UTC, Chris wrote:
>>>> On Tuesday, 6 May 2014 at 23:19:47 UTC, Mason McGill wrote:
>>>>> On Tuesday, 6 May 2014 at 11:28:21 UTC, Chris wrote:
>>>>>> Maybe it's time to think about a D interface to Julia. If 
>>>>>> Julia catches on within the scientific community, it would 
>>>>>> be good to have a foot in the door. Science quickly 
>>>>>> creates large code bases, unfortunately, so far it's 
>>>>>> mostly Python and Matlab which makes it hard to use the 
>>>>>> algorithms in real world applications.
>>>>>
>>>>> I've actually been working on just that, on and off for a 
>>>>> few months now. Such a thing is kind of "anti-Julian", 
>>>>> though, since one of Julia's main goals is to reduce or 
>>>>> eliminate the need for mixed-language projects.
>>>>>
>>>>> However, with D, you can compile small shared libraries 
>>>>> that can be automatically bound to your users' favorite 
>>>>> dynamic runtimes (via compile-time reflection). I'm hoping 
>>>>> this will be good for both D and Julia, allowing library 
>>>>> developers to reach a broader audience, and library 
>>>>> consumers greater flexibility.
>>>>>
>>>>> I'll post on the D "announce" thread when I have something 
>>>>> working, and I'd definitely appreciate tests/bug-reports at 
>>>>> that time!
>>>>
>>>> I was also thinking in the direction of enabling D to use 
>>>> existing Julia code seamlessly, so you can just call it from 
>>>> D (extern(J)), and maybe even efficiently compile it into 
>>>> binaries along with D code, as you would with extern(C) 
>>>> calls now.
>>>
>>> It's really easy to do that with R. There is a package 
>>> RInside that makes it trivial to embed R in a C++ program, 
>>> and it's not difficult to use with D.
>>
>> Would be cool if we had something like this for Julia (if it 
>> really catches on).
>
> I guess you can call D from Julia very easily via the C API and 
> would just need to declare C calling convention in your D code.
>  It may be that with a combination of Julia and D one has the 
> best of both  worlds - no compromise with speed and efficient 
> resource use on the number crunching with a nice shell / 
> Ipython notebook that is still pretty fast on the front end.
>
> Nicer would be a wrapper a la PyD that seamlessly translates 
> between types.
>
> Then the other thing is to translate julia.h into D so that you 
> can embed Julia.  That's a little work but not so hard.  More 
> about how this works with C here:
>
> http://docs.julialang.org/en/release-0.3/manual/embedding/