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?

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.

[image] andyferris: 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. 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.

[image] andyferris: 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?” 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 :slight_smile:). 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. [image] andyferris: 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. 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. [image] andyferris: 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. Is there an issue with more details on this?

[image] ChrisRackauckas: 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. 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 :wink: ) 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.

[image] DNF: 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 :wink: ) 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.

[image] ChrisRackauckas: 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”. Changed the title @ChrisRackauckas, thanks.

I’d like to be able to get prints on remote workers.

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.

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.

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

List of most desired features for Julia v1.x

Community

juliohm June 28, 2017, 1:59pm 75

Changed the title @ChrisRackauckas, thanks.

Getting our act together in the data ecosystem

Topic		Replies	Views
What don't you like about Julia for "serious work"? Community	176	28023	April 20, 2024
Compiler work priorities Internals & Design	122	25911	August 6, 2021
I find it hard to develop in Julia Internals & Design	71	6611	February 13, 2026
Julia motivation: why weren't Numpy, Scipy, Numba, good enough? Community history	120	85862	September 21, 2018
Couldn't be good to postpone 1.0? Internals & Design	44	5693	December 23, 2017

List of most desired features for Julia v1.x

Related topics