List of most desired features for Julia v1.x

gripes
suggestions

#1

In this thread I’d like to share my list of most desired features for Julia v1.x:

  • The ability to manipulate types in a parametric type as discussed here (see also #18466)
  • Interfaces or traits: #6975
  • Default field values: #10146

With these features I should be near 100% happy with the language, what about you?


Stand alone binary executable
How do you use debuggers?
Areas for new users to contribute to?
Ability to define function templates
How do you use debuggers?
How do you use debuggers?
#2

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:

  • True dispatch from keyword arguments: #16580
  • Stack-allocated views: #12205
  • Higher bar for or ability to “turn off” splat and recursion penalties:
    #22370
  • Compiler optimizations for small unions.
  • The closure performance bug #15276
  • Fix up the Julia builds in standard repositories so people stop accidentally downloading Julia v0.4 (mostly a teaching thing).

And the things in the package ecosystem to make it really feel complete:

  • GR’s new GUI
  • Slow first-time-to-plot on Plots.jl and Gadfly.jl (credit to @musm for mentioning it)
  • The current working branches of GPUArrays.jl to merge
  • Better testing of packages with binaries on Windows… pretty much all around
  • NLsolve.jl to do its “input swap” release
  • DataFrames/DataTables/DataUtils/IterableTables/IndexedTables/DataIKEA needs to work itself out (see compiler optimizations for small unions). I am honestly lost here.
  • The basic PDE tooling (FDM and Fenics wrappers) needs to be released
  • Fix some layout issues in Plots.jl

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.

Edit

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.


#3

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).


#4

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.


#5

I’m pretty partial to this suggestion: https://github.com/JuliaLang/julia/issues/18703 . :slight_smile:


#6

Closure performance in my opinion is one of the key optimizations as it hugely influences the recommended programming style.


#7

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.


#8

My wishlist :

  • faster global variables
  • a debugger
  • 3d plotting (interface to mayavi?)
  • a more mature package ecosystem
  • a stable paradigm for HPC (equivalent to standard MPI/OPENMP)
  • pkg3 so I don’t have to download the whole git history of packages
  • optimization to subarray indexing and operations so I don’t have to do have @. and @views so much
  • faster loading of packages
  • reload packages loaded with using
  • an error printing that differentiates between errors in my code and in Base, so I can quickly see where my bug is
  • faster comprehensions
  • reductions dropping dimensions

#9

Aside from what qualifies for v1.0 and what doesn’t, I think that these two are essential for scientists:

  • fast(er) plotting of 2d and 3d data (what is it anyways that makes Matlab’s plotting capabilities so fast?)
  • compiling Julia code to executables

#10

:100:


#11

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.


#13

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.


#14

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


#15

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.)


#16

My list has only three items:

  • Debugger
  • Graphical interactive debugger
  • Debugger

I have a hard time coding or reading code without a debugger.


#17

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.


#18

Well, let me be greedy too:

  • Enable embedding Julia into multiple unmanaged threads

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: https://groups.google.com/forum/#!topic/julia-users/A-7lKSuUtYw.


#19

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.


#20

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 ?


#21

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.