Julia v1.0 has been released

[1] https://github.com/JuliaLang/julia/commit/5d4eaca0c9fa3d555c...

I confess, not being the default is a big thing. I've definitely had times where I thought "this would be easier with 0 indexed arrays", but it can then be harder to commit to adding a dependency and making that change vs just adding awkward looking "+1"s to all the indexes. Coming from math/science, there's lots of times 1-indexing makes more sense / is more familiar. It's normal there to start counting from 1, so it can be easier to translate.

Clearly we're talking decades, but I am already realizing pay-offs from the switch to Julia (from Python) in my domain.

Rackauckas pointed out an amazing example recently [1]:

https://discourse.julialang.org/t/differentialequations-jl-a...

You have a library that implements calculating with numbers with uncertainties. You have the differential equations library. They don't know about each other but you can use the former in the latter to solve differential equations with uncertainties with a whole bunch of advanced solving algorithms.

This sort of power, having an ecosystem like Python that combines in a performant way, will be huge.

[1] http://www.stochasticlifestyle.com/why-numba-and-cython-are-...

First, Jupyter Notebooks don't facilitate working with revision control very well. Each time a notebook is saved, a new mess of JSON is belched out. I think the path to collaboration via revision control should be as easy as possible for analysts. This model of notebook is pretty hostile to making the jump to collaboration.

By contrast, RStudio's "R Notebooks" (supports more than R) are human readable, and git revisionable, with no loss of functionality as compared to Jupyter Notebooks. This is the same model that Emacs's org-mode uses for a document with embedded, executable code snippets.

Second, while Jupyter Notebooks can be an easy path for someone with no computer experience to get started, it's very hard to scale the environment up to writing larger analytic projects. The notebook model that Jupyter provides doesn't allow you to escape the notebook without ditching the tools pretty much completely and learning something entirely new.

By contrast, RStudio makes moving between notebook computing and more traditional IDE support for R scripts very easy. A thing I have done that is easy in RStudio (or Emacs org-mode):

- start building a plain R script with just comments

- convert to an R Notebook where I essentially add rich documentation

- once things start to get unwieldy, I start to factor out code from my notebook into more reusable project modules. I then let a notebook report be the "tip of the iceberg" where I still have the write-up of my analysis and embedded supporting evidence like plots and tabular summaries.

At this last evolution, my notebook is really just a UI for the outputs of my reusable analysis code. If I want to take things further I can:

- Move away from a notebook / document presentation of my results toward an interactive application via Shiny.

I just don't see any way that Jupyter Notebooks are any easier than RStudio's tooling. I also see that RStudio's tooling facilitates moving up and down through different more or less technical interaction models. Jupyter Notebooks by contrast are a brittle environment that pretty much dictates you stay within their walls or learn something else entirely.

But, I do find Racket to be a nicer language than R or Python. I like to imagine that Racket's best-of-breed support for building DSLs could yield a more expressive data / stats environment.

People always talk about the unassailability of Python and R in data science. But I think that's sort of defeatist. Not very many years ago people would have laughed at you if you suggested doing statistics with Python rather than R. Even though Python is still a long ways behind R in statistical libraries, people have built enough that Python too is viable for many things.

So too could Racket (or Julia!) become more useful than they already are.