In this thread I’d like to share my list of most desired features for Julia v1.x:
With these features I should be near 100% happy with the language, what about you?
Both of those are small potatoes and don’t actually give new things. SimpleTraits.jl and Parameters.jl cover those quite well.
The only things I care for are things I can’t do myself in a package. There are a few rough edges that still need to be sanded down. These are:
And the things in the package ecosystem to make it really feel complete:
That’s probably a list of everything that, in the current state of Julia, come up enough that giving a workshop I would expect to have to mention that “it’s a current problem but should be fixed in the near future”. Honestly, none of this is breaking or devastating, or “definitely need to be in 1.0”, but I think Julia will still feel somewhat “new” to me until these kinds of things are completed.
When I look at this list, none of it is really “required” for v1.0. It’s really just optimizations and polish. Necessary polish, but nothing breaking. I think we’re pretty ready.
On my list is getting rid of the @printf and @sprintf macros . Even a temporary hack for 1.0 that does something like printf(x...) = @printf x... ( obviously not exactly this) would be desirable so that we have the names reserved (the implementation can be resolved during the 1.x cycle).
We will see lots of new features in terms of packages for sure.
Even though traits and default field values are apparently superfluous features, having them built-in in Julia would be great. Packages for those are only a temporary solution IMO, they aren’t perfect and very few people are looking into them.
I’m pretty partial to this suggestion: Enhanced Interpolations to Replace `@printf` · Issue #18703 · JuliaLang/julia · GitHub . 
Closure performance in my opinion is one of the key optimizations as it hugely influences the recommended programming style.
I have not been at julia con, but i would assume that Pkg3 is a must-have for 1.0.
Current package management does work quite well, but I would`t want to be stuck with millions of files on windows for the whole 1.0 cycle.
My wishlist :
Aside from what qualifies for v1.0 and what doesn’t, I think that these two are essential for scientists:
compiling Julia code to executables
Why would this be " essential for scientists"?
Fortran is the only scientist targetted language I can think of that has this as a core feature, in 1.0.
Fair enough, not essential, but very useful.
As you said, Matlab does it, and I’d say that many scientists both (sadly) use matlab and don’t care what it costs.
I find executables quite relevant in reproducible research…
Please let’s not settle on “others do not do it, let’s not do it” premise
I find executables quite relevant in reproducible research…
Surely, executable code is more useful though.
Particular working code, with good tests and CI.
Because if you are given an executable, how do you know it follows the description in the paper?
If you are given code, and an exectuable, then the only way to check is to compile the code,
and ensure it either bitwise matches, ore gives the same results.
In which case you might as well have just been given the code.
Please let’s not settle on “others do not do it, let’s not do it” premise
A fair point.
Being greedy is what got us this far, no?
(I’m still not convinced it is a blocking 1.0 feature though.)
My list has only three items:
I have a hard time coding or reading code without a debugger.
I don’t understand why. The executable is a binary black box. You will not be able to observe the actual algorithm, tweak it, do robustness checks, and extensions. In case it does not work because of a minor issue (eg an implicit assumption on the input data format which is not documented — I have seen this countless times) then you can’t figure out why it does not work.
I think that executables are probably the worst thing for reproducible research. They are useful for deployment of applications though, but I am not sure that is a priority.
Well, let me be greedy too:
That is mostly what is preventing me from starting using (by embedding) Julia in production code and really solve my “two languages problem”, as better explained here: Redirecting to Google Groups.
Depends on your/the OP’s definition of reproducible research. I know (at work) at least one group who treats the black box as reference, even including the input parameters, so you simply run and get the result (which is multi-megabytes of numbers). In my group we reference a certain commit and a matlab version to do the same.
quite ironic as some people have been given the advice to move away from Gadfly (the ‘slow’ plotting solution) to Plots (the ‘fast’ plotting solution). Looks like, the underlying problem - in pre- oder partial-pre compilation - is the same for complex data handling and transformation issues.
Is there something readable about how and where the time is spend in Plots.jl ?
As a full time Matlab user (at work) i’d consider Matlab’s plotting speed: OK, but not fast. Especially if you want to go into animation domain, you’ll recognize the deficiencies.