- A great debugger
- Truly helpful error messages
- 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? 
4 Likes
Sure, it’s beatiful 
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
I personally promise not to complain about rough edges in 1.0. I just don’t think it matters how the people on this board or on github talk about 1.0. At launch Julia will be subjected to a serious inspection by the wider internet community of non-converts, potentially with very little patience and only marginal good will. Or perhaps it will be ignored, is that any better?
I have confidence in the Julia people, though. They have surely given much more thought to this than I have.
Edit: I want to add that managing the expectations of the community wrt 1.0 may be quite useful, and that I have myself adjusted mine after reading this thread. (But I will definitely be adding the debugger to my evening prayers to the Flying Spaghetti Monster.)
6 Likes
This, very much. No matter how much will be said that 1.0 just means stability of the core, it will not be judged that way (as more than one community has already experienced). At the launch of 1.0 many people will take a first (or second) look at Julia, and should get the best possible experience; If important parts of the ecosystem are still broken, perceived speed is bad, …this will go down badly. Might be better to go for the no breaking changes in 0.7 (or 0.8), then have some time for the ecosystem to stabilize as well before calling 1.0 …
10 Likes
Great Thread!
My wishlist:
-
Using Spyder as an IDE
Julia needs MATLAB’s style IDE and instead of starting from scratch I’d like to see collaboration with the Spyder IDE Project (They are adding ability to support any language, so this is the time for joint efforts).
Key point here is to have the same Debugging experience as in MATLAB. -
Portable Package of Julia
Make a truly portable version of Julia Pro (Maybe collaboration with PortableApps). Namely all configuration files should be in the Julia folder (No traces in the User Folder / App Folder) and no registry entries. -
Out of the Box Intel MKL Integration
I know Julia can not be distributed with Intel MKL. But maybe an option to tell Julia that I have MKL / IPP installed and give it the path to it and let it use it. Just a simple configuration which doesn’t require recompiling Julia or anything like that. -
Julia Application Compiler
Being able to create a self contained package of Julia Code which can run on any computer. The main reason for that (Similar to the EXE request above) is for UI. Create a shareable UI / Application. It has no contradiction with Open Source . Open Science it will just create ability to create real world applications based on Julia.
Thank You.
4 Likes
I’ve seen this request before. Is there any special advantage to Spyder other than its array viewer (which should be relatively easy to implement in another IDE)? I’ve encountered some people who are extremely loyal to Spyder, but I still haven’t been able to find any terribly compelling reasons to use it.
1 Like
The ability to broadcast indexing operations in a convenient fashion, as dicussed in Issue 19169.
Commercial/Research: One feeds off the other, and in my opinion, without strong commercial interest, it’ll be always be an uphill battle to get funding. So for example, compilation to a small executable that can run my newest NN on an android…
Data: Although there has been some significant improvements, data (DataFrames, DataTables, …) remains a minefield.
3 Likes
I second this, more specifically: statically compiled executable capability.
This will provide a major boost to Julia’s use case. I would love to see this happen before 1.0. This will also have a benefit of not having a first-call overhead.
6 Likes
I’d alsp like to see static compilation to standalone compiler free binaries.
5 Likes
I’ll second the notion that the community can do a lot about many of the issues here, without it being required for Julia 1.0. As evidence, Revise.jl may address various posts here about “slow startup” and “wish I didn’t have to restart Julia so much.” All this did was capitalize on some work that Jameson did in base Julia for 0.6; I suspect the frequent posts about static compilation might be largely addressable by reading his blog posts and start working on packages that fill in the remaining details.
18 Likes
After looking at this:
- please include logging into Base
Shorter time-to-first-plot is not a good reason for migrating from Gadfly to Plots. The best advice is for people to use the plotting package that lets them express the plots they need in a way that’s intuitive for them. If there is one reason to recommend Plots it’s the idea of recipes – allowing package maintainers to define plotting functions for custom types without depending on a plotting package (and potentially introducing plot conflicts for downstream packages that prefer a different plotting solution).
3 Likes
7 Likes