GLVisualize.jl has 2D and 3D plotting directly on the GPU, so is lightening fast (or at least as fast as copying data to the GPU).
I believe future versions will interact with GPUArrays.jl
4 Likes
I’m in favor of compiling Julia v1.0 code to executables. Executables and web-servers are useful for sharing methods with scientists who do not have programming skills.
6 Likes
a few random points:
- debugger
- Usability issues like proxy setting for git/libgit2
- correct line number report for syntax or similar issues
- consolidation of package environment
- spend some effort on infrastructure services like WinRPM/BinDeps/Clang/Cxx/Cxxwrap
- (i don’t know how to formulate this correctly) native datatype/syntax for AST.
- solving the ‘name is already exported’ problem
- multi module packages (?)
- patching packages externally (overwriting/patching Module.X = function newY(a::Int64) etc.
- more testing
2 Likes
Indeed I fully agree that for reproducible research to have the source code is the most important thing. I’ve never said otherwise. 
As mentioned before by @oxinabox there is always a need for source code and I second that.
Please let me explain what I meant under relevancy though.
My workflow is very simple and straight forward:
raw experimental data processing -> data to work with
Once all work is done on code I’m able to apply same “black box” (version controlled) on any data from my experiment.
That “black box” contains all possible outside packages dependencies at the time the source code was properly tested and finalized. This will assure that if there is some breaking update on any package it will not break the workflow.
Executable is a snapshot of the code that can be indeed further deployed and distributed to other colleagues that are not as skilled in compiling the code.
Definitely not a blocking 1.0 feature.
6 Likes
String concatenation with +.
21 Likes
- ahead of time static compilation. Meaning: not just building an executable (that can be done by embedding a julia interpreter in an exec) but having the compiler use the type information and getting the type errors at compile time instead of runtime.
- multithreading sorted out
- working debugger (not just prototypes)
- stable fast IDE
- having a true public/private visibility mechanism in packages that is enforeced by the compiler.
- hierarchical namespaces for packages. Having all packages in a long linear list on package sites gets unwieldy quite quickly. But also in the source code itself I’d like to have hierarchical organization of packages into groups and have the editor/IDE code completion work with that for showing suggestions. All modern general purpose programming languages have this (including Python of course). It just seems that older data science specific languages “sin” against this, e.g. R & matlab. I’d rather not have julia make the same mistake.
- some more curation in the package ecosystem. I know there is already some and that’s great but I also would like to see old abandoned packages removed from the “official” list and I 'd like see some metrics (either automatic or manually maintained) around popularity, quality, age, stability, …
10 Likes
Thought of one more: easier to reload (or possibly auto-reload) code when I modify it. I’m struggling quite a bit with this. ClobberingReload or the Junolab workflow are supposed to solve this, but I find them difficult to use or error-prone.
So I pretty much end up restarting Julia all the time.
12 Likes
Doing this comprehensively in julia can be reduced to the halting problem.
And is thus impossible.
It can also be trivially shown that the type of a variably is not nesc deterministicly known at compile time.
Eg x=ones(now > 2018 ? Int32, Float64)
Doing this partially, where it is possible is either, an optimisation, or part of linting.
Since it can’t be done with certainty you can’t base behavior or errors off of it.
(Julia, unlike static languages, does not require all types to be inferable)
But when the types are given by the programmer (for example in all function arguments) then I’d like to know about violations against the given types at compile time rather than runtime (if possible. Maybe it’s not possible due to multiple dispatch…).
Also languages like Scala (& I think Haskell) let the compiler issue an error when it cannot resolve the type via inference. This error basically says that the user should add a type annotation. That system works in practice.
2 Likes
@Steven_Sagaert: see this issue:
- Compilation to executables. Not sure why so many people seem allergic to it.
- An actual debugger.
- Better reloading, being able to develop from the REPL without constantly rebooting it (no other REPL requires this much restarting to get work done).
- A no-kidding replacement for PyPlot.jl that doesn’t crash half the time.
5 Likes
I wondered now for some time: Why didn’t Julia have return type definition from the beginning? What is the benefit of type-unstable code?
1 Like
Please show me a use-case for this.
1 Like
Lots of good points, +1 from me on most of what’s listed here.
One thing I would really like to see moved into Base is MacroTools.jl. It seems important to make everyone aware of it and to guarantee its maintenance, and it would be nice if most of the macro code sitting around in the ecosystem used it, because frankly macro code that doesn’t use it can sometimes be absolutely horrendous (and oddly “non-Julian”).
The only thing I miss about python is the debugging, so having a good debugger is something I very badly want. The debugger seems to have been completely abandoned, is that the case?
I’m not sure I understand why compiled binaries are so important to people.
I emphatically agree with @Tamas_Papp, if one can’t reproduce somebody’s results using their source code and data only one should be suspicious of the result. If in the course of my research a collaborator told me that I had to use a particular compiled binary it would make me very uncomfortable and I would not be willing to conduct research that way. I would even go as far as to say that I would only trust a result if I could make changes to the source code and see that the result depends on those changes in a reasonable way.
The only use I can think of for compiled binaries (other than obfuscation) is for guaranteeing no “run-time compilation”, possibly incorporating more extensive compile-time optimizations. While this seems absolutely necessary for, for example, video games, it some how seems less imperative for scientific and numerical purposes. That said, I think we all agree it’s a feature we’d like to have eventually.
8 Likes
- debugging
- copy-on-write slicing
4 Likes
Can you quote a single person who is against it? I can’t. It’s just understandably not high on most people’s priority list, since it doesn’t actually effect language usage and most people aren’t compiling code from dynamic languages. Sure, it will be more useful from Julia than other languages, but the ability to use an interactive language non-interactively just doesn’t affect most people.
Jeff mentioned something about automatically binding functions which would fix this. I am not sure if this would actually be breaking though (?), so it might be fine for a minor release instead of 1.0.
Docker? Not sure why people are suggesting that executables are the answer to this when we have much more modern tools for handling scientific reproduciblility issues than “smash it all into a binary that humans can’t read”. @ExpandingMan sums it up pretty nicely.
Plots.jl doesn’t precompile and it lazy loads backends, so it’s not the same at all. These became big issues with some of the changes due to v0.6. There are fixes in the works, like https://github.com/JuliaPlots/Plots.jl/pull/916.
Differentiation between Base and user code was brought up in conversations at JuliaCon and is an interesting topic. Julia is written in Julia, so it uniquely has this problem. A mode to make the debugger ignore Base would be helpful in many cases.
Yes. BinDeps2 was brought up as a Julia 1.x goal in Stefan’s talk.
Did the 265 fix not do this?
@Keno knows about the debugger issues. I think lately he was pretty busy making Julia enter the list of languages which have achieved petascale (what else has? C, C++, Fortran, and Assembler? @dpsanders made a good point that it’s probably a short list).
Again? Why type instability? - #8 by ChrisRackauckas
Notice that @oxinabox’s example is very close to how factorize works, except branching off of the matrix type. It’s a feature, though the ability to turn on additional checks would be nice.
1 Like
Every time anyone brings it up, the response is “it shouldn’t be necessary” or “there’s no use case for it”, despite people in the community asking for it about twice a month. That’s what I mean by “allergic”, which doesn’t necessarily mean “against it”.
After all, I quite enjoy ice cream, but the day after not so much.
6 Likes
Let’s stop the discussion around executables and move on to other more interesting features?
It is a well known fact that:
- Research should be open source
- Executables are good for commercial products
To all of you that stayed on-topic, a big thanks! Really good list of features, I am bookmarking all of them.
The whole data stack deserves attention. 
I am delaying my use of DataFrames as much as I can because everything is constantly changing. From JuliaCon 2017, I saw at least 3 presentations on DataFrames, Queries, Databases, etc. We need a comprehensive framework for manipulating/storing/plotting data in Julia.
12 Likes
The debugger isn’t abandoned - it’s maintained by Keno, who has been busy on Celeste.jl recently. It’s going to be updated for 0.6.
I don’t know for certain, but it seems likely that the new financing Julia Computing obtained will partially be used to support the debugger as well.
3 Likes