www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Julia vs. D?

reply "Chris" <wendlec tcd.ie> writes:
I recently came across this article 
http://www.wired.com/2014/02/julia/. On the Julia homepage there 
are some benchmarks times relative to C. I know that bearophile 
has mentioned Julia several times on this forum. Has anyone 
compared D's vs Julia's performance as well as design features?
May 06 2014
next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 6 May 2014 at 09:11:30 UTC, Chris wrote:
 I recently came across this article 
 http://www.wired.com/2014/02/julia/. On the Julia homepage 
 there are some benchmarks times relative to C. I know that 
 bearophile has mentioned Julia several times on this forum. Has 
 anyone compared D's vs Julia's performance as well as design 
 features?

I can only comment on design features. You can think of Julia as a dynamic language similar to Python, with optional typing and for such a young language, a quite good JIT compiler backed by the LLVM backend. It is a multi-paradigm language, with an OO approach based on multi-methods and direct support for scientific programming. The target audience are the scientifc community that makes use of R, Python with NumPy and so on, which are currently disappointed with the performance of said systems. Their goal is to keep the programming flexibility of R and Python, while improving the performance without having to be forced to write C code. -- Paulo
May 06 2014
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 5/6/14, 8:23 AM, bearophile wrote:
 Paulo Pinto:

 You can think of Julia as a dynamic language similar to Python, with
 optional typing and for such a young language, a quite good JIT
 compiler backed by the LLVM backend.

Unlike dynamic languages, at running time all variables are strongly typed.

What do you mean?
May 06 2014
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 5/6/14, 10:41 AM, Chris wrote:
 On Tuesday, 6 May 2014 at 13:25:56 UTC, Ary Borenszweig wrote:
 On 5/6/14, 8:23 AM, bearophile wrote:
 Paulo Pinto:

 You can think of Julia as a dynamic language similar to Python, with
 optional typing and for such a young language, a quite good JIT
 compiler backed by the LLVM backend.

Unlike dynamic languages, at running time all variables are strongly typed.

What do you mean?

Just a wild guess: that the compiler infers the type of a variable and turns it into a static type. That would increase the security during runtime (plugins, libraries, crackers).

Julia doesn't have a compiler. There's no compile-time and run-time distinction. But functions are jitted before execution. I don't see how that means "variables are strongly typed". If you mean that at runtime they carry their type information, so do dynamic languages.
May 06 2014
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 06.05.2014 22:44, schrieb Chris:
 On Tuesday, 6 May 2014 at 17:10:39 UTC, Ary Borenszweig wrote:
 On 5/6/14, 10:41 AM, Chris wrote:
 On Tuesday, 6 May 2014 at 13:25:56 UTC, Ary Borenszweig wrote:
 On 5/6/14, 8:23 AM, bearophile wrote:
 Paulo Pinto:

 You can think of Julia as a dynamic language similar to Python, with
 optional typing and for such a young language, a quite good JIT
 compiler backed by the LLVM backend.

Unlike dynamic languages, at running time all variables are strongly typed.

What do you mean?

Just a wild guess: that the compiler infers the type of a variable and turns it into a static type. That would increase the security during runtime (plugins, libraries, crackers).

Julia doesn't have a compiler. There's no compile-time and run-time distinction. But functions are jitted before execution.

I know. I was talking about JIT compilation. There must be some kind of (jit) compiler.
 I don't see how that means "variables are strongly typed". If you mean
 that at runtime they carry their type information, so do dynamic
 languages.

But are the types immutable at runtime (in other dynamically typed languages) or can they be reassigned as in x = "Hello" x = 5 If yes, then I think this is what Julia is addressing, that a module, library or malevolent cracker cannot reassign a different type to a variable. x = 5 // Error! If so,

They can be re-assigned (http://forio.com/julia/repl/): julia> x = "Hello" "Hello" julia> x = 5 5 julia> Julia compiler works in a similar way to Self, Strongtalk, Dylan, Lisp and so on. The language is dynamic, with optional type annotations and the compiler does its best to infer the types. The design of the language is done in a JIT friendly way, while keeping its dynamic capabilities. -- Paulo
May 06 2014
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 06.05.2014 23:00, schrieb bearophile:
 Paulo Pinto:

 They can be re-assigned (http://forio.com/julia/repl/):

 julia> x = "Hello"
 "Hello"
 julia> x = 5
 5
 julia>

I think the JIT compiler splits those two in two different variables :-)
 The language is dynamic,

The language tries its best to be flexible as a dynamic language. But variables never carry a run-time type tag, unlike in Lisp. Bye, bearophile

That is an implementation detail I would say, but then again I only saw a few talks online and have not played that much with it. -- Paulo
May 06 2014
prev sibling parent Ary Borenszweig <ary esperanto.org.ar> writes:
On 5/7/14, 6:18 AM, "Marc Sch├╝tz" <schuetzm gmx.net>" wrote:
 On Wednesday, 7 May 2014 at 07:27:42 UTC, Mason McGill wrote:
 On Tuesday, 6 May 2014 at 21:00:18 UTC, bearophile wrote:
 The language tries its best to be flexible as a dynamic language. But
 variables never carry a run-time type tag, unlike in Lisp.

Hmm... Then how can I do this: x = 5 typeof(x) # evaluates to "Int64" x = 5.0 typeof(x) # evaluates to "Float64" ? Is Julia doing something trickier than I think it is? Or do you just mean they don't carry type tags after compilation?

Maybe the first x stops existing, and a new one is created on reassignment? A more interesting case is this (pseudo code, don't know Julia syntax): x = 5 if (...) { x = "Hello" } typeof(x) # ??? Is that disallowed?

I just tried it. I also used the code_llvm function to see what llvm is generated. Some lines: %8 = call %jl_value_t* jl_box_int32(i32 %0), !dbg !4339 (an int is being boxed and you get a pointer to a jl_value_t) %13 = call %jl_value_t* jl_apply_generic(%jl_value_t* inttoptr (i64 4373507136 to %jl_value_t*), %jl_value_t** %6, i32 2), !dbg !4346 (a generic function call is being made) So, there clearly must be runtime information associated to the variables, at least when they need boxing or this kind of multi-dispatch at runtime.
May 07 2014
prev sibling parent Dejan Lekic <dejan.lekic gmail.com> writes:
bearophile wrote:

 Chris:
 
 That would increase the security during runtime (plugins,
 libraries, crackers).

Yes, and also gives almost native performance. Bye, bearophile

One can argue that every modern JIT achieves "almost native performance" ... -- http://dejan.lekic.org
May 06 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Paulo Pinto:

 You can think of Julia as a dynamic language similar to Python, 
 with optional typing and for such a young language, a quite 
 good JIT compiler backed by the LLVM backend.

Unlike dynamic languages, at running time all variables are strongly typed. Bye, bearophile
May 06 2014
prev sibling next sibling parent "Chris" <wendlec tcd.ie> writes:
On Tuesday, 6 May 2014 at 11:20:33 UTC, Paulo Pinto wrote:
 On Tuesday, 6 May 2014 at 09:11:30 UTC, Chris wrote:
 I recently came across this article 
 http://www.wired.com/2014/02/julia/. On the Julia homepage 
 there are some benchmarks times relative to C. I know that 
 bearophile has mentioned Julia several times on this forum. 
 Has anyone compared D's vs Julia's performance as well as 
 design features?

I can only comment on design features. You can think of Julia as a dynamic language similar to Python, with optional typing and for such a young language, a quite good JIT compiler backed by the LLVM backend. It is a multi-paradigm language, with an OO approach based on multi-methods and direct support for scientific programming. The target audience are the scientifc community that makes use of R, Python with NumPy and so on, which are currently disappointed with the performance of said systems. Their goal is to keep the programming flexibility of R and Python, while improving the performance without having to be forced to write C code. -- Paulo

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.
May 06 2014
prev sibling next sibling parent "Chris" <wendlec tcd.ie> writes:
On Tuesday, 6 May 2014 at 13:25:56 UTC, Ary Borenszweig wrote:
 On 5/6/14, 8:23 AM, bearophile wrote:
 Paulo Pinto:

 You can think of Julia as a dynamic language similar to 
 Python, with
 optional typing and for such a young language, a quite good 
 JIT
 compiler backed by the LLVM backend.

Unlike dynamic languages, at running time all variables are strongly typed.

What do you mean?

Just a wild guess: that the compiler infers the type of a variable and turns it into a static type. That would increase the security during runtime (plugins, libraries, crackers).
May 06 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Chris:

 That would increase the security during runtime (plugins, 
 libraries, crackers).

Yes, and also gives almost native performance. Bye, bearophile
May 06 2014
prev sibling next sibling parent "Brian Rogoff" <brogoff gmail.com> writes:
On Tuesday, 6 May 2014 at 11:20:33 UTC, Paulo Pinto wrote:
 On Tuesday, 6 May 2014 at 09:11:30 UTC, Chris wrote:
 I recently came across this article 
 http://www.wired.com/2014/02/julia/. On the Julia homepage 
 there are some benchmarks times relative to C. I know that 
 bearophile has mentioned Julia several times on this forum. 
 Has anyone compared D's vs Julia's performance as well as 
 design features?

I can only comment on design features. You can think of Julia as a dynamic language similar to Python, with optional typing and for such a young language, a quite good JIT compiler backed by the LLVM backend. It is a multi-paradigm language, with an OO approach based on multi-methods and direct support for scientific programming. The target audience are the scientifc community that makes use of R, Python with NumPy and so on, which are currently disappointed with the performance of said systems. Their goal is to keep the programming flexibility of R and Python, while improving the performance without having to be forced to write C code.

Excellent summary, one quibble, you omit MATLAB and Octave users from your target audience, when they may be the most important one. Julia reads much more like MATLAB than like R or Python, and numerical linear algebra is one of the things Julia is being aimed at. It has a very rich language of types, and a macro system. Disappointingly, whilst you can annotate function arguments and variables with types, you can't annotate the function itself with a return type. TL;DR MATLAB reimagined by Lisp hackers. I like it! Not really competing in the same space as D. Yes, I know, I'm pigeonholing D, which is supposed to be a wide spectrum language, etc. etc.
May 06 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Dejan Lekic:

 One can argue that every modern JIT achieves "almost native 
 performance" ...

OK. Then for Julia remove the "almost" :-) Bye, bearophile
May 06 2014
prev sibling next sibling parent "Chris" <wendlec tcd.ie> writes:
On Tuesday, 6 May 2014 at 17:10:39 UTC, Ary Borenszweig wrote:
 On 5/6/14, 10:41 AM, Chris wrote:
 On Tuesday, 6 May 2014 at 13:25:56 UTC, Ary Borenszweig wrote:
 On 5/6/14, 8:23 AM, bearophile wrote:
 Paulo Pinto:

 You can think of Julia as a dynamic language similar to 
 Python, with
 optional typing and for such a young language, a quite good 
 JIT
 compiler backed by the LLVM backend.

Unlike dynamic languages, at running time all variables are strongly typed.

What do you mean?

Just a wild guess: that the compiler infers the type of a variable and turns it into a static type. That would increase the security during runtime (plugins, libraries, crackers).

Julia doesn't have a compiler. There's no compile-time and run-time distinction. But functions are jitted before execution.

I know. I was talking about JIT compilation. There must be some kind of (jit) compiler.
 I don't see how that means "variables are strongly typed". If 
 you mean that at runtime they carry their type information, so 
 do dynamic languages.

But are the types immutable at runtime (in other dynamically typed languages) or can they be reassigned as in x = "Hello" x = 5 If yes, then I think this is what Julia is addressing, that a module, library or malevolent cracker cannot reassign a different type to a variable. x = 5 // Error! If so,
May 06 2014
prev sibling next sibling parent "Chris" <wendlec tcd.ie> writes:
On Tuesday, 6 May 2014 at 20:52:20 UTC, Paulo Pinto wrote:
 Am 06.05.2014 22:44, schrieb Chris:
 On Tuesday, 6 May 2014 at 17:10:39 UTC, Ary Borenszweig wrote:
 On 5/6/14, 10:41 AM, Chris wrote:
 On Tuesday, 6 May 2014 at 13:25:56 UTC, Ary Borenszweig 
 wrote:
 On 5/6/14, 8:23 AM, bearophile wrote:
 Paulo Pinto:

 You can think of Julia as a dynamic language similar to 
 Python, with
 optional typing and for such a young language, a quite 
 good JIT
 compiler backed by the LLVM backend.

Unlike dynamic languages, at running time all variables are strongly typed.

What do you mean?

Just a wild guess: that the compiler infers the type of a variable and turns it into a static type. That would increase the security during runtime (plugins, libraries, crackers).

Julia doesn't have a compiler. There's no compile-time and run-time distinction. But functions are jitted before execution.

I know. I was talking about JIT compilation. There must be some kind of (jit) compiler.
 I don't see how that means "variables are strongly typed". If 
 you mean
 that at runtime they carry their type information, so do 
 dynamic
 languages.

But are the types immutable at runtime (in other dynamically typed languages) or can they be reassigned as in x = "Hello" x = 5 If yes, then I think this is what Julia is addressing, that a module, library or malevolent cracker cannot reassign a different type to a variable. x = 5 // Error! If so,

They can be re-assigned (http://forio.com/julia/repl/): julia> x = "Hello" "Hello" julia> x = 5 5 julia> Julia compiler works in a similar way to Self, Strongtalk, Dylan, Lisp and so on. The language is dynamic, with optional type annotations and the compiler does its best to infer the types. The design of the language is done in a JIT friendly way, while keeping its dynamic capabilities. -- Paulo

So what's the point then? To have the program crash at runtime or better jit-time when the types are not assigned correctly? Then again, if types can be changed dynamically, how can the jit compiler say it's "wrong"? Or is there something I've missed?
May 06 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Paulo Pinto:

 They can be re-assigned (http://forio.com/julia/repl/):

 julia> x = "Hello"
 "Hello"
 julia> x = 5
 5
 julia>

I think the JIT compiler splits those two in two different variables :-)
 The language is dynamic,

The language tries its best to be flexible as a dynamic language. But variables never carry a run-time type tag, unlike in Lisp. Bye, bearophile
May 06 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Paulo Pinto:

 That is an implementation detail I would say,

It's not an implementation detail, it has consequences on the kind of code you are allowed to write, because it's not really a dynamic language. After the JIT compilation it's "statically" typed, with some niceties like the type splitting you have seen with the x variable. In Julia you can't write all the programs you can write in Python. But in practice the limitations are not a problem for the scientific code, and the advantages are great. Bye, bearophile
May 06 2014
prev sibling next sibling parent "Mason McGill" <mmcgill caltech.edu> writes:
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!
May 06 2014
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 6 May 2014 at 21:31:32 UTC, bearophile wrote:
 Paulo Pinto:

 That is an implementation detail I would say,

It's not an implementation detail, it has consequences on the kind of code you are allowed to write, because it's not really a dynamic language. After the JIT compilation it's "statically" typed, with some niceties like the type splitting you have seen with the x variable. In Julia you can't write all the programs you can write in Python. But in practice the limitations are not a problem for the scientific code, and the advantages are great. Bye, bearophile

Maybe we are talking across each other, but JIT code is always statically typed after native code generation. The approach taken by Julia is no different than other dynamic languages that enjoy AOT native compilers. If you mean Julia allows for less dynamic programming cleverness as Python, there I agree with you. I guess I need to play more with it, maybe then I can better grasp what you mean. -- Paulo
May 06 2014
prev sibling next sibling parent "Mason McGill" <mmcgill caltech.edu> writes:
On Tuesday, 6 May 2014 at 21:00:18 UTC, bearophile wrote:
 The language tries its best to be flexible as a dynamic 
 language. But variables never carry a run-time type tag, unlike 
 in Lisp.

Hmm... Then how can I do this: x = 5 typeof(x) # evaluates to "Int64" x = 5.0 typeof(x) # evaluates to "Float64" ? Is Julia doing something trickier than I think it is? Or do you just mean they don't carry type tags after compilation?
May 07 2014
prev sibling next sibling parent "Chris" <wendlec tcd.ie> writes:
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.
May 07 2014
prev sibling next sibling parent "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Wednesday, 7 May 2014 at 07:27:42 UTC, Mason McGill wrote:
 On Tuesday, 6 May 2014 at 21:00:18 UTC, bearophile wrote:
 The language tries its best to be flexible as a dynamic 
 language. But variables never carry a run-time type tag, 
 unlike in Lisp.

Hmm... Then how can I do this: x = 5 typeof(x) # evaluates to "Int64" x = 5.0 typeof(x) # evaluates to "Float64" ? Is Julia doing something trickier than I think it is? Or do you just mean they don't carry type tags after compilation?

Maybe the first x stops existing, and a new one is created on reassignment? A more interesting case is this (pseudo code, don't know Julia syntax): x = 5 if (...) { x = "Hello" } typeof(x) # ??? Is that disallowed?
May 07 2014
prev sibling next sibling parent "Chris" <wendlec tcd.ie> writes:
On Tuesday, 6 May 2014 at 21:31:32 UTC, bearophile wrote:
 Paulo Pinto:

 That is an implementation detail I would say,

It's not an implementation detail, it has consequences on the kind of code you are allowed to write, because it's not really a dynamic language. After the JIT compilation it's "statically" typed, with some niceties like the type splitting you have seen with the x variable. In Julia you can't write all the programs you can write in Python. But in practice the limitations are not a problem for the scientific code, and the advantages are great. Bye, bearophile

So this basically means: setName(name) userName = name; // string type extern module / cracker: setName(5.0) // Error or at least doesn't affect original userName Right or wrong?
May 07 2014
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
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.

That would be very good. If julia is to become a/the norm for scientific computing, D could form the full-power systems/applications partner very neatly.
May 07 2014
prev sibling next sibling parent "bachmeier" <no spam.net> writes:
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.
May 07 2014
prev sibling parent "Chris" <wendlec tcd.ie> writes:
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).
May 07 2014