Julia is awesome, but..

178 pointsby mfschover 10 years ago

10 comments

Xcelerateover 10 years 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.

评论 #8811453 未加载

tenfingersover 10 years 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!

评论 #8809956 未加载

StefanKarpinskiover 10 years ago

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

评论 #8811851 未加载

idunningover 10 years 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 <a href="http://pkg.julialang.org/pulse.html" rel="nofollow">http://pkg.julialang.org/pulse.html</a>, 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<a href="https://github.com/JuliaStats/Distributions.jl" rel="nofollow">https://github.com/JuliaStats/Distributions.jl</a><a href="https://github.com/JuliaStats/StatsBase.jl" rel="nofollow">https://github.com/JuliaStats/StatsBase.jl</a><a href="https://github.com/pluskid/Mocha.jl" rel="nofollow">https://github.com/pluskid/Mocha.jl</a> (deep learning)<a href="https://github.com/stevengj/PyCall.jl" rel="nofollow">https://github.com/stevengj/PyCall.jl</a>The JuliaOpt stack of optimization packages (<a href="http://juliaopt.org" rel="nofollow">http://juliaopt.org</a>)and then you get fun new ones like <a href="https://github.com/anthonyclays/RomanNumerals.jl" rel="nofollow">https://github.com/anthonyclays/RomanNumerals.jl</a>

chollida1over 10 years 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 (<a href="http://cran.r-project.org/" rel="nofollow">http://cran.r-project.org/</a>) 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:(.

评论 #8810140 未加载

评论 #8810125 未加载

评论 #8810133 未加载

barrkelover 10 years 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.

KenoFischerover 10 years 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 <a href="http://pkg.julialang.org/pulse.html" rel="nofollow">http://pkg.julialang.org/pulse.html</a> 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 longTL;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.

评论 #8810327 未加载

评论 #8810964 未加载

评论 #8811677 未加载

bluecalmover 10 years 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.

评论 #8810554 未加载

评论 #8811652 未加载

评论 #8811436 未加载

zapharover 10 years 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.

maximsch2over 10 years 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.

评论 #8811055 未加载

评论 #8812475 未加载