List of most desired features for Julia v1.x

[ChrisRackauckas]

@oatlzzvztd

Compilation to executables. Not sure why so many people seem allergic to it.

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.

@lobingera

solving the ‘name is already exported’ problem

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.

@slowbrain

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.

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.

@lobingera

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 ?

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.

@antoine-levitt

• an error printing that differentiates between errors in my code and in Base, so I can quickly see where my bug is

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.

@lobingera

spend some effort on infrastructure services like WinRPM/BinDeps/Clang/Cxx/Cxxwrap

Yes. BinDeps2 was brought up as a Julia 1.x goal in Stefan’s talk.

@DNF

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.

Did the 265 fix not do this?

@ExpandingMan

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?

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

@lobingera

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?

@lobingera

Please show me a use-case for this.

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.