Slashdot Mirror


Julia Programming Language Receives $600k Donation

jones_supa writes: The Julia programming language has received a $600k donation from Moore Foundation. The foundation wants to get the language into a production version. This has a goal to create more efficient and powerful scientific computing tools to assist in data-driven research. The money will be granted over the next two years so the Julia Language team can move their core open computing language and libraries into the first production version. The Julia Language project aims to create a dynamic programming language that is general purpose but designed to excel at numerical computing and data science. It is especially good at running MATLAB and R style programs.

106 comments

  1. If we've tried, but can never understand Julia... by AnontheDestroyer · · Score: 3, Funny

    ...are we doomed to forever playing with our own Python?

  2. So . . . by OverlordQ · · Score: 1

    aims to create a dynamic programming language that is general purpose but designed to excel at numerical computing and data science. It is especially good at running MATLAB and R style programs.

    So they're re-inventing Python?

    --
    Your hair look like poop, Bob! - Wanker.
    1. Re:So . . . by Anonymous Coward · · Score: 0

      Python is pretty slow.

    2. Re:So . . . by Beck_Neard · · Score: 4, Informative

      Not at all. Julia is just-in-time compiled to native code. You can basically get C-like performance in pure julia: http://julialang.org/benchmark...

      There's also a powerful type system and lisp-style macros, along with support for parallel programming and lightweight threads, allowing you to do stuff like: https://gist.github.com/anj1/2...

      (that's just a toy example, of course)

      --
      A fool and his hard drive are soon parted.
    3. Re:So . . . by dotancohen · · Score: 1

      Python is pretty slow.

      Use Numpy for data analysis. It runs on ATLAS, an open source BLAS implementation and is plenty fast.

      --
      It is dangerous to be right when the government is wrong.
    4. Re:So . . . by Beck_Neard · · Score: 1

      How does that change the fact that Python is slow? Julia uses BLAS as a linear algebra backend too, but that has nothing to do with this.

      --
      A fool and his hard drive are soon parted.
    5. Re:So . . . by Anonymous Coward · · Score: 0

      If you are simply calling a library (written in C) there will not be a big speed difference between Julia and Python.
      The big difference is that you could write this library in Julia with similar performance to the C code.
      That's the biggest attraction to me: a high level language where you do not need to fall back to C for doing performance oriented or even really low level programming

    6. Re:So . . . by Anonymous Coward · · Score: 0

      How does that show "basically get C-like performance"? Sure a few of the benchmarks they show are close to C, but the worst is 5x slower.

    7. Re:So . . . by Beck_Neard · · Score: 2

      The best is actually faster than C, and the worst is 2.1x slower, not 5x slower (numerical values given in http://julialang.org/ ). And that's just the fibonacci benchmark; the other ones are within 50% of C performance except for rand_mat_stat which is 60% slower than C (this is due to the garbage collector, apparently).

      --
      A fool and his hard drive are soon parted.
    8. Re:So . . . by HiThere · · Score: 1

      Added to which they've removed Python's GIL. But the documentation doesn't make it clear how to get a character's General Category, despite the fact that many of the functions use it in deriving their answer (e.g., isalnum). This would be a real annoyance were I seriously considering using it.

      --

      I think we've pushed this "anyone can grow up to be president" thing too far.
    9. Re:So . . . by Beck_Neard · · Score: 1

      import Base.UTF8proc.category_code

      category_code('')

      --
      A fool and his hard drive are soon parted.
    10. Re:So . . . by microbox · · Score: 2

      No they are not. Python has a two-language problem, for a starters. Also, Python is a pain in the neck for scientific computing, which is my day job, btw. Also Julia is soon to work seamlessly with both C and C++ (like, include header, load library, and execute code without any bindings or nonsense). Julia has the potential to be properly threaded, but is really aimed at being seamlessly multi-process. That mean seamlessly moving data between processes -- even on different computers and networks. This is seriously useful for scientific computing. Julia is much more like Matlab, and Matlab is much, much, much better for scientific computing than python ever can be. Also, Julia should work faster than python once the garbage collector has been updated.

      --

      Like all pain, suffering is a signal that something isn't right
    11. Re:So . . . by microbox · · Score: 1

      Part of the point of Julia is that you don't have to screw around with different libraries to get things working. Ever done matrix manipulations on Matlab? It is incomparable to anything Python and Numpy can provide. But Julia works the same.

      --

      Like all pain, suffering is a signal that something isn't right
    12. Re:So . . . by microbox · · Score: 3, Informative

      There will be a big "ease of use" benefit to using Julia though. Julia requires to bindings to run C code (and soon C++ code, including all those fancy templates). That's because Julia doesn't suffer the two-language problem that every other language does. Julia types are LLVM types, and C types are LLVM types. Same with function calls. It's so simple and convenient.

      --

      Like all pain, suffering is a signal that something isn't right
    13. Re:So . . . by microbox · · Score: 1

      Because Julia is compiled into the same bit code that C is compiled into when compiled with the Clang (Apple) compiler. That means no translation necessary for calling to and from C code (and soon C++). When Julia gets slower it is because: (1) the garbage collector is immature, and (2) you are using facilities that simply aren't there in C.

      --

      Like all pain, suffering is a signal that something isn't right
    14. Re:So . . . by edtice1559 · · Score: 1

      A better performance comparison would be against a garbage-collected language like C++11 / 14 with unique_ptr and similar constructs.

    15. Re:So . . . by dotancohen · · Score: 1

      If you are simply calling a library (written in C) there will not be a big speed difference between Julia and Python. The big difference is that you could write this library in Julia with similar performance to the C code. That's the biggest attraction to me: a high level language where you do not need to fall back to C for doing performance oriented or even really low level programming

      Thank you, now I see what the fuss is about. I had previously had the impression that Julia is more like Python (scripting, great syntax) than R (numerical calculation performance, horrible syntax). I'll have to take a better look at it.

      --
      It is dangerous to be right when the government is wrong.
    16. Re:So . . . by dotancohen · · Score: 1

      How does that change the fact that Python is slow? Julia uses BLAS as a linear algebra backend too, but that has nothing to do with this.

      Presumably the i.e. LA operations that the OP were doing were slow. If the OP is complaining that the code that presents his GUI takes an extra 100ms to load, then he is just trolling. This is a discussion of programming languages for scientific, statistical, and other numeric operations. In Python those operations can be done with not-slow code with the proper library.

      --
      It is dangerous to be right when the government is wrong.
    17. Re:So . . . by dotancohen · · Score: 1

      Part of the point of Julia is that you don't have to screw around with different libraries to get things working. Ever done matrix manipulations on Matlab? It is incomparable to anything Python and Numpy can provide. But Julia works the same.

      Actually I haven't done matrix manipulations in Matlab but I believe that PyLab (based on Numpy and Scipy) addresses the concern that you make. I don't use Matlab so I cannot make a better comparison.

      --
      It is dangerous to be right when the government is wrong.
    18. Re:So . . . by Anonymous Coward · · Score: 0

      Numpy is badly designed for mathematics. It has this infuriating habit of arbitrarily converting types (eg vectors to lists, 2d matrices to sometimes vectors, sometimes lists, etc) and has inconsistent APIs. Moreover, you can easily use several times too much memory due to incorrect garbage collection and implicit copy operations. To be sure, all these problems can be worked around, but by the time you're done, your code is crazy complex for something that shouldn't take that much effort.

      It's often easier to write a C program and use BLAS directly instead of making a "small" Numpy program robust and safe.

    19. Re:So . . . by dotancohen · · Score: 1

      Thank you. I would love to see an example of the issue. Numpy mostly works with it's own ndarray datatype, so I suspect that you got the issues when performing Numpy operations with native Python lists, sets, and tuples?

      --
      It is dangerous to be right when the government is wrong.
    20. Re:So . . . by majid_aldo · · Score: 1

      - numpy converting to lists??? read the docs to learn about type precedence.

      - garbage collection is python's job. read the decent docs to know when things are copied vs in place

      - easier to write in C?? please tell me you're joking

      --
      --- widget evolution: enhanced, plus, super, ultra, extreme, exxxtreme, ultra-extreme, ..etc.
    21. Re:So . . . by Beck_Neard · · Score: 1

      > In Python those operations can be done with not-slow code with the proper library.

      Not always.

      Fact is, Python has a two-language problem.

      --
      A fool and his hard drive are soon parted.
    22. Re:So . . . by Beck_Neard · · Score: 1
      --
      A fool and his hard drive are soon parted.
    23. Re:So . . . by dotancohen · · Score: 1

      http://cyrille.rossant.net/wha...

      That was a great read, and I could add some points of my own. The author goes off track at the end (complaining about distributing cross-platform binaries to non-technical users has no place in an article about scientific computation development) which comes off as grasping for straws, but otherwise I do see that the author is sincere and wrote the article in order to help improve Python, which he obviously esteems.

      That was one datapoint, and it doesn't really address the GP AC's concern to which I had replied. The only relevancy between the two is the mention of hstack() and zeros() requiring a tuple as the argument, and even the author mentions that the only issue with that is teaching it to beginners. Anybody doing scientific computing will understand that a tuple can be an argument to a function, and may superficially look like double parentheses. That should be reason for laughter, not complaint.

      I'm sure that there is no lack of similar datapoints against Matlab, Maple, and R. Julia probably has similar issues. The more a technology is used, the more people complain about it (see: Windows, Java). None of the issues on that page are really major, and especially not for new users who don't have a legacy Python 2 or Matlab background. The only really problematic issue mentioned on that page is one that is not limited to Python scientific computing: the GIL. You can complain about the GIL all day and I'll stand by you!

      --
      It is dangerous to be right when the government is wrong.
    24. Re:So . . . by HiThere · · Score: 1

      Hmmm... I'd looked under string and character documentation, but didn't find a reference to that function. Not surprising given where they chose to stash it, but it strikes me as an unreasonably obscure location. Surely character should have at least a cross reference. (Well, perhaps it did and I missed it. I wasn't seriously considering switching to Julia. And perhaps the locations would have been obvious to someone who was acquainted with the code. Even I could tell it was being used in some functions.)

      When I was seriously considering it my real problem was with its model of parallelism. It seems excellent for handling matrices, but that's not at all what I need.

      --

      I think we've pushed this "anyone can grow up to be president" thing too far.
  3. It's probably not aimed at you by dlenmn · · Score: 4, Informative

    Julia is aimed at people who do math-heavy problems (like computational physics), so that might be why you haven't heard of it. I think it's been on /. before.

    I've never used Julia (the computing resources I have access to don't support Julia), but I've been following it, and the language looks pretty impressive: the ease of python/matlab with the speed of fortran/c. It's pretty impressive for a language you can use interactively.

    1. Re:It's probably not aimed at you by Anonymous Coward · · Score: 0

      WTF is that typing, err... I mean dynamic typing and JIT compilation. Probably great for scripting but not for serious code.

    2. Re:It's probably not aimed at you by Anonymous Coward · · Score: 0

      Definitely looks impressive. Would have been nice if it had been around before R and Python had become so established but R probably has an insurmountable head start in the "any random model or test that you could ever possibly need is available with a single command" department.

    3. Re:It's probably not aimed at you by TeknoHog · · Score: 1

      the language looks pretty impressive: the ease of python/matlab with the speed of fortran/c.

      My two favourite languages since about 2000 have been Python and Fortran, so you can imagine my joy of finding Julia. Of course it's not a perfect solution for everything, and I still prefer Python for most tasks that are not compute heavy. This is mostly due to the plethora of libraries available by default.

      On the issue of ease, Julia's syntax actually borrows heavily from Fortran, and thus avoids most of the whitespace thing.

      --
      Escher was the first MC and Giger invented the HR department.
    4. Re:It's probably not aimed at you by Anonymous Coward · · Score: 0

      Julia is aimed at people who do math-heavy problems (like computational physics), so that might be why you haven't heard of it.

      If only there were some kind of FORmula TRANslation language that would allow me to do math-heavy problems and has over 40 years of proven excellence.

    5. Re:It's probably not aimed at you by Anonymous Coward · · Score: 0

      Julia has facilities to call just about any external programming language: C/C++, Python, R, etc. https://github.com/stevengj/PyCall.jl

    6. Re:It's probably not aimed at you by edtice1559 · · Score: 1

      Uh JIT compilation produces faster code than fully pre-compiling. This sounds like somebody read - decades ago - that Java was slow and now subject to primacy confirmation bias and perseverance confirmation bias. A JIT language is faster because the JIT compiler can profile the code and then reoptimize. To get this with a direct-to-object-code compilation, you have to build it once, profile, then build again with the new information. And then if the usage changes somehow, the optimizations become out of date.

    7. Re:It's probably not aimed at you by Anonymous Coward · · Score: 1

      That's wrong on so many levels. For example, suppose the optimization gains you a few hundred nanos compared to precompiled code. In a typical Java program you'll never amortize the JIT compilation phase itself, which must be performed each time that the program runs, and you're STILL at the mercy of the garbage collector, which is going to completely trash your cache and nullify all the JIT gains at random times. Moreover, it misses the point that anyone who truly cares about speed will of course spend the time to profile, followed by *changing the datastructures* rather than hoping a few opcode changes will magically the big-oh complexity.

       

    8. Re: It's probably not aimed at you by Anonymous Coward · · Score: 0

      You don't have a clue so sh* the f*ck up

    9. Re: It's probably not aimed at you by Anonymous Coward · · Score: 0

      Great job of removing indention as a block construct to only introduce 'end' block markers. Look at the link you posted and see its effect in action. The julia code is indented *exactly* as the python code, but it is about five lines longer due to the end statements. The end statements are just redundant fluff, the indention is enough to delineate blocks. Python is beautiful.

    10. Re: It's probably not aimed at you by TeknoHog · · Score: 1

      The end statements are just redundant fluff, the indention is enough to delineate blocks. Python is beautiful.

      Unfortunately, this isn't so simple in the real world. When different people edit the source on different editors and operating systems, you may end up with blocks that look aligned but aren't. This is generally due to mixing spaces and tab characters. The end statement does take up space and visual attention, but it makes the syntax more robust against such glitches.

      BTW, Python's use of the colon is mostly redundant fluff. It serves a function for one-liners "if this: do_that" but if this is what you want, you might as well go back to the butt-ugly C syntax with its semicolons and braces.

      --
      Escher was the first MC and Giger invented the HR department.
    11. Re:It's probably not aimed at you by Anonymous Coward · · Score: 0

      Using a JIT compiler does not imply using a garbage collector. Nor does it prevent doing the data structure or algorithm optimizations.

    12. Re: It's probably not aimed at you by Anonymous Coward · · Score: 0

      Indentions are not a practical problem, but a tool to get code style very similar across devs from the get go. If you have an issue with indentions clearly you are doing something wrong -- simply use spaces only, no tabs and you are good to go. The colon is not a problem either. Really if *these* is your main concerns you are not thinking about the right problems. A programming language is means to and end, and Python is great at that without getting in the way. It writes and reads almost as succint as pseudo code does, i.e. as we think. From the example linked above alone we can see that Julia already adds fluff to exactly no avail at all IMHO.

  4. jesus thats all it takes? by nimbius · · Score: 0, Flamebait

    as a jaded sysadmin im in the wrong business. Ive learned perl and python and bash and even picked up a case of php along the way but if all it takes for hipsters to belch a half a million dollars at me is a language? then this is where it begins, slashdot.

    My language is called twerk-cankle. It was named after a dance that comes from a small island in the osowhatwhocares islands and is ritually performed with great efficiency. my classes are called palpatisms and you instantiate them by using the pelvic_thrust operator. all code is terminated with yoskrilldropit(hard) which calls a completely gender neutral subroutine to issue enlightenments to my interpreter. The interpreter which you can download under the BSD, MIT, PCP, GPL, and my own personal DERP license uses spare CPU cycles to search the ram heap for Kony. Ive also released a debugger called shitlord which runs as an elevated user once after checking its privilege and enrolling a small orphinage of women and nuns into the girls who code program. Processes when threaded are done so in a way that recognizes france's tragedy and assert a macklemore call to find 99 cent urine scented clothing on the memory bus.

    --
    Good people go to bed earlier.
    1. Re:jesus thats all it takes? by MightyMartian · · Score: 3, Funny

      I won't be silenced until Brainfuck gets the recognition it deserves!

      --
      The world's burning. Moped Jesus spotted on I50. Details at 11.
    2. Re:jesus thats all it takes? by Anonymous Coward · · Score: 0

      I need the DERP license terms and conditions, I was thinking of applying it to all my projects from here out.

      Also please don't forget to call dispose() on your macklemoring.

    3. Re:jesus thats all it takes? by glwtta · · Score: 4, Interesting

      What is actually wrong with you?

      Julia is a useful niche language with a sizable community, not some bullshit vanity project. Unfortunately it has not chance of dislodging R, and I'll never understand the decision to make it dynamic, but it fills a role that nothing else does, at the moment.

      Also, I have no idea what you think the word "hipster" means, or why you're so angry about it.

      --
      sic transit gloria mundi
    4. Re:jesus thats all it takes? by Anonymous Coward · · Score: 0

      Where can I buy the twerk-cankle for dummies book? I've been waiting for a language just like this! I can't tell you how frustrated I am with using Perl to maximize my urine scented clothing!

    5. Re:jesus thats all it takes? by lachlan76 · · Score: 1

      Sure, but it's not necessarily competing with R. There are a _lot_ of Matlabbers who don't use C interface yet still run uncomfortably lengthy simulations, and for them Julia is hugely advantagous. Static typing would be something of a turnoff when you're coming from something like Matlab where you don't think about types at all in most programs, especially faffing about in the REPL.

    6. Re:jesus thats all it takes? by Anonymous Coward · · Score: 0

      "Unfortunately it has not chance of dislodging R"

      ^this

      capcha: falsity

    7. Re:jesus thats all it takes? by Anonymous Coward · · Score: 0

      Bleh, I have to use Matlab, but I don't have to like the steaming pile. Give me a real language that has been thought out from the start (rather than evolving and devolving from a bunch of matrix routines someone wrote in the 80s) and convince my research colleagues to use it and I'll be a happy man.

    8. Re:jesus thats all it takes? by Anonymous Coward · · Score: 0

      mknod -m 600 home_for_brainfuck c 1 3
      mv brainfuck* home_for_brainfuck
      There!

    9. Re:jesus thats all it takes? by Anonymous Coward · · Score: 0

      I'm someone who has been using R since it was in beta (I guess I'm on the record somewhere from that time talking about it).

      I actually do see Julia dislodging R eventually.

      R is wonderful, and I still use it all the time for various things--I'm about as fluent in it as anyone you'll meet, but it does has its limitations. The biggest of these are speed and memory use, but also the ad hoc way that parallelism is handled. There are other problems too, like the type system and whatnot, but the resource use and access is the biggest area.

      Sure, you can wrap R around underling C/C++ or fortran, and there are parallelism libraries, but these aren't really integrated into the language in the way they should be, and the wrapping strategy eventually will bump up against the fact that you're not going to push everything down into the lower-level languages, so the R becomes a bottleneck. To avoid it, you have to go to the lower-level languages, which then defeats the purpose.

      For years, I've had this sense that you could get low-level performance from a high-level language, but nothing really seemed to be quite right. There was that HPC language competition that never seemed to go anywhere, OCaml seemed promising for awhile, and then Go, but none of these really were right.

      Julia is that language. It's amazingly fast--I was sort of skeptical myself until I had a computational problem recently where the R version ran on the order of a day or so, and then a fairly straightforward Julia port ran on the order of a few minutes.

      Julia at this point also reminds me of what it was like when R was first starting out--it has the same vibe.

      I fully suspect that Julia will surpass R in use within a decade, as people realize how limited R is compared to Julia. It's going to happen, especially as parallelism and big data becomes more widespread. And if it doesn't become widely adopted, what do I care? Their loss. There's enough of a community already that I don't feel a loss from R.

      The only problem I have, if it really is a problem, is that I'd like to see Julia bootstrapped, to eventually have a Julia compiler written in Julia. It doesn't matter too much, but it would be nice to remove that extra layer--I also think that self-hosting languages reflect a certain level of maturity and stability. The developers talked about it as an idea, but sort of said at the time that critical parts were written in something that might make it difficult, but that it wasn't impossible. So we'll see.

    10. Re:jesus thats all it takes? by jma05 · · Score: 1

      I doubt that Julia is going to surpass R in a decade as you say. I use R because statisticians like it and contribute every obscure technique into it. Statisticians (for most part) don't seem to care about performance or elegance of the language from an engineering standpoint. R toolbox, for whatever reason, makes sense to them. For most people, R is used more as a statistical shell, rather than a programming language. Do I care whether BASH scripting is elegant or fast? No... just that everything is quickly available from it.

      Julia will no doubt be valuable for a subset of statistical techniques where performance matters. I think Julia will become a good extension language for vectorized code. It will perhaps be the next NumPy/Cython, a general-purpose high-level, high-performance language/libraries that everyone can plug into, not just the Python community.

      The one problem I had was that it still had a nasty startup time when I last evaluated it an year ago. Gadfly took way too long to import... something like a minute. Its not a problem for interactive use, but painful for scripts. It can be worked around of course. I hope the grant helps.

    11. Re:jesus thats all it takes? by TheRaven64 · · Score: 1

      Unfortunately it has not chance of dislodging R,

      The places I've seen Julia make the most inroads, it's been displacing Fortran, not R. And anything that displaces Fortran makes me happy.

      --
      I am TheRaven on Soylent News
  5. Performance by dlenmn · · Score: 1

    Take a look at the benchmarks on the Julia frontpage and reevaluate your statement.

    1. Re:Performance by umafuckit · · Score: 1

      IIRC, the MATLAB results have improved a lot since they last posted these. Also don't forget that these benchmarks emphasize lower-level tasks. People use MATLAB and R for the higher-level functions they provide. I've generally found MATLAB's built-in higher level functions to be pretty quick and convenient. R is a language for statistics and so is pretty specialised; it almost doesn't belong on that list. I'm surprised at Octave's bad showing.

    2. Re:Performance by Beck_Neard · · Score: 1

      I found that MATLAB's emphasis on vectorization forces you into a form of coding that is not always useful or productive. Sure, it's better to use a*b when multiplying matrices, but stuff like this? :

      cell2mat(arrayfun(@(K) accumarray(C, F(:,K), [], @mean), 1:size(F,2), 'Uniform', 0))

      come on. It pays to have a language where you can write out a clear explicit loop if you want to and not worry about performance.

      --
      A fool and his hard drive are soon parted.
    3. Re:Performance by Anonymous Coward · · Score: 0

      In Octave there are many things you would use a*b type constructions and then back-end this to optimised versions of BLAS or LAPACK or similar, so whilst the benchmarks are benchmarks of the code as written, a wider set of benchmarks of typical matrix manipulations would be useful too as a comparison with Julia. The same goes for Python using numpy, and so on.

    4. Re:Performance by fph+il+quozientatore · · Score: 2

      You'd be mostly benchmarking the quality of the underlying BLAS implementation. All these languages call the same blobs of Fortran and assembler code, and the performance of the glue part is insignificant once you have a matrix larger than 100x100.

      --
      My first program:

      Hell Segmentation fault

    5. Re:Performance by umafuckit · · Score: 1

      I never write MATLAB code that. If it looks like that then just write it as a loop. Over the last few years they've really sorted out the looping and you should see little speed difference between the arrayfun and loop approaches.

    6. Re:Performance by Beck_Neard · · Score: 1

      True, Matlab has included a just-in-time compiler, but the language has limitations and the compiler isn't as mature as Julia's (LLVM). Devectorized code often runs _faster_ in Julia, sometimes much faster. In Julia, vectorization is just a way of invoking BLAS functions when appropriate - as it should be.

      --
      A fool and his hard drive are soon parted.
    7. Re:Performance by umafuckit · · Score: 1

      Yes, MATLAB isn't the fastest language out there, but it's still no slouch. Its main advantage comes from the rich collection of functions in its toolboxes and this what Julia lacks. If you need more speed in MATLAB you have can write MEX functions in C or C++.

  6. Re:If we've tried, but can never understand Julia. by Anonymous Coward · · Score: 1

    Look... you can either play with Julia or your Python.

  7. All The Job Postings by Anonymous Coward · · Score: 0

    Are asking for 10 years of experience with Julia, right?

    1. Re:All The Job Postings by __aaclcg7560 · · Score: 1

      Pick up a Julia Child cookbook and you're get a job in no time.

  8. Re:Another day, another language. by alvinrod · · Score: 1

    Considering that you have now heard of it, apparently that $600k "advertisement" did indeed change that.

    It doesn't sound like something that most of us will use based on the problem domain and the other languages mentioned, I'm sure that there are some people who will find it highly useful and create some products that enhance all our lives.

  9. Yet Another Slow Language by Anonymous Coward · · Score: 0

    Yet another slow bloated language.

    You need speed? You need accuracy? Go with the power of Java.

    Never mind lack of IEEE-754 compliance.

    Java is the "good enough" language to handle all tasks.

    1. Re:Yet Another Slow Language by Beck_Neard · · Score: 2

      http://julialang.org/benchmark...

      If you think Java handles 'all tasks' then Julia isn't aimed at you. it's for scientific/numerical computing. Java is terrible at that, in terms of syntax, library support, and speed. Even python is far better than Java for that purpose.

      --
      A fool and his hard drive are soon parted.
    2. Re:Yet Another Slow Language by Anonymous Coward · · Score: 0

      You clearly never did any scientific computing.

      Also, if you'd bother look at benchmarks, you'd realize that Julia is FASTER than Java for most tasks.

      Julia is also a really elegant language. The resemblance to matlab is superficial.

  10. MATLAB and R style programs? by Anonymous Coward · · Score: 0

    MATLAB and R style programs?

    So what you're saying is Julia's a steaming sack of shit?

    1. Re:MATLAB and R style programs? by fph+il+quozientatore · · Score: 1

      Au contraire, to me it feels a lot like Matlab re-done from scratch, but getting it right this time. The language is as pleasant as Python to work with, and it has none of the Matlab syntax abominations and unexpected performance bottlenecks.

      --
      My first program:

      Hell Segmentation fault

  11. Eek the Ignorance! by transfire · · Score: 2, Informative

    It appears the ignorance level here on Slashdot has risen too an all time high. With the exception of one or two, none of the have any idea what they are talking about. People should be more careful about bashing things they know absolutely nothing about. Julia is a fairly kickass language and if you are a coder it should be on your radar -- up there with Go, Rust, Elixir, Clojure, etc. Having dabbled in most languages, I'd say it just might be the best of the lot, although I do dislike its module system.

    1. Re:Eek the Ignorance! by transfire · · Score: 1

      s/too/to/ s/the have/the comments have/ Damn it Slashdot, get an edit button.

    2. Re: Eek the Ignorance! by Anonymous Coward · · Score: 0

      Oh fuck you

    3. Re: Eek the Ignorance! by Anonymous Coward · · Score: 0

      You illiterate goon

    4. Re:Eek the Ignorance! by Anonymous Coward · · Score: 0

      you don't know how much it would be abused, would you?

      But I personally would prefer and EDIT button for AC posts. would love to see the edit wars.

  12. Re:Another day, another language. by __aaclcg7560 · · Score: 1

    I doubt anyone paid $600K to DICE to post Julia on Slashdot. There are cheaper ways to advertise.

  13. Do we need another language? by Anonymous Coward · · Score: 0

    We have a ton of languages out there. Why not narrow it down to just a few and focus on those? For security-minded work, Ada (since it can be proven to be secure mathematically.) For basic scripting, bash or powershell. For running across platforms, Java [1]. For Web stuff , HTML5 or JavaScript.

    We really don't need more languages, because they are more about the brags (knowing the latest language for Web pages to beat the H-1Bs to the trendy jobs) as opposed to actual work. At best, we might need C and C++ for low level work, a compiled language for cross-platform stuff, then a JIT interpreted language just because they are in vogue.

    If we -have- to have a language, we need a scripting language for secure programming, just to make it more idiot-resistant.

    [1]: Well, something Java-like that actually allows a JVM on one platform to run code written in another JVM without dying. Basically what Java promised, but was never delivered.

    1. Re:Do we need another language? by microbox · · Score: 2

      Julia is revolutionary, and I'm looking forward to it blowing away Matlab. All that's really holding it back is a good garbage collector, and mind-share. The language is truly superior, integrates seamlessly with C (like it is the same language -- there is no two-language problem), and soon C++. Could seriously replace C++ for /most/ things if it were multi-threaded. (There is some work on this, but Julia is designed to be multiprocess -- you can seamlessly shift objects between processes, even if they are on different machines. This is better then threads if you're doing scientific computing.) So Julia even has the potential to be better than D. And it runs as fast C (compiled by clang), and comes with the convenience of a REPL, and a truly beautifully designed.

      Julia looks a lot like Matlab, and some Matlab code just runs as is, or requires only minor tweaks. Mathworks has long dominated scientific computing with their awkward and expensive -- but otherwise so convenient -- product. Mathworks is screwed.

      Java/C#/python will never be what Julia is.

      --

      Like all pain, suffering is a signal that something isn't right
    2. Re:Do we need another language? by Mr.CRC · · Score: 1

      There is a lot more to Matlab's market than you may realize. Simulink is a big deal now. They played their cards well, and got entrenched. Something I wished Wolfram would have done better: strategize.

    3. Re:Do we need another language? by TheRaven64 · · Score: 1

      Your enumeration of requirements omits scientific computing, which is the niche where Fortran is currently dominant and Julia is growing.

      --
      I am TheRaven on Soylent News
  14. Re:JUILA IS TEH SUXX!!!111 by Anonymous Coward · · Score: 0

    why are there so many clueless people who love talking about stuff they have no idea about?

  15. A huge waste of money by Anonymous Coward · · Score: 0

    It should have been given to the Python Software Foundation or the PyPy project.

    1. Re:A huge waste of money by HiThere · · Score: 1

      Last I heard PyPy wasn't even attempting to get rid of the GIL.

      Mind you, I do like Python, but not for multiprocessing. It's better than some choices, but it's hardly good.

      (OTOH, when I really looked into Julia a few months ago [how many?] I decided that its way of doing multiprocessing wasn't useful for my purposes, but was instead optimized for array arithmetic.) This is great for most of their target audience, but doesn't fit my purposes which are more closely modeled by independent servers. I was looking for an approach that didn't have so much overhead, but was still passing messages into queues and not waiting for a response. The response, when it appeared, would be in the form of a message passed into the queue held by the originating thread/process/server. A TCP server is overkill, but finding anything simpler isn't straightforwards. (If it helps, the messages passed are immutable in actuality, whether or not conceptually.)

      Currently I'm torn between Ruby and Python for speed of development, and I'll probably convert the code to use 0MQ so I can switch out modules for C or C++ code to improve speed. But this is running all around Robin Hood's barn to accomplish something that should be straightforwards. But by using 0MQ I can keep the character handling part out of C/C++, as those languages are truly terrible at handling Unicode.

      --

      I think we've pushed this "anyone can grow up to be president" thing too far.
  16. Sounds like fortran by Anonymous Coward · · Score: 0

    Fast, efficient, designed with the sciences in mind? Sounds just like Fortran (later versions that is: design is probably too strong a word for F77 and co). Fortran also has the advantage of a large base of fast, well tested (and primarily science/maths) code to go along with it. Also many people are already fluent in it.

    But, still, good luck to them. Reinventing wheels is fun, particularly if you get paid to do it.

    1. Re:Sounds like fortran by Anonymous Coward · · Score: 0

      It's an interpreted language with REPL that is as fast as fortran. Read first, opinionate later :-)

    2. Re:Sounds like fortran by Anonymous Coward · · Score: 0

      Where's the fun in that :P

    3. Re:Sounds like fortran by Anonymous Coward · · Score: 0

      if you were doing scientific computing, you would not be asking..

      The reason for Julia is that it is a language for scientific computing, that is *not* python :-) and is much faster than the non-dynamic alternatives

    4. Re:Sounds like fortran by TheRaven64 · · Score: 1

      It's aimed at the same niche as Fortran, but comes with memory safety, a REPL environment and a JIT, and good interfacing with other languages (including Fortran) to reuse library code. Fortran is probably still a better choice if you're writing a library that lots of people will use.

      --
      I am TheRaven on Soylent News
  17. rofl by Anonymous Coward · · Score: 0

    python has already won the scientific race lol...

  18. Re:JUILA IS TEH SUXX!!!111 by Anonymous Coward · · Score: 0

    Who's got time to learn stuff when you spend all your time in social media?

  19. Julia, Elm, Elixir by tanstaaf1 · · Score: 1

    There are some really fascinating - and potentially revitalizing - new languages out there, and these are among the most interesting. Julia is comparable to R running like greased lightening. It deserves attention and $600K. It has C level speed, which is remarkable given its domain. Elm is comparable to Haskell but much more approachable -- especially for web development. Elixir is like Ruby..maybe Ruby goes on a date with Erlang and they fall in love. Kinda functional; kinda something wild. There are some other FASCINATING languages coming out, too. For instance, you might check out red ... keeping in mind how the unknown REBOL did in in the redmonks comparison of conciseness + other compelling strengths. What i would say is that we are in urgent need of better languages. The hardware, network, and critical deployment goes asymptotic while we mostly get is out-of-proportion bloat and bugs as our languages progress linearly, at best. We desperately need software upgrade in a real sense -- not the sense we generally keep getting with more of the shopworn procedural/object-oriented paradigm.

  20. Looks like ML by God+of+Lemmings · · Score: 1

    A good functional language that reminds me of the ML language. Looks like a decent replacement for fortran. Mandelbrot numbers appear suspect to me, as by definition, LuaJIT is written in C, and could not have magically performed better than C, unless their C implementation of mandelbrot was really crappy to begin with.

    --
    Non sequitur: Your facts are uncoordinated.
    1. Re:Looks like ML by Beck_Neard · · Score: 1

      Julia is more related to the lisp family of programming languages than ML. Some have said that Julia is just another lisp (albeit with a nifty dynamic type system supporting type families and polymorphism).

      --
      A fool and his hard drive are soon parted.
  21. Production version by manu0601 · · Score: 1

    Get the language into a production version

    I was not aware it was not production ready, and I now understand the fact is was not is a good explanation why it was such a pain to build. The thing embeds numerous third party libraries, and even the full distribution of LLVM.

  22. Julia needs arbitrary array indexing base by iliketrash · · Score: 4, Informative

    Any language that purports to be a good for technical computing needs to get away from a forced base for indexing arrays. No, this is not a 0 or 1 problem. Arrays should be numbered from whatever the programmer specifies. The Pascal-type languages including Ada have this feature and it prevents many many errors. Maybe the $600K can buy this, but somehow I doubt it as this fixed-index-base is usually in the mindsets of the language's designers.

    1. Re:Julia needs arbitrary array indexing base by Victor+Liu · · Score: 1

      I couldn't agree more, especially for a language that deals with math and linear algebra. When accessing submatrices of matrices and doing advanced linear algebra manipulations, using 0 based offsets leads to far more natural indexing, reduces the need to constantly subtract and re-add 1, and leads to fewer chances to make silly errors.

    2. Re:Julia needs arbitrary array indexing base by Mr.CRC · · Score: 2

      There have already been extensive discussions about this, and from what I've seen starting indexing at 1 is likely to stick in Julia. Feel free to search for this matter yourself.

  23. I guess it really is true.. by h8sg8s · · Score: 1

    I guess it really is true that you can write Fortran in any language.

    --
    Organization? You must be joking..
  24. almost there by Khashishi · · Score: 1

    As a physicist, I do a lot of numerical programming. I like julia, but it isn't quite useful to me yet. The problem is that it takes too long to run something the first time you run it in a session, and there's no way to save a compiled binary so I have to take the hit each time I run it. In particular, loading libraries takes too long. Maybe this boost will help it get there.

  25. Re:If we've tried, but can never understand Julia. by John.Banister · · Score: 1

    I believe I read above that with PyCall.jl you can put your Python inside of Julia.

  26. Fat chance... by RuffMasterD · · Score: 1

    I heard Julia does JSON.

    --
    Human Rights, Article 12: Freedom from Interference with Privacy, Family, Home and Correspondence
  27. Re:Another day, another language. by TheRaven64 · · Score: 1

    I suspect that most people doing scientific computation have heard of Julia. It's a pretty neat language (and has a lot shallower a learning curve than Fortran, which is the big player in the space. If you're not in a field that uses Fortran a lot, Julia probably isn't too relevant to you). I had a student last year work on hoisting bounds checking out of loops to expose better optimisation opportunities for autovectorisation. In combination with Polly, this got a factor of 4-8 speedup for a lot of workloads and also paves the way for things like GPU offloading for critical loops. There are definitely a lot of places where some of that $600K could be spent on small improvements that would give huge improvements to end users.

    --
    I am TheRaven on Soylent News
  28. What about s Python replacement? by jgfenix · · Score: 1

    When I read about Julia I thought that. HIgh level features, beautiful syntax, macros and metaprogramming and has better perfomance than Python and it is better at multiprocessing.

  29. Can't be worse than R by Anonymous Coward · · Score: 0

    Whatever Julia is, it can't be worse than R's syntax.

  30. Whoosh!!!!! by bigsexyjoe · · Score: 1

    Many people are talking about stuff they don't understand, but I thought my sarcasm was obvious enough.

  31. Looking forward to the next year! by waTeim · · Score: 1

    This may read like I'm a Julia fan-boy ... I guess I am.

    I found out about Julia from the Machine Learning course from Coursera. Not directly, for at that time it was Octave; the advice given there was "trust me, for machine learning, this syntax is better." Indeed for many machine learning algorithms, the basis of understanding it, is vector and matrix operations. The innovation of Matlab which both Octave, which is essentially a gnu, open-source implementation of Matlab, and Julia is making vector valued variables first class (e.g. M*X, M^-1 where M is a matrix and X is a vector) makes things succinct and clear -- btw M^-1 is a representation of the inverse of M, an O^3 order algorithm in 4 characters?

    Now yes, Python has numpy, which is close syntactically, but there are yet other comparisons were is not quite so easy, and Julia has an advantage here in that it's so new that devs are still tolerant of syntax changes -- for instance the behavior of {} was changed between Julia 0.3 and 0.4. And so if there's something new on the horizon that needs a re-org, Julia is better able to handle it.

    The other thing of course which Julia and Python and R communities are attempting to do is to figure out the best way to extract the optimizations available from LLVM, and owing to it's close ties to and ability to modify to conform to changes of LLVM, Julia also has an advantage. As I've posted before, expect Julia to be able to scale almost linearly on the Xenon Phi (Knight's Landing+) for HPC linear algebra oriented applications -- expect this by Julia 0.5.