Comment by LittlePeter | Hacker News Reader

Comment by LittlePeter | Hacker News Reader

Every release I am downloading Julia and trying to wrestle through some tutorials. Every time (0.4.0, 0.6.0, 1.0.0) I get stuck at some error, usually during the pre-compiling of some dependency.

For example, I have downloaded julia-1.0.0. I try to follow this tutorial here, linked in this post by someone: http://juliadb.org/latest/manual/tutorial.html

Then I do this and get an error:

julia> using JuliaDB [ Info: Precompiling JuliaDB [a93385a2-3734-596a-9a66-3cfbb77141e6] ERROR: LoadError: UndefVarError: start not defined Stacktrace:

Every time. Even the screenshot of Julia code that julialang.org used to have was not runnable per admission of core devs.

What am I doing wrong? How are you able to run large Julia programs successfully?

Edit:

Let's try tutorial at https://www.analyticsvidhya.com/blog/2017/10/comprehensive-t.... First command: Pkg.add("IJulia"): command fails to install dependency Conda.

Same for the tutorial at http://ucidatascienceinitiative.github.io/IntroToJulia/Html/...

Sigh. Give up

> Every time (0.4.0, 0.6.0, 1.0.0) I get stuck

You should have tried 0.4.2, 0.6.3, 1.0.1. Motto: Don't start too fast and be slow giving up ;-)

Thanks for the tip :-)

Yes, if you want stability, you should never use a x.0 or x.0.0 release (even from a big company - how many people remember Windows 3.0? ) I, however, am a bit crazy, and enjoy living on the bleeding edge, and so am up late tonight hacking making sure all my packages are working correctly on v1.0.0 of Julia!

After every release the package ecosystem usually takes a few weeks to catch up. I'd recommend trying 0.6 until then.

Is it possible for the Julia team to make a short tutorial that does not depend on any external packages? Just show the new features in a fresh installation on a clean machine downloaded from https://julialang.org/downloads/ .

That would help a lot of people get started.

It was literally released today. Of course the packages don't work yet...

That makes sense. Maybe I was used to R (CRAN) where uploaded packages are actually tested against the version they declare to support.

JuliaDB declares support for 0.6 not 1.0 - http://juliadb.org/latest/

Which package declared support for 1.0.0 and didn’t compile?

A binary package will be available in CRAN for a given platform/version only if it works (it passes all the tests). It seems that Julia lets you install a non-working package without any warning (you will probably get errors when you run it, but I guess it may also fail silently which is worse).

I was excited to try using Julia 1.0.0 today after a couple years since my last try and... couldn’t.

None of the packages work with it yet. I guess I could go find an older version, but it seems like a problem that Julia will happily allow you to install a package it isn’t compatible with. What’s the point of the Pkg system then? CRAN’s model makes a lot more sense.

Many packages have declared them selves compatible with any future version of Julia... which is clearly a lie. These need upper bounds on their version compatibility, but that will take some time to propagate through the system.

This is indeed a very good idea. In Julia, the package author defines the range of supported Julia version. Most package actually just say "version 0.6 or later". The JuliaDB package was just been updated preventing the installation on Julia 0.7 or 1.0:

https://github.com/JuliaComputing/JuliaDB.jl/commit/8bf3057d...

A automatic check as in R would indeed a better choice.

That will only prevent installation of master of the package or the immediate next few versions on 0.7. The old package versions without a julia upper bound remain available so users on 0.7 or 1.0 will just be held back to old versions of JuliaDB until a new release without an upper bound gets made.

On each packages GitHub page, there should be unit test info, including badges that link to Travis and/or Appveyor, indicating where they were treated and whether they passed. If the tests haven't run in a while, they wouldn't have been tested on 1.0. Waiting a month may be a good bet.

That probably didn't happen at R 1.0.0. (Release notes: ftp://cran.r-project.org/pub/R/R-release-1.0.0.html).

More informative wikipedia page: https://en.wikipedia.org/wiki/R_(programming_language)#CRAN

That being said, R was GNU S once upon a time, so they didn't really build a new language, rather an open source clone of a popular proprietary tool. (In case it wasn't clear I both love R and am madly excited that Julia has finally hit 1.0.0).

CRAN has extremely strong requirements around testing, compatibility, documentation, all aggressively enforced by the maintainers of the repository.

The Julia package ecosystem is much more anarchic, like npm. You basically just have to have a public git repository with certain files in place, and a cursory review from the managers of the package metadata.

There are tradeoffs. I'm honestly not sure which one is the right way. I really appreciate how much I can trust that a CRAN package works, but there's a reason so many R devs are using devtools to do an end-run around it.

Is there anything wrong with recommending 0.7? Most things seem to work by now.

v0.7 is mostly for developers upgrading packages. It is nice because it throws warnings instead of errors for things that changed. So if it works on v0.7 without depwarns then it will be 1.0 compatible. But in many cases it's not perfect yet, so staying at v0.6 can be nicer than throwing a bunch of depwarns at new users.

I've never used Julia but why would a language make breaking changes on each release? It doesn't have backwards compatibility? That sounds like a nightmare to work with. Is it because it was pre-1.0?

Yes. v1.0 is literally the release so that all future 1.x releases are backwards compatible. That's why it's such a big deal.

Exactly, and that is why 1.0 is a big deal: the end of breaking changes until Julia 2.0.

Pre 1.0, we've generally provided backwards compatibility for one version with deprecations. Somewhat ironically that has often led to people just living with walls of warnings until the version that actually broke it came out, which led to a worse experience. We also have automated upgrade tools now, which can do many of the simple (and some not so simple ones) automatically. The situation on 1.0 is slightly worse than in previous releases because we released 0.7 and 1.0 simultaneously to avoid having to ship 1.0 with active deprecations. Of course that means that people will have to fix their packages now, rather than waiting until next year.

Reply on news.ycombinator.com