Good points, I totally agree with that.
In addition, maybe update the docs with some indication to check the master branch first, if this workflow has become a best practice. Even better, define guidelines and automate via PkgDev.
I have generated one here, I need to upload it though: https://juliohm.github.io/science/DAG-of-Julia-packages/
It is not live either, ideally one could have a service checking METADATA, but that is too much I think.
Of course, you could just use GitHub - JuliaString/StringLiterals.jl: Implement improved string literals with Swift-style syntax for interpolation, hex, & unicode characters, plus C & Python style formatting and Unicode, HTML, LaTeX, and Emoji entities 
JuliaObserver? 
Do they also have a DAG of packages? Never seen it.
No, I was just pointing out the ideal serve to host it.
One important (that has influence on several others) would be:
Remove slow startup of Julia scripts because of initial compilation of functions
by e.g. caching precompilation to binary code on first use: Even with precompilation, the first call of a function is often slow. Keeping a REPL open to avoid recompilation cost is often not possible/desirable, and many people first testing out Julia get a bad impression now. You see many simple “benchmarks”
“showing” Julia to be very slow, only because of startup cost.
It would probably (partially) solve several of the other issues mentioned
- slow Plots, … startup
- compilation to exe: I was wanting this/looking into this mostly for startup speed reasons. For reproducability and distribution it could be complemented with a way to create an isolated Julia binary package with the packages needed in the correct versions: This should be easier than making static executables.
Even when using precompiled,
I haven’t seen many breaking core changes on this list. Which is great!
Keep in mind that this dev cycle is the last chance for serious breakage before 1.0. Don’t forget that many of the awesome suggestions here can (and probably will) appear in 1.1, 1.2, etc. When I read the title of this thread, I’m asking myself “what do I want to break?”
Picking my favourites from the above, the dataframes ecosystem would be nice to settle and I think the introduction of a named tuple type (definitely in 1.0) will be a huge step forward here since fighting type stability won’t be an issue any more and we can all agree that a row is a named tuple.
Regarding “static” code and static compilation, I have oftened wondered if there could be an annotation or style that avoids dynamic dispatch, so you could package a executable with no Julia interpretter or compiler (and that provably will work without one). The idea would be to go beyond our current “researchy” communities and develop apps/games/etc.
The wildly breaking change I would consider is modifying slightly the semantics of mutable structs so that they become refs of immutable structs (and have syntax to make using them as easy as now to use). I think making the reference structure more transparent would be a great boon.
The final slightly breaking change I look forward to is a slimmer Base with things like FFTW and maybe BLAS optional. The goal here for me is to dramatically reduce RAM of each Julia instance.
Lastly, the thing that will make Julia better for production environments is Pkg3 and BinDeps2.
11 Likes
Some people talked during JuliaCon with me about this. In theory you could use the infrastructure built for GPU codegen to emit completly static code with minimal or no runtime interactions. Besides GPUs the main use case could be embedded systems.
7 Likes
Yes, I think that word needs to start spreading on what v1.0 is. v1.0 somehow got this idea of being some complete version of Julia that is the final form, and everything should be extra. Stefan was pretty clear at JuliaCon that v1.0 is just following semantic versioning: v1.0 is the version where the big breaking changes have no ended, it’s a sign of stability, but it’s not necessarily “the perfect Julia” (which he jokingly but seriously stated as Julia 10 ).
To manage people’s expectations, we should make sure this meaning of v1.0 spreads. v1.0 is when code stops breaking, but that doesn’t mean the debugger is magically complete, every feature and compiler optimization is added, and we every package is up-to-snuff. v1.0 is a signal of language stability, not a signal of feature completeness.
Since this thread is almost surely going to show up in Google searches, I would suggest changing the title to be “List of most desired features for Julia v1.x”. As you noted and as I noted earlier, almost everything here has nothing to do with breaking changes and is feature additions, which is not v1.0 blocking material.
Oh god, how did I miss this one? Yes, this is definitely a breaking change I’d like to see completed. Add “move libm to a package, and let the user choose a libm”. There are many great Julia-only LibMs that are hard to “seamlessly use”, and it would probably spur more development if you could swap the default.
Is there an issue with more details on this?
8 Likes
I get your point, but desires for version 1.0 is also partly about what people want soon. Being told that the debugger will come in ‘version 1.x’ is perhaps satisfying from a theoretical point of view, but for some (like me) we want the debugger “yesterday” (actually, I would like it last week, but I am trying to be reasonable 
)
Some features are so indispensable and so sorely missed, that signalling: we want this for 1.0 feels urgent, even though it’s not a breaking change, and could theoretically come in 1.3.
1 Like
I get the sentiment, but I think that if we don’t start correcting our own use of what Julia 1.0 means, Julia outsiders may get the wrong impression which could be a bad situation. We should make it clear that 1.0 means language stability so that way things like the debugger can stabilize in 1.x. That’s actually a really good example: the debugger is currently broken because of breaking language changes between v0.5 and v0.6, a clear sign for why expecting the debugger concurrent with 1.0 may be the wrong way to think about things.
If people get the wrong impression and think Julia’s 1.0 release is some form of magic that is supposed to fix all problems, people will be disappointed. Instead, Julia 1.0 is the magical release that is supposed to be stable, which then makes it much easier to build, support, and maintain the features people are asking for here.
I’d like to be able to get prints on remote workers.
2 Likes
- I want an interface / abstract type with declared, but not defined functions / traits with declared, but not defined functions
Many people say that this is not needed, but as a writer of libraries I disagree. Currently I have to write a simulator where users can input their own modules and if the modules do not adhere to my imposed structure the whole thing will fall on its head with terrible, confusing and generally useless error messages. This pain for the user also gets amplified when they fix one part of their module, just to be bitten again by the next error.
All of this could be made much more simple by saying to the user: Look here in this file at that line is the interface. Implement what is coherently displayed there.
You will be directed to this interface by the error message directly. No need for me to add documentation or some fancy error message.
Instead of: Okay now I am at this line in some library which inner workings I never wanted to see and confuse me. What input do they want here? What output do they want?
Technically an interface is not needed. Practically it would reduce the pain of usage tremendously.
Also I do not want them to be some third-party package like SimpleTraits. This just leads to everyone doing their own stuff, because people will disagree and it will make people dependent on the author of that library. 1.0 rolls around and SimpleTraits does not get updated… well guess we can not update was well. This feature is way to integral for my liking to be outsourced.
-
Better error messages and line numbers. The second you use macros all line numbers run wild. A week ago I had an error in line 240 or so. The file was 100 lines long, but had some macros in it.
On another occasion I had a function call with 6 arguments. It crashed on that line with “Undefined reference Error” or something like that, but it did not tell me which of the 6 arguments was the undefined one. Great. println for those 6 the line before to see which one is undefined. Which brings me to -
A debugger (ideally like visual studio has). Again I do not want to rely on third party packages. Gallium was not working for a long time and I do not put the fault here to gallium, it was the best we had. This again is too essential for my taste to be outsourced.
-
A better documentation. Really the current documentation is awful. Often you don’t even know what the types of the input are or what the type of the output is. It is also missing examples and how it works with other dependent function calls.
-
Anything regarding packages is super slow. For a while I did Pkg.update(“name”) for my simulator, but this seriously took over a minute to complete. Now I just go into my package-dir directly and say git pull. That works instantly, but feels very wrong.
-
method_exists where I can specify the return-type.
-
Startup time of julia is slow. (I do not work with atom because atom is slow as well and generally much slower than just starting julia fresh every time)
-
Too much magic for my taste in macros. Combined with lacking documentation it is really hard to grasp the cost of using the inbuild macros without extensive testing and really understanding what the implications are of using them.
I have some more issues that are more fundamental, but I do not think that the devs ever would want to change that.
edit: Don’t know why my second to last point are intended and start at 1 again. In the text I wrote it is not intended and goes on with 2. Guess this is just what I mean by the magic in my last point.
9 Likes
Here is my wish list that will make Julia even more awesome than it currently is.
- I would like to be able to view all functions in a module with an argument of a certain type, something like the methods of a class but in Julia logic.
- Also a full support of sparse matrices where normal matrices are used would be appreciated, with special emphasis on linear algebra, multivariate calculus and optimization algorithms.
- A simple GPU for loop would be nice to have, something like ArrayFire’s gfor loop. That will enable quick inline GPU computations for embarrassingly parallel parts of an algorithm. These parts can be specially annoying to domain experts who can see clear GPU acceleration potential in their specialized algorithm but don’t speak GPU language.
- A simple way to share functions and their variable and function dependencies with multiple procs and the GPU after having been defined. This is also related to the previous point.
I think that should be it for now.
1 Like
For 1. try
methodswith(typ[, module or function][, showparents::Bool=false])
e.g.
julia> methodswith(String, OhMyREPL)
4-element Array{Method,1}:
colorscheme!(name::String) in OhMyREPL at C:\Users\Christian\.julia\v0.6\OhMyREPL\src\OhMyREPL.jl:29
test_colorscheme(cs::OhMyREPL.Passes.SyntaxHighlighter.ColorScheme, str::String) in OhMyREPL at C:\Users\Christian\.julia\v0.6\OhMyREPL\src\OhMyREPL.jl:64
test_colorscheme(name::String, str::String) in OhMyREPL at C:\Users\Christian\.julia\v0.6\OhMyREPL\src\OhMyREPL.jl:51
test_colorscheme(name::String) in OhMyREPL at C:\Users\Christian\.julia\v0.6\OhMyREPL\src\OhMyREPL.jl:51
2 Likes
If you just wrap your array in a GPUArray, then broadcasting and map operations will “just work” like this. You should suggest that GPUArrays.jl adds a macro to make this loop form since it would be nice. GPUArrays.jl is definitely a core library now.
6 Likes
1 Like
I would really love to get to use one of Julia coolest features, loop fusion, from inside of another one of Julia’s coolest features, @generated functions. It sounds like its within the realm of possibility https://github.com/JuliaLang/julia/issues/21094#issuecomment-287649747 and I have a really cool application that’s just waiting for it.