
Retro on the Julia Programming Language - philip1209
https://blog.staffjoy.com/retro-on-the-julia-programming-language-7655121ea341
======
acidflask
The issues about the lack of tooling and stability are well heeded.
Unfortunately, we at the Julia Lab at MIT, like our colleagues that are the
JuMP group at the MIT ORC, are limited to working on things that can be
justified as research activities. Developing new algorithms and applying them
to scientific computing activities is research; writing a debugger and testing
framework is not. For non-research development we have had to rely on the
goodwill from hundreds of open source community developers, which have helped
improve Julia and its package offerings immeasurably.

Happily, the present situation is more rosy than it has ever been. Funding
agencies are beginning to realize that academic software development is an
activity worth funding in its own right, not necessarily tied to research.
Julia Computing has also been fortunate to receive funding from organizations
such as the Moore Foundation to work on precisely the tools that users most
need, but are difficult to justify development with research funds.

~~~
philip1209
Thanks you too for your contributions. From an enterprise perspective, we used
a pre-release language with the expectations of a stable production language,
so we knew to expect these instabilities.

------
KenoFischer
I'm glad julia was useful for you guys. Of course huge kudos goes to Miles,
Iain and Joey (and the rest of the JuliaOpt folks) for building JuMP. I'm
sorry you guys didn't end up being able to use it in production, but I can
guarantee you that we (both as the open source community and as Julia
Computing) are feverishly working on improving the language and tooling to get
ready for a stable release. Thanks for being an early adopter!

~~~
philip1209
Thanks for your contributions, Keno! We saw major improvements in the language
and its libraries as we were using it. Unfortunately, the effort required to
update our codebase for new Julia versions while developing new code proved to
be too much. I'm looking forward to a 1.0 release!

------
Xcelerate
I use Julia extensively for scientific research. It's such a great language
though that I wish I could use it for more than that. I find that writing
Python code irks me after programming in Julia for a day.

I almost feel like there should be two versions of Julia: a commercial version
that focuses on stability and is usable in production systems, and a
scientific version that undergoes constant revision/feature overhaul to
produce the best programming language for numerical computing.

~~~
sgt101
I've been messing about with Julia for a couple of years, I did a few tech
talks about it at work and wrote a few side projects in it.

At work most people agreed with the technical insights - it's just a super
language, but everyone thought that it was impossible to use it in any real
project and very quickly discarded it even as a hobby tool. The clue is / was
in the versioning - 0.3; 0.4 now 0.5. Things are broken and major things will
change.

I think that this is really good, and important. Getting Julia _right_ may
really matter in the future. Code that costs less to write, runs faster and is
easier to maintain is an underpinning capability for our economy and for
science. Julia could be a huge enabler.

Having said that I find myself having a meltdown over 0.5 (specifically I had
a tantrum yesterday when everything broke). I wanted to do some stuff on a
private laptop so set up an env under windows. I jumped versions from 0.3.9 to
0.5.3478 because - why not? I'd also been using a 0.4 dev version sometimes,
it worked ok but there was one issue that made me normally run 0.3.9 which was
fine. However, Atom couldn't cope because HttpServer is @unix_only (whatever
the that means, even the complier didn't know, it just said "documentation
error")... I had about 100 compile errors in my code due to "' ' not allowed
before '(' in foo (bar, bee)" but ok I just fixed those, one of the things
that attracted me to Julia was whitespace liberalism, a minor irritation with
Python, I find it easier to read code with a bit more whitespace. The trip
wire was that I got the same thing from dependencies - like DataStructures.jl

This is intentional by the devs (I put an issue on GitHub and it got closed
with that note). I do like "lets get it right", but even as someone just
messing about with prime numbers in the evenings I can feel the pain of anyone
who is trying to do more significant things. On the other hand a fork like the
one you describe is going to be bad - Python 2/3 bad, and Julia is in no way
as established as Python was when it had it's fork. The consequences are that
the stable libraries are going to have to focus on the stable build and the
problem is that at that point the dev version is irrelevant.

For Julia that is a big problem. There is a lot to do in terms of developing
the core infrastructure in the language, see the idea of a registry in 0.6 or
shrinking base and having a standard library for example. I do think that
there is a worry that in covering off all cases and requirements the lovely
simplicity of Julia may get diluted, the registry is especially a worry here
because dealing with config files and issues is one of my bugbears and I was
hoping Julia would stop this nonsense by "just use Git".

Still - I picked up Java at 0.7 and it really became useful at 1.4 Julia is on
a much better trajectory already!

~~~
pjmlp
I wonder how you managed to have public access to Java 0.7, internal Sun
releases?

~~~
sgt101
Do you know, I simply don't remember - maybe it was 1.0, but I have a feeling
that I downloaded a beta and was overjoyed at being able to scrap all my hoaky
c++ sockets / CORBA code and reimplement in something amazingly easy called
RMI !

Not sure why I thought 0.7, perhaps I was wishful thinking wrt. how much
change happened in early Java, but I think that the conventions of version
numbering hadn't settled in the same way as they have now.

~~~
pjmlp
The public release was 1.0, quickly followed by 1.0.1.

I also shared the same feeling, given the chaos of writing portable C++ code
back then.

------
dandermotj
I'm really impressed you used Julia in production. Despite its immaturity and
all the reasons you mentioned, building your product on it is a testament to
the language, its potential and the core group working on it. I wonder what
the performance differences in your product are going from Julia to python?

I've had my eye on it for the last two years and really look forward to its
1.0 release. There is no doubt there is an audience for it!

~~~
dnautics
I'm currently using julia to write automated continuous testing for a computer
chip. My only beef is that it isn't zero indexed.

I probably could have done it with python, but IMO the language just is
cleaner and easier to read. The macro system helps, a lot. The typesystem also
gives me confidence in the correctness of some of the stranger code I'm
emitting.

It's a really great prototyping language for mathematical concepts.

~~~
philip1209
The indexing change while rewriting some of our tests from Julia to Python was
the most painful part.

------
transfire
Saw that dependency management was going to be a pain from the get go.
Suggested a fix, was rejected. I decided not to use Julia b/c of this
deficiency even though overall I like everything else about the language.

------
SixSigma
Hi Philip,

You labast the lack of testing tools but one of the other blog posts [1] is
about how you built a testing framework.

We're just just being kind in that blog post because you didn't really spell
out any shortcomings then ?

[1]

~~~
tavert
[1] = [https://blog.staffjoy.com/test-driven-development-in-
juliajk...](https://blog.staffjoy.com/test-driven-development-in-
juliajk-8b66d3664852) ?

~~~
SixSigma
Yes, thanks. Seems I didn't finish my post before I hit submit - someone came
into the room to collect me and I had to log out quickly. By the time I
noticed the edit window was closed.

------
stcredzero
_At the core, most programming languages are quite similar, but the developer
tools and communities shape the culture and ultimately the roadmap of the
language._

~~~
Ericson2314
> At the core, most programming languages are quite similar,

Absolutely not.

> The developer tools and communities shape the culture and ultimately the
> roadmap of the language.

Absolutely so. My fellow PL-ers sometimes forget this part :)---Thankfully
this is changing.

~~~
renox
>> At the core, most programming languages are quite similar, >Absolutely not.

He said 'most' not all, so he is correct.

------
SixSigma
Want to play with Julia ? No install required, just a web browser

[http://www.juliabox.org/](http://www.juliabox.org/)

------
xhub
What tool is now used for the modeling of the optimization problem?

While the work on JuMP is impressive, isn't the fact that all major devs are
from the same place worrisome?

~~~
idunning
Not sure what you mean - in case our office gets hit by a meteor?

