List of most desired features for Julia v1.x

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

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

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.

Changed the title @ChrisRackauckas, thanks.

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

2 Likes
  1. 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.

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

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

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

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

  5. method_exists where I can specify the return-type.

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

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

  1. 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.
  2. 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.
  3. 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.
  4. 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

Suggested: https://github.com/JuliaGPU/GPUArrays.jl/issues/33

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.

  1. A great debugger
  2. Truly helpful error messages
  3. Executables for deployment
7 Likes

I am going to second @ChrisRackauckas - this thread is useless if it’s just a laundry list of things people want to see in packages and editors. We would all like the debugger to be brought up to date with .6, and it will be.

It would be better to focus here on what breaking changes to the language syntax and semantics need to be made before a stable 1.x cycle is finalized.

12 Likes

While i agree a lot that some clarification is needed what Julia 1.0 means, what is to be expected from the package ecosystem, what is on the agenda of the commercial Julia products, etc.

Still i don’t like to see discussions that were clearly started as ‘what should happen next’ (with 1.0 in the title) re-structured in something like ‘future topics’ without target dates.

I’m here as an interested hobbyist to expand my overview on programming environments. But that’s only half of the story. In my day-job i’m an expert on a certain type of simulation and we do these simulations in various tools in various programming environments. Matlab is dominating our work environment, because its usability (not speed, not language features, not re-usability - implement once, use in other places) is considered our main bonus in using it. Both in my private and professional life i’ll look at the next steps and future topics. I have stopped recently to recommend Julia as programming environment (internally and externally), mostly because of the non-progress on the debugger and some other usability problems (like installation problems).

My expectation of this discussion was: We should take the 1.0 label serious, and come up with a plan/list of solveable problems. Some of them in the language, some of them in the package ecosystem, some of them in infrastructure (and leave the unsolvable problems away).

To return on the reoccuring topic of a usable debugger: Maybe the approch to let Keno work alone part time on the debugger is not the most efficient one. I’ve never worked on a debugger itself but maybe there is something i can contribute. I just don’t see where to start, as the concept isn’t clearly defined, there seems to be some interaction of Keno also on the LLVM infrastructure, general documentation is missing, and how can we write tests for a debugger program? The debugger doesn’t seem to be a project inviting participation (imho).

I don’t claim that something is wrong here, i’d just prefer more focus on a 1.0 release which is meaningful.

4 Likes

I, too, think that framing the 1.0 release extremely narrowly as ‘the end of (most) breaking changes in the core language’ sounds limiting.

I would think that 1.0 is also a PR event. Launching it without regard to the maturity of tooling and the state of the ecosystem could invite some pretty harsh critisism. The launch of 1.0 is going to be the point when lots of people, bloggers and news sites take a new look at Julia and report the status. Missing debugger, insufficiently updated packages etc. at that point could be a PR disaster. Explanations of the meaning of ‘semantic versioning’ could easily fall on deaf ears.

But, frankly, I’m pretty sure some savvy people at JuliaComputing are already pondering these questions.

12 Likes

True, but consider the flipside: the wild success of a language that is still under heavy development and experiences breaking changes on a regular basis (yes, nicely managed and everything, but still breaking). Yet people don’t seem to care; they demand more breaking changes. Insane, eh? :sunglasses:

4 Likes

Sure, it’s beatiful :smile:

But that is pre-1.0. After 1.0 it’s the big leagues, contending with the giants, no more ‘still in beta’ figleaf.

For some, Julia is still just some Github open source project, but it’s becoming more; a professional organization with significant funding, people working globally to build communities and managing PR. I doubt that the launch of 1.0 will just be Tony Kelman tagging a new release, some fireworks emoticons in some issue and an new download in the Downloads page. It should be handled as a major PR event.

Hope they get it right! I find the prospect of a mature, slick version of Julia that I can seriously start converting people to very exciting!

4 Likes

I’m sure they thought long and hard before talking about the Julia roadmap at JuliaCon. It seemed like a clear and conscious decision. I wasn’t for it at first, but I have come around to think that it makes a lot of sense: how are we supposed to build that ecosystem people want if there’s still no guarantee of language stability? The debugger is precisely an issue BECAUSE of pre-1.0 instability, putting it all on one guy to constantly update a complex package every time Base Julia changes and then wondering why he doesn’t have the time to fix it with every little internal change. These kinds of things need 1.0 in order to work well, almost by definition.

1.0 will only be a PR disaster if we, the Julia community, talk about 1.0 as some holy grail that fixes everything. We were told what 1.0 means, and so we should start correcting our own use of the term. The release should just clearly say “this is a breaking change, which for now breaks the debugger and … and …, but it’s the last breaking change for awhile: now let’s go fix things”.

Though it would be interesting to have a v0.7 “stable update phase”, with a long (3-6 months?) “let’s get together and update the ecosystem and get rid of everything which isn’t working” time. Essentially: “Julia 1.0 is already complete. It is exactly v0.7 but without the depwarns. However, given the significance of this number, we are giving the ecosystem an extended time to catch up with the changes, and cleaning up the packages which do not”. That’s something I could get around.

But this is just my second-hand retelling + reinterpretation of what we learned from the Julia roadmap talk from JuliaCon. Maybe @StefanKarpinski has time to clear things up.

5 Likes