9 ms·

Julia is awesome, but..

178 points by mfsch 12y ago

deleted 12y ago
[deleted]
tenfingers 12y ago
Most of the remarks are deserved. The exception hierarchy is not consistent currently, but the language is still evolving a lot, including on a syntax level (julia 0.4 deprecates the short dict/array syntax, just to name one). To be honest, I hope they continue to break stuff. There are still many areas where it feels that the syntax/language itself could be improved a lot (too many to list!). Some of the changes have a significant impact on the entire system (like multiple inheritance for abstract types). Most of the proposed discussion/changes I've seen improve the language in several ways, they make it more uniform, so I'm really looking forward to them! The base lib is very minimal, and the quality of the contributed packages varies wildly. It's a new language... you might lament most of the same issues with Rust. Being a long time lisper, for me Julia it's a lisp in disguise with an edge on performance. The compromises/choices done so far have a great sense of direction and balance. It's a good time to jump into the development before the language is set in stone and the warts cannot be changed anymore!
- sanxiyn 12y ago
  I would like to defend Rust here. For example, the article complains "The build is often broken or has failing tests". Rust build is basically never broken nor has any failing tests. Being a new language really is no execuse. This is not rocket science. You can do it too. Go read http://graydon2.dreamwidth.org/1597.html http://graydon2.dreamwidth.org/1597.html written by Rust's original author.
  - tenfingers 12y ago
    I personally never had a failing build, and I'm following the master branch. I cannot relate to the author for that specific point. Julia seems to be reasonably unit-tested to me for being such a young project. The testing framework is very simple, but does the job. I would say that also the complaint that @test is just an assert is mostly moot: it's actually the only thing you need the vast majority of the time. Other frameworks are maturing. But if you consider the entire ecosystem (see http://pkg.julialang.org http://pkg.julialang.org), many packages that you might rely on, especially for simple operations, might break. Most of the breaking changes are developed in branches and merged when completed. Again, overall the source management is also following the best practices in this sense. I didn't really want to get into too much detail because for me most of the arguments made are ok, but it's an ongoing development effort. When new ideas are proposed, I want them to be considered, not dismissed as "breaking changes".
  - mijoharas 12y ago
    On another point, the rust documentation is absolutely amazing for a young language (and improving! [0]). [0] http://words.steveklabnik.com/rusts-documentation-is-about-to-drastically-improve http://words.steveklabnik.com/rusts-documentation-is-about-t...
    - steveklabnik 12y ago
      Thanks for the kind words. Still so much to do!
    - masklinn 12y ago
      One thing I definitely miss, especially with things being split into separate extension traits (e.g. iterators a few weeks ago) is a Hoogle-like type-based search. Because finding out how to perform operations, especially very generic ones, has become fairly frustrating. Also the ability to easily search both the standard library and third-party libraries is probably going to be needed soon if nothing experimental is going to be available in the "standard track".
      - steveklabnik 12y ago
        https://github.com/rust-lang/rust/issues/12866 https://github.com/rust-lang/rust/issues/12866
  - bazookajoes 12y ago
    Maybe I'm off base, but in this day and age I can not imagine writing a new compiler and runtime without at least 100% branch coverage and automated fuzz testing and actually asking people to use it. It is a gut wrenching feeling when code crashes in production and it is my compiler to blame. It seems so much more shameful to me then if a library or service of mine crashed, not that that isn't shameful as well. Do I need to loosen up?
    - lmm 12y ago
      You need to be loose enough that you'll actually write and release a compiler, imperfect as it is. Shame can be a powerful motivator but it can also be paralyzing. As I've used more modern languages with better type systems I've moved away from high test coverage and towards writing code that simply can't go wrong (or at least, that is exceedingly limited in the ways it can go wrong); http://spin.atomicobject.com/2014/12/09/typed-language-tdd-part1/ http://spin.atomicobject.com/2014/12/09/typed-language-tdd-p... is a well-written explanation of something very close to my current approach. So I wouldn't put the emphasis on branch coverage or fuzz testing that you do. But I absolutely agree that you should have a very high level of confidence in a compiler before you ask people to use it, substantially higher than the level of confidence required of a library or service.
barrkel 12y ago
I buy the problem with cultural issues around testing and possibly poor quality of the current implementation. I do think the OP doesn't get exceptions, though. Catching and doing something with an exception should be very rare, and almost never happen in library code, unless you've been infected by Java-itis and feel compelled to wrap implentation exceptions at the API level. Failures are a function of implementation. The stack trace includes the fact that the API was involved. Further wrapping is usually busywork. If action needs to be taken on failure, the code that must not fail should have an exception handler, which can deal with the failure if possible (necessarily failure modes it can enumerate), and retry or abort as required. Wrapping is particularly pointless with more functional code. When code is idiomatically passed around, library exceptions are frequently from user code passed in, rather than something the library author could exhaustively list.
deleted 12y ago
[deleted]
chollida1 12y ago
I agree with alot of the authors criticism's. Julia's sweet spot seems to be anyone who needs to do statistical work who also has an existing C ABI based environment. The ability to seamlessly plug in Julia to your production system via C code is a boon for those of us who have to use R in an "offline" capacity and then feed data to production systems. The downside of alot of the Julia posts is that its not R. R, for better and worse, has many years of bug fixing and library design behind it. I have yet to stump cran (http://cran.r-project.org/ http://cran.r-project.org/) when looking for a library and after 5+ years of using R I still am amazed that I can learn some new ability that ggplot can do. My advice to people who ask what language to use is always, I think Julia is still a bit too early on to use unless you already know what code you want to write and are using a C based enviroment. The reason is that most programmers just want to get one task done. They aren't an expert on the mathematical domain they are trying to use, they just want to plug their values into a library and get their results and maybe print them in a nice format. With Julia I still run into issues too often where you have to second guess the langugage or library and if you aren't fully sure that your math is right you tend to assume you are wrong:) Otherwise use R. It just works and it will make googling for answers much easier. EDIT replaced jvm with C ABI. Not sure how I made that big of a typo:(.
- peatmoss 12y ago
  I'm not sure you're talking about Julia here. Or maybe it has some way of interfacing with the JVM that I'm not familiar with? I've thought Julia's interop story had more to do with being able to interface with C code easily via LLVM. For the JVM, Clojure and Incanter seem like a better statistical bet. I heard they're moving toward a 2.0 release of Incanter too...
- synparb 12y ago
  Could you point to a link about how to seamlessly plug Julia into the jvm? I haven't seen any documentation or examples.
  - KenoFischer 12y ago
    Even though there parent misspoke here, there's https://github.com/aviks/JavaCall.jl https://github.com/aviks/JavaCall.jl for interfacing with the JVM, though of course that's more the reverse.
KenoFischer 12y ago
This is very fair criticism. Julia has yet to make the full transition from research project to production language. Having seen Julia evolve over the past 2+ years, I feel like stability and test coverage have improved a lot and I expect them to improve further. I fully agree on the need for more testing. We've been trying to make sure that new functionality and all issues reported come with tests where possible and I actually think we've been making progress on that front (and especially compared to two years ago), but we need to do a lot more of this. For a significant number of the core contributors (myself included), Julia is probably the first big project we're working on and we're still learning proper release engineering and making software for a large number of users. That said, I think we've been pretty good about keeping master functional recently and I don't remember the last time I pulled from master and had something break (I think the travis status analysis is misleading here, because it probably includes development branches as well as instances where the CI system itself is failing - either because travis is down, or because the servers for dependencies are down etc). I also don't think that we've ever left master broken for days at a time when there was an easy fix available (of course bugs that come up and you don't know how to fix can always happen). On that topic though, I think we have room for improvement. I've been thinking about moving to a pre-commit CI system (you push to a branch and the CI system merges once everything's green), especially now that we have CI coverage for all 3 supported platforms. I'll bring that up on the mailing list. So much for the Julia core. Packages are a different issue and I agree that we have a problem with package quality. That are a few very high quality packages (I'm thinking e.g. Color and Distributions) and a long tail of packages of varying quality. Iain has been doing great work on this front with http://pkg.julialang.org/pulse.html http://pkg.julialang.org/pulse.html and making sure that packages keep up with changes in julia and at least pass their own test suite, but there's obviously a lot of work to be done there. The good thing is though that since these packages are completely decoupled from Julia core, this can be easily parallelized. One of the advantages of Julia is that the core is pretty small (admittedly bigger now than it should be and we need to split some stuff out) and it's in general pretty easy to look at the code which hopefully makes it easy hack on packages. Making high quality packages requires a lot of time and work and since Julia is such a young language, the ecosystem is still immature. If you have thoughts on what we can do to improve package quality or make things easier on package developers, please let us know, we'd love to hear them. Finally, I also would like to ask to please, please file bug reports for things that don't work the way you expect them to or for any bugs you encounter. One of the things mentioned in the OP was the REPL rewrite (which I worked on). The original REPL was a messy readline based hack, which really needed to be replaced. Admittedly, readline has a lot of features and I originally only implemented the ones that were part of my workflow, but I fully expected people to file issues for any features they were missing (and they did) and I and others quickly implemented lots of features (including quite a number not present in the original rewrite). Of the REPL issues currently open, I can see only one that may have worked with the original REPL (emacs keybindings). In any case, if you're missing features in the REPL please file an issue. I'll end with my general disclaimer that while Julia has a lot to offer, it is not yet a polished system and I don't yet recommend using it if that's the experience you want. Sorry for making this so long TL;DR I agree, Base needs more testing, but I think we've been making progress on that. Another big issue is package quality, which I'm not sure how to fix. If you encounter bugs please file issues.
zaphar 12y ago
Personally I hope the the julia testing package that gets adopted most widely is QuickCheck.jl. That form of testing deserves wider adoption than it gets.
Xcelerate 12y ago
I really like Julia despite the criticisms. I think the problem is that it's still a young project that needs more core developers to help maintain it. I find bugs and unintuitive behavior a lot when using Julia. Often it requires me searching the mailing list or Stack Overflow to figure out "idiomatic" Julia code when this really should be in the documentation (who knew that a matrix operation A += B allocates new memory for A each time?) And I think global variables should just be removed altogether, as many problems as they cause. I commonly find myself thinking "There's no way that someone new to Julia would know you're supposed to do it this way", whereas with Python or even C, that's not the case. But I think the language has a lot of promise, and the language design is really slick and well put together: powerful macros, a nice type system, multiple dispatch, clean code when you don't need performance but lots of additional decorations you can add when you do (devectorization, @parallel, @inbounds, @simd, type annotations). Remember that Julia is only at dev version 0.4. The author of the article complains about breaking backwards compatibility on an almost daily basis by removing or changing things. At this early stage, I see absolutely nothing wrong with this. I'm tired of languages that have unintuitive and quirky (stupid) ways of doing things just in order to not break existing code. C++, for instance, is abhorrent to me. How many pages is the standard?? At the moment, Julia has a steep learning curve if you want high-performance code. But once you know what you're doing, it's easy to get it running at the level of C. Plus, features like viewing the AST, or the LLVM and native assembly representation of the code are handy for debugging.
- bazookajoes 12y ago
  > And I think global variables should just be removed altogether, as many problems as they cause. Hi, I'm curious what your thinking is? Is it because global variables make testing hard? Is it because global variables are can not be optimized well? Is it because of bugs in julia related to global variables? I would like to use a language that doesn't have static variables, global variables, or static functions to make writing tests easier, but that makes it really hard to interface with C and the JVM. I often need functions like write() and System.out.print.
  - Xcelerate 12y ago
bluecalm 12y ago
It's personal preference and very minor thing but I don't really like end keyword to end a block. Those don't save space over braces (well at least not over K&R style braces) and are less readable than them (eyes naturally focus on words so the code with a lot of ends is more difficult to read). Why not just indentation or if that's too troublesome standard {} braces ? Discussion about such things is usually quickly dismissed here but I wonder how other people react to syntax things like that.
- CyberDildonics 12y ago
  It's quickly dismissed probably because that, along with 1 indexing (instead of 0 offsetting) are such minor negative decisions compared to all the extremely apt decisions made in the design of Julia. Those two are both controversial with minor pros and cons, but larger scale core design issues like multiple dispatch, integrated multidimensional arrays, a packaging system based off of github, the ability to immediately generate llvm or native code etc. far outweigh the cosmetic issues people might not be as comfortable with.
  - bluecalm 12y ago
    I agree but I also believe that cosmetic issues help with adoption and sparking enthusiasm for a language. It's silly but a lot of people are like that (I am as well). Beautiful cars, apartments, smartphones... in all of them core design is way more important but people still go for looks at least to some extent.
    - CyberDildonics 12y ago
      I think that those two features in particular are more polarizing than anything. I don't think there is a wide consensus as to which is better even though most programmers have an opinion. Many programmers would agree (I think) that Julia is cosmetically beautiful in a lot of other ways however.
    - pygy_ 12y ago
      These features were precisely chosen to drive the adoption of the language among R and especially MATLAB programmers.
maximsch2 12y ago
This is probably mostly a UI/IDE question (although lack of object method call notation doesn't help), but what's stopping me now from using Julia is discoverability of functions. I'm just too used to typing obj.<tab> and going through a list of functions in something like IPython. In Julia, it seems like you have to dig through docs to find functions that you need.
- 3JPLW 12y ago
  Check out `methodswith(typeof(obj))` and `methodswith(typeof(obj), true)` (which shows the parent type methods, too).
  - maximsch2 12y ago
    Thanks for the pointer! There is a big difference between having an easy tab completion vs running `methodswith` every time you want to call a method. But the fact that it's possible to do right now makes me hopeful, that it should be a built-in function of REPL and IJulia some time in the future.
- rcoder 12y ago
  While I appreciate the convenience of this, I think you may be misunderstanding how Julia does method dispatch. Rather than dispatching purely on the type of their first argument (as in Python) or into a class hierarchy/namespace based on that argument, then by parameter types (ala Java) Julia methods are fully qualified over every parameter type. Sadly, that makes it hard to ask the question "what methods can I call on an object of this type?" because the answer might include functions with that type in any parameter position. In many cases that wouldn't be a meaningful answer - as in the case of, say, a numeric type which could be used for all kinds of indexing, iteration, and offset methods involving collections, IO handles, etc. You might benefit a bit more from using the 'apropos' builtin to lookup functions based on simple keyword matching. Given a type name it lists methods that take or emit objects of that type (which may or may not be exactly what you want, but it's a starting point at least).
StefanKarpinski 12y ago
The julia-users thread discussing this post may be of interest: https://groups.google.com/forum/#!topic/julia-users/GyH8nhExY9I https://groups.google.com/forum/#!topic/julia-users/GyH8nhEx... My response (which is too long to include here) is this: https://groups.google.com/d/msg/julia-users/GyH8nhExY9I/0BznqtD5VJgJ https://groups.google.com/d/msg/julia-users/GyH8nhExY9I/0Bzn...
- bachmeier 12y ago
  This is kind of a good reason to not touch Julia (from the second link): > You cannot compare Julia with a project that has Google in the background. Its clear that they have a "more clear" development model and more documentation. Some goes for Rust. Julia is from and for researchers.
  - StefanKarpinski 12y ago
    It's true that Julia doesn't have big corporate backing, but it is certainly not only a research language. Julia is being actively used in a growing number of industry applications, not just in academia (finance, aerospace, etc.).
    - hayd 12y ago
      I think it's fair to say that the quote does not reflect general Julia feeling. > Julia is from and for researchers. I think the actual criteria is being ["a greedy, unreasonable, demanding programmer"](http://julialang.org/blog/2012/02/why-we-created-julia/ http://julialang.org/blog/2012/02/why-we-created-julia/) i.e. everyone.
      - rspeer 12y ago
        You can say Julia is for everyone, but it's not informative. You could just as well (and just as uninformatively) say that Erlang is for everyone, or Rust is for everyone, or Haskell is for everyone. Each programming language has strengths and weaknesses that are the reason you use the language. Julia's strength so far is fast numerical algorithms, and that's what most people seem to use it for.
idunning 12y ago
I feel like people are perhaps a bit overly negative about the state of Julia's packages. Compared to other early-stage languages, I'd say our package ecosystem is vibrant and full of fantastic packages. Naturally perhaps they are more math/scientific focussed, so if you are looking for cutting-edge packages for web dev you won't find them yet (although there are packages!). See http://pkg.julialang.org/pulse.html http://pkg.julialang.org/pulse.html, for example. We have over 470 packages in total that are registered, and on Julia 0.3 we have over 300 packages with tests that pass - and we run the tests in all registered packages every night. Some of my favorite packages (that I didn't make, of course :D) would include https://github.com/JuliaStats/Distributions.jl https://github.com/JuliaStats/Distributions.jl https://github.com/JuliaStats/StatsBase.jl https://github.com/JuliaStats/StatsBase.jl https://github.com/pluskid/Mocha.jl https://github.com/pluskid/Mocha.jl (deep learning) https://github.com/stevengj/PyCall.jl https://github.com/stevengj/PyCall.jl The JuliaOpt stack of optimization packages (http://juliaopt.org http://juliaopt.org) and then you get fun new ones like https://github.com/anthonyclays/RomanNumerals.jl https://github.com/anthonyclays/RomanNumerals.jl

178 points by mfsch 12y ago

deleted 12y ago

[deleted]

Most of the remarks are deserved. The exception hierarchy is not consistent currently, but the language is still evolving a lot, including on a syntax level (julia 0.4 deprecates the short dict/array syntax, just to name one). To be honest, I hope they continue to break stuff. There are still many areas where it feels that the syntax/language itself could be improved a lot (too many to list!). Some of the changes have a significant impact on the entire system (like multiple inheritance for abstract types). Most of the proposed discussion/changes I've seen improve the language in several ways, they make it more uniform, so I'm really looking forward to them! The base lib is very minimal, and the quality of the contributed packages varies wildly. It's a new language... you might lament most of the same issues with Rust. Being a long time lisper, for me Julia it's a lisp in disguise with an edge on performance. The compromises/choices done so far have a great sense of direction and balance. It's a good time to jump into the development before the language is set in stone and the warts cannot be changed anymore!

sanxiyn 12y ago
I would like to defend Rust here. For example, the article complains "The build is often broken or has failing tests". Rust build is basically never broken nor has any failing tests. Being a new language really is no execuse. This is not rocket science. You can do it too. Go read http://graydon2.dreamwidth.org/1597.html http://graydon2.dreamwidth.org/1597.html written by Rust's original author.
- tenfingers 12y ago
  I personally never had a failing build, and I'm following the master branch. I cannot relate to the author for that specific point. Julia seems to be reasonably unit-tested to me for being such a young project. The testing framework is very simple, but does the job. I would say that also the complaint that @test is just an assert is mostly moot: it's actually the only thing you need the vast majority of the time. Other frameworks are maturing. But if you consider the entire ecosystem (see http://pkg.julialang.org http://pkg.julialang.org), many packages that you might rely on, especially for simple operations, might break. Most of the breaking changes are developed in branches and merged when completed. Again, overall the source management is also following the best practices in this sense. I didn't really want to get into too much detail because for me most of the arguments made are ok, but it's an ongoing development effort. When new ideas are proposed, I want them to be considered, not dismissed as "breaking changes".
- mijoharas 12y ago
  On another point, the rust documentation is absolutely amazing for a young language (and improving! [0]). [0] http://words.steveklabnik.com/rusts-documentation-is-about-to-drastically-improve http://words.steveklabnik.com/rusts-documentation-is-about-t...
  - steveklabnik 12y ago
    Thanks for the kind words. Still so much to do!
  - masklinn 12y ago
    One thing I definitely miss, especially with things being split into separate extension traits (e.g. iterators a few weeks ago) is a Hoogle-like type-based search. Because finding out how to perform operations, especially very generic ones, has become fairly frustrating. Also the ability to easily search both the standard library and third-party libraries is probably going to be needed soon if nothing experimental is going to be available in the "standard track".
    - steveklabnik 12y ago
      https://github.com/rust-lang/rust/issues/12866 https://github.com/rust-lang/rust/issues/12866
- bazookajoes 12y ago
  Maybe I'm off base, but in this day and age I can not imagine writing a new compiler and runtime without at least 100% branch coverage and automated fuzz testing and actually asking people to use it. It is a gut wrenching feeling when code crashes in production and it is my compiler to blame. It seems so much more shameful to me then if a library or service of mine crashed, not that that isn't shameful as well. Do I need to loosen up?
  - lmm 12y ago
    You need to be loose enough that you'll actually write and release a compiler, imperfect as it is. Shame can be a powerful motivator but it can also be paralyzing. As I've used more modern languages with better type systems I've moved away from high test coverage and towards writing code that simply can't go wrong (or at least, that is exceedingly limited in the ways it can go wrong); http://spin.atomicobject.com/2014/12/09/typed-language-tdd-part1/ http://spin.atomicobject.com/2014/12/09/typed-language-tdd-p... is a well-written explanation of something very close to my current approach. So I wouldn't put the emphasis on branch coverage or fuzz testing that you do. But I absolutely agree that you should have a very high level of confidence in a compiler before you ask people to use it, substantially higher than the level of confidence required of a library or service.

barrkel 12y ago

I buy the problem with cultural issues around testing and possibly poor quality of the current implementation. I do think the OP doesn't get exceptions, though. Catching and doing something with an exception should be very rare, and almost never happen in library code, unless you've been infected by Java-itis and feel compelled to wrap implentation exceptions at the API level. Failures are a function of implementation. The stack trace includes the fact that the API was involved. Further wrapping is usually busywork. If action needs to be taken on failure, the code that must not fail should have an exception handler, which can deal with the failure if possible (necessarily failure modes it can enumerate), and retry or abort as required. Wrapping is particularly pointless with more functional code. When code is idiomatically passed around, library exceptions are frequently from user code passed in, rather than something the library author could exhaustively list.

deleted 12y ago

[deleted]

chollida1 12y ago

I agree with alot of the authors criticism's. Julia's sweet spot seems to be anyone who needs to do statistical work who also has an existing C ABI based environment. The ability to seamlessly plug in Julia to your production system via C code is a boon for those of us who have to use R in an "offline" capacity and then feed data to production systems. The downside of alot of the Julia posts is that its not R. R, for better and worse, has many years of bug fixing and library design behind it. I have yet to stump cran (http://cran.r-project.org/ http://cran.r-project.org/) when looking for a library and after 5+ years of using R I still am amazed that I can learn some new ability that ggplot can do. My advice to people who ask what language to use is always, I think Julia is still a bit too early on to use unless you already know what code you want to write and are using a C based enviroment. The reason is that most programmers just want to get one task done. They aren't an expert on the mathematical domain they are trying to use, they just want to plug their values into a library and get their results and maybe print them in a nice format. With Julia I still run into issues too often where you have to second guess the langugage or library and if you aren't fully sure that your math is right you tend to assume you are wrong:) Otherwise use R. It just works and it will make googling for answers much easier. EDIT replaced jvm with C ABI. Not sure how I made that big of a typo:(.

peatmoss 12y ago
I'm not sure you're talking about Julia here. Or maybe it has some way of interfacing with the JVM that I'm not familiar with? I've thought Julia's interop story had more to do with being able to interface with C code easily via LLVM. For the JVM, Clojure and Incanter seem like a better statistical bet. I heard they're moving toward a 2.0 release of Incanter too...
synparb 12y ago
Could you point to a link about how to seamlessly plug Julia into the jvm? I haven't seen any documentation or examples.
- KenoFischer 12y ago
  Even though there parent misspoke here, there's https://github.com/aviks/JavaCall.jl https://github.com/aviks/JavaCall.jl for interfacing with the JVM, though of course that's more the reverse.

KenoFischer 12y ago

This is very fair criticism. Julia has yet to make the full transition from research project to production language. Having seen Julia evolve over the past 2+ years, I feel like stability and test coverage have improved a lot and I expect them to improve further. I fully agree on the need for more testing. We've been trying to make sure that new functionality and all issues reported come with tests where possible and I actually think we've been making progress on that front (and especially compared to two years ago), but we need to do a lot more of this. For a significant number of the core contributors (myself included), Julia is probably the first big project we're working on and we're still learning proper release engineering and making software for a large number of users. That said, I think we've been pretty good about keeping master functional recently and I don't remember the last time I pulled from master and had something break (I think the travis status analysis is misleading here, because it probably includes development branches as well as instances where the CI system itself is failing - either because travis is down, or because the servers for dependencies are down etc). I also don't think that we've ever left master broken for days at a time when there was an easy fix available (of course bugs that come up and you don't know how to fix can always happen). On that topic though, I think we have room for improvement. I've been thinking about moving to a pre-commit CI system (you push to a branch and the CI system merges once everything's green), especially now that we have CI coverage for all 3 supported platforms. I'll bring that up on the mailing list. So much for the Julia core. Packages are a different issue and I agree that we have a problem with package quality. That are a few very high quality packages (I'm thinking e.g. Color and Distributions) and a long tail of packages of varying quality. Iain has been doing great work on this front with http://pkg.julialang.org/pulse.html http://pkg.julialang.org/pulse.html and making sure that packages keep up with changes in julia and at least pass their own test suite, but there's obviously a lot of work to be done there. The good thing is though that since these packages are completely decoupled from Julia core, this can be easily parallelized. One of the advantages of Julia is that the core is pretty small (admittedly bigger now than it should be and we need to split some stuff out) and it's in general pretty easy to look at the code which hopefully makes it easy hack on packages. Making high quality packages requires a lot of time and work and since Julia is such a young language, the ecosystem is still immature. If you have thoughts on what we can do to improve package quality or make things easier on package developers, please let us know, we'd love to hear them. Finally, I also would like to ask to please, please file bug reports for things that don't work the way you expect them to or for any bugs you encounter. One of the things mentioned in the OP was the REPL rewrite (which I worked on). The original REPL was a messy readline based hack, which really needed to be replaced. Admittedly, readline has a lot of features and I originally only implemented the ones that were part of my workflow, but I fully expected people to file issues for any features they were missing (and they did) and I and others quickly implemented lots of features (including quite a number not present in the original rewrite). Of the REPL issues currently open, I can see only one that may have worked with the original REPL (emacs keybindings). In any case, if you're missing features in the REPL please file an issue. I'll end with my general disclaimer that while Julia has a lot to offer, it is not yet a polished system and I don't yet recommend using it if that's the experience you want. Sorry for making this so long TL;DR I agree, Base needs more testing, but I think we've been making progress on that. Another big issue is package quality, which I'm not sure how to fix. If you encounter bugs please file issues.

zaphar 12y ago

Personally I hope the the julia testing package that gets adopted most widely is QuickCheck.jl. That form of testing deserves wider adoption than it gets.

Xcelerate 12y ago

I really like Julia despite the criticisms. I think the problem is that it's still a young project that needs more core developers to help maintain it. I find bugs and unintuitive behavior a lot when using Julia. Often it requires me searching the mailing list or Stack Overflow to figure out "idiomatic" Julia code when this really should be in the documentation (who knew that a matrix operation A += B allocates new memory for A each time?) And I think global variables should just be removed altogether, as many problems as they cause. I commonly find myself thinking "There's no way that someone new to Julia would know you're supposed to do it this way", whereas with Python or even C, that's not the case. But I think the language has a lot of promise, and the language design is really slick and well put together: powerful macros, a nice type system, multiple dispatch, clean code when you don't need performance but lots of additional decorations you can add when you do (devectorization, @parallel, @inbounds, @simd, type annotations). Remember that Julia is only at dev version 0.4. The author of the article complains about breaking backwards compatibility on an almost daily basis by removing or changing things. At this early stage, I see absolutely nothing wrong with this. I'm tired of languages that have unintuitive and quirky (stupid) ways of doing things just in order to not break existing code. C++, for instance, is abhorrent to me. How many pages is the standard?? At the moment, Julia has a steep learning curve if you want high-performance code. But once you know what you're doing, it's easy to get it running at the level of C. Plus, features like viewing the AST, or the LLVM and native assembly representation of the code are handy for debugging.

bazookajoes 12y ago
> And I think global variables should just be removed altogether, as many problems as they cause. Hi, I'm curious what your thinking is? Is it because global variables make testing hard? Is it because global variables are can not be optimized well? Is it because of bugs in julia related to global variables? I would like to use a language that doesn't have static variables, global variables, or static functions to make writing tests easier, but that makes it really hard to interface with C and the JVM. I often need functions like write() and System.out.print.
- Xcelerate 12y ago

bluecalm 12y ago

It's personal preference and very minor thing but I don't really like end keyword to end a block. Those don't save space over braces (well at least not over K&R style braces) and are less readable than them (eyes naturally focus on words so the code with a lot of ends is more difficult to read). Why not just indentation or if that's too troublesome standard {} braces ? Discussion about such things is usually quickly dismissed here but I wonder how other people react to syntax things like that.

CyberDildonics 12y ago
It's quickly dismissed probably because that, along with 1 indexing (instead of 0 offsetting) are such minor negative decisions compared to all the extremely apt decisions made in the design of Julia. Those two are both controversial with minor pros and cons, but larger scale core design issues like multiple dispatch, integrated multidimensional arrays, a packaging system based off of github, the ability to immediately generate llvm or native code etc. far outweigh the cosmetic issues people might not be as comfortable with.
- bluecalm 12y ago
  I agree but I also believe that cosmetic issues help with adoption and sparking enthusiasm for a language. It's silly but a lot of people are like that (I am as well). Beautiful cars, apartments, smartphones... in all of them core design is way more important but people still go for looks at least to some extent.
  - CyberDildonics 12y ago
    I think that those two features in particular are more polarizing than anything. I don't think there is a wide consensus as to which is better even though most programmers have an opinion. Many programmers would agree (I think) that Julia is cosmetically beautiful in a lot of other ways however.
  - pygy_ 12y ago
    These features were precisely chosen to drive the adoption of the language among R and especially MATLAB programmers.

maximsch2 12y ago

This is probably mostly a UI/IDE question (although lack of object method call notation doesn't help), but what's stopping me now from using Julia is discoverability of functions. I'm just too used to typing obj.<tab> and going through a list of functions in something like IPython. In Julia, it seems like you have to dig through docs to find functions that you need.

3JPLW 12y ago
Check out `methodswith(typeof(obj))` and `methodswith(typeof(obj), true)` (which shows the parent type methods, too).
- maximsch2 12y ago
  Thanks for the pointer! There is a big difference between having an easy tab completion vs running `methodswith` every time you want to call a method. But the fact that it's possible to do right now makes me hopeful, that it should be a built-in function of REPL and IJulia some time in the future.
rcoder 12y ago
While I appreciate the convenience of this, I think you may be misunderstanding how Julia does method dispatch. Rather than dispatching purely on the type of their first argument (as in Python) or into a class hierarchy/namespace based on that argument, then by parameter types (ala Java) Julia methods are fully qualified over every parameter type. Sadly, that makes it hard to ask the question "what methods can I call on an object of this type?" because the answer might include functions with that type in any parameter position. In many cases that wouldn't be a meaningful answer - as in the case of, say, a numeric type which could be used for all kinds of indexing, iteration, and offset methods involving collections, IO handles, etc. You might benefit a bit more from using the 'apropos' builtin to lookup functions based on simple keyword matching. Given a type name it lists methods that take or emit objects of that type (which may or may not be exactly what you want, but it's a starting point at least).

StefanKarpinski 12y ago

The julia-users thread discussing this post may be of interest: https://groups.google.com/forum/#!topic/julia-users/GyH8nhExY9I https://groups.google.com/forum/#!topic/julia-users/GyH8nhEx... My response (which is too long to include here) is this: https://groups.google.com/d/msg/julia-users/GyH8nhExY9I/0BznqtD5VJgJ https://groups.google.com/d/msg/julia-users/GyH8nhExY9I/0Bzn...

bachmeier 12y ago
This is kind of a good reason to not touch Julia (from the second link): > You cannot compare Julia with a project that has Google in the background. Its clear that they have a "more clear" development model and more documentation. Some goes for Rust. Julia is from and for researchers.
- StefanKarpinski 12y ago
  It's true that Julia doesn't have big corporate backing, but it is certainly not only a research language. Julia is being actively used in a growing number of industry applications, not just in academia (finance, aerospace, etc.).
  - hayd 12y ago
    I think it's fair to say that the quote does not reflect general Julia feeling. > Julia is from and for researchers. I think the actual criteria is being ["a greedy, unreasonable, demanding programmer"](http://julialang.org/blog/2012/02/why-we-created-julia/ http://julialang.org/blog/2012/02/why-we-created-julia/) i.e. everyone.
    - rspeer 12y ago
      You can say Julia is for everyone, but it's not informative. You could just as well (and just as uninformatively) say that Erlang is for everyone, or Rust is for everyone, or Haskell is for everyone. Each programming language has strengths and weaknesses that are the reason you use the language. Julia's strength so far is fast numerical algorithms, and that's what most people seem to use it for.

idunning 12y ago

I feel like people are perhaps a bit overly negative about the state of Julia's packages. Compared to other early-stage languages, I'd say our package ecosystem is vibrant and full of fantastic packages. Naturally perhaps they are more math/scientific focussed, so if you are looking for cutting-edge packages for web dev you won't find them yet (although there are packages!). See http://pkg.julialang.org/pulse.html http://pkg.julialang.org/pulse.html, for example. We have over 470 packages in total that are registered, and on Julia 0.3 we have over 300 packages with tests that pass - and we run the tests in all registered packages every night. Some of my favorite packages (that I didn't make, of course :D) would include https://github.com/JuliaStats/Distributions.jl https://github.com/JuliaStats/Distributions.jl https://github.com/JuliaStats/StatsBase.jl https://github.com/JuliaStats/StatsBase.jl https://github.com/pluskid/Mocha.jl https://github.com/pluskid/Mocha.jl (deep learning) https://github.com/stevengj/PyCall.jl https://github.com/stevengj/PyCall.jl The JuliaOpt stack of optimization packages (http://juliaopt.org http://juliaopt.org) and then you get fun new ones like https://github.com/anthonyclays/RomanNumerals.jl https://github.com/anthonyclays/RomanNumerals.jl