Julia: A fresh approach to numerical computing

Post by simonster » Sat, Nov 08, 2014, 3:34 PM UTC

srparish wrote: post #59

wbhart wrote: post #47

Earlier quoted context omitted.

This very much depends on what you want to do with it and what your background is. Here are some things that might bother you. * Julia's approach to OOP is via multimethods, not the usual class/inheritance model. This might be annoying for people who don't want to learn how to be an effective programmer in the other paradigm. * Julia's garbage collector is not generational/incremental and in some corner cases, GC can…

* lack of threads: they do support multiple processes which can be useful for splitting up work for large computation, but not a substitute for threads * module compilation is not cached, so if you use very many modules your start-up times can be slow * error messages sometimes require some head scratching. For example, it's not uncommon to get an error that there's no available function convert(::SomeType, (Some, Ar…

Post by ViralBShah » Sat, Nov 08, 2014, 3:40 PM UTC

lebek wrote: post #58

wbhart wrote: post #47

Earlier quoted context omitted.

This very much depends on what you want to do with it and what your background is. Here are some things that might bother you. * Julia's approach to OOP is via multimethods, not the usual class/inheritance model. This might be annoying for people who don't want to learn how to be an effective programmer in the other paradigm. * Julia's garbage collector is not generational/incremental and in some corner cases, GC can…

What a fantastic list. And just to echo what the parent said, I find this so much more interesting than a list of 'good parts', which are generally easy to glean from the official docs. Back to Julia: lack of CUDA support was a limiting factor for me when I tried it a year ago.

Post by srparish » Sat, Nov 08, 2014, 3:44 PM UTC

simonster wrote: post #61

srparish wrote: post #59

Earlier quoted context omitted.

* lack of threads: they do support multiple processes which can be useful for splitting up work for large computation, but not a substitute for threads * module compilation is not cached, so if you use very many modules your start-up times can be slow * error messages sometimes require some head scratching. For example, it's not uncommon to get an error that there's no available function convert(::SomeType, (Some, Ar…

The first two are both WIP. Threading is https://github.com/JuliaLang/julia/tree/threads (although it hasn't been updated in a little while) and static compilation of modules is https://github.com/JuliaLang/julia/pull/8745

Post by wbhart » Sat, Nov 08, 2014, 3:48 PM UTC

ViralBShah wrote: post #64

wbhart wrote: post #20

I've been playing around with the Cxx library (currently only works with a source build of bleeding edge Julia) https://github.com/Keno/Cxx.jl It allows you to basically embed ordinary C++ code in Julia code, to interface with C++ libraries at runtime, and to slurp in entire .h files unmodified. (It also in theory allows a C++ REPL mode to be written, though such a thing does not exist for Julia yet.) It makes very c…

wbhart This sounds like a really interesting project! Is it already on Gitub? I suspect there are others in the Julia community who would love to join the effort too when you have something ready.

Post by andreasvc » Sat, Nov 08, 2014, 4:10 PM UTC

jghn wrote: post #33

RivieraKid wrote: post #29

Earlier quoted context omitted.

> Or at least I think `+(u, v)` or `u + v`, is more natural then `u.plus(v)` or `u.+(v)` I definitely agree with that, I said that object.method() style is often more natural. Typically when you have an object with some internal state and you want to send a message to it that will change its state. For example: threadPool.run(command) feels more natural than run(thread_pool, command).

It's more natural to you (and to be fair, most programmers who have used OOP languages) purely because you're used to languages which work that way.