
Some Insights from a Julia Developer - ptype
http://www.stochasticlifestyle.com/like-julia-scales-productive-insights-julia-developer/
======
88e282102ae2e5b
It's great and all, but I can't justify switching languages for minor
improvements over Python + numpy/scipy. I'd be abandoning:

    
    
      * My deep knowledge and experience with Python
      * My entire codebase
      * The ability to work on projects with colleagues who don't also switch
      * The certainty that when I leave my current job, someone will be able to pick up after me
      * Zero-based indexing
    

I've started to do some work in Rust when it makes sense, since there's
occasionally a compelling case and it's substantially different than Python.
Incremental advances in programming languages just aren't worth it, and
knowing that other people are probably coming to the same conclusion means I
can't expect a serious community to ever arise around Julia.

~~~
jernfrost
The improvements are not minor they are massive. Citing rust shows that the
advantage of Julia has not been explained well enough. Julia allows you to
write as performant code as Rust with a much smaller investment in learning.
You cite your concern for spending time learning something new. That makes no
sense considering the high learning curve and complexity of Rust compared to
Julia. Julia is quite fast to learn and has far more overlap with Python than
Rust to make the transition easy. You can call python code from Julia and ise
many of the same tools like the notebook.

~~~
vvanders
Have a citation on the performance vs Rust?

I'm skeptical any GC'd language can approach C/Rust unless they have explicit
mechanisms to do data layout for using the cache/prefetcher to the fullest
degree.

~~~
ViralBShah
The point around Julia's performance is often in the context of mathematical
computing. The two languages are designed for very different use cases.

Julia is designed to make it extremely easy to write high performance
mathematical programs with ease. Rust is designed to make it easy to do
systems programming. Both are high performance for the things they are
designed to do. Just like I wouldn't do systems programming in Julia (although
I am certain KenoFischer would), I wouldn't want to do mathematical computing
in Rust.

~~~
vvanders
Sure but mathematical problems don't exist in isolation. I used to do a ton of
3D graphics work with matrices, vectors, etc. We definitely couldn't use
something that didn't have the right support for data layout and good runtime
semantics.

C/Rust/C++ fit that very well so I wanted to understand how similar claims
were made for a GC'd language. C# for instance can work with value types and
was wondering is Julia has similar constructs.

~~~
omginternets
In the case of research, data-science and -- generally speaking -- "scientific
computing", mathematical problems pretty much _do_ exist in isolation.

This is the niche that Julia wants to occupy.

~~~
vvanders
If that were the case I wouldn't have an adjacent subthread telling me that
they are pretty much the same ;).

To be clear, I have no beef with Julia, I'm sure it's a fantastic language. I
take issue with people thinking they can get the same level of performance
without explicitly controlling their memory access patterns/allocations.

98% of developers will never need it in their careers but when you do there is
no substitute.

~~~
CyberDildonics
Why don't you think you can control those things? Make an array, loop through
linearly, just like C. Avoid allocations in inner loops, just like C.

~~~
xfer
I agree, a lot of the performance problems have to with allocation in any
language, gc'd or not. I still can't believe people making the same argument
against gc'd languages even when highly performant jvm exists.

~~~
vvanders
It's not an issue of allocation, it's an issue of allocation location to get
better cache locality.

Take the JVM, a good majority of ORM databases uses Sun.misc.unsafe to do
manual native memory allocation. Not because it's faster(because it isn't
faster than bumping the nursery pointer).

They do it so they can control where disparate datatypes live in memory so
that as a cache line is read in the prefetcher is already pulling in the next
cache line.

Things like this will get you a 10-50x performance increase, which in some
cases you absolutely need it.

~~~
xfer
Sure, but like you said, 98% don't need it and there is indeed a substitute
when you need it.

------
fasquoika
Whenever I see Julia mentioned, I like to link to this blog post by Graydon
Hoare (creator of Rust).
[https://graydon2.dreamwidth.org/189377.html](https://graydon2.dreamwidth.org/189377.html)

~~~
Bromskloss
What would you say is the takeaway point for this discussion?

~~~
pygy_
Quoting the conclusion:

————

 _Julia, like Dylan and Lisp before it, is a Goldilocks language. Done by a
bunch of Lisp hackers who seriously know what they 're doing.

It is trying to span the entire spectrum of its target users' needs, from
numerical inner loops to glue-language scripting to dynamic code generation
and reflection. And it's doing a very credible job at it. Its designers have
produced a language that seems to be a strict improvement on Dylan, which was
itself excellent. Julia's multimethods are type-parametric. It ships with
really good multi-language FFIs, green coroutines and integrated package
management. Its codegen is LLVM-MCJIT, which is as good as it gets these days.

To my eyes, Julia is one of the brightest spots in the recent language-design
landscape; it's working in a space that really needs good languages right now;
and it's reviving a language-lineage that could really do with a renaissance.
I'm excited for its future._

------
kevinalexbrown
The packages-first attitude feels significant to me. A language that “users”
enjoy but package developers also enjoy seems important. I hadn’t thought
about language choice from a heavily package-development weighted perspective
before. It seems obvious in retrospect though, which is probably a sign of
something cool.

A version of this would be: how can good package development be as easy as
possible, and how can package use be as easy as possible?

I haven’t done any serious work in Julia mainly because the python libraries
are mature, good, and performant enough. I can’t speak for everyone, but for
end users in science labs library support is perhaps the biggest consideration
for language choice.

~~~
pjmlp
It is.

Many of the language flamewars we do, tend to skip over the eco-system.

Which is much more relevant that any language design issue.

Specially given that the decision of choosing a language is a consequence of
working with a specific tool, unless one is open to face some hurdles.

------
ACow_Adonis
Sometimes, in my darker moments, I have the terrifying thought that one of the
reasons that many users like R and made it popular (apart from the historical
context of its now many libraries and being the main free version of
statistical software), is specifically that it isn't robust and sensibly
designed from a programming/analytical perspective.

You can download a package, type in a preset command on a preset thing, and
95% of the time (its R, so its only ever 95% of the time), you get back an
answer/number.

And if an answer is what you're after, that's where the considerations stop.

Was there an edge case? Is R's answer really correct? Did it wallop something
in your search path? Do you have your profile set up differently to the
author? Do all the dependent packages clash and silently depend on how you
load them and in what version you did so? Has R coerced something in the
background, or pattern matched your typo'd variable to something it shouldn't?
Somewhere in your code did you hit on one of the thousands of gotchas?

Who cares? It gave me an answer. I can give it to my boss or put it in a
paper.

I personally am all for faster, safer, stricter (while still being dynamic)
languages. And i've tried to explain to many users that languages that produce
errors when you do something you shouldn't are not your enemies, they're your
friends. But I see many people every day aren't living that philosophy, they'd
rather an answer than the right answer or a robust answer, despite what
they'll tell you in plain english.

With respect to Julia, someone like me might like it (well, if they got rid of
the matlab syntax and just went back to the Lisp they copied and relabeled as
'Julia' :P).

But perhaps many users don't want a faster, more robust language. Perhaps,
many of them are comfortable with a simple but wrong answer. And for that
purpose, I can't see where Julia wins out relative to R.

As I said though, these are thoughts i have in my darker moments...

~~~
x0x0
I think your fears are misplaced.

R users love R because of ease of use. R does sometimes ignores ugly corner
cases in favor of that ease of use (though I'm skeptical this damages the
validity of the answer in anything like 5% of cases), but that's a side
effect.

sklearn and pandas are great, but you still simply have to be a programmer to
use them, or at least much closer to a programmer than many statisticians want
to be. Allowing non-programmers to do things like

    
    
       data <- read.csv(file='blah.csv')
       fit1 <- lm(outcome ~ var1 + var2, data)
    
       anova(fit1)
       summary(fit1)
    

to read data, run a linear model, and get an anova and p-values is amazing,
and massively widens the scope of people to whom these tools are available.

This omission of most quoting, the magic inference of column names, etc etc
all makes R much easier to use.

~~~
ACow_Adonis
In many ways, I think we're actually in agreement :p

Free. Quick. Interactive. 4 lines. Done. What's the value proposition of Julia
compared to that? Now you can argue that Julia will allow better type
specification and specialisation, etc, etc. But that's not what's valued or
used in your example.

Now, my mindset/domain has to engage with such, and i freak out at the
implicit-ness/assumptions inherent in such code, especially with some of R's
additional design choices.

In my mind, having code that crashes/errors out when something
ambiguous/dangerous is encountered in your example a "good thing". But that's
not what's valued in the above example.

And while Julia would allow someone to program in such a way as to specialise
or raise these errors and concerns, what is valued is the ability to not think
about them. And if you don't think about them, or even as a library designer,
if you want to program in such a way that your user primarily doesn't want to
think about them, then you're effectively very close to
reinventing/reimplementing a new "R", with all its costs and benefits.

I'm just making this observation explicit, even though I actually do value the
things the Julia crowd seems to value, but I'm not sure I'm in the majority,
and I'm not sure you can push that down into the libraries without exposing
concerns most users don't want to be exposed to.

~~~
fspeech
DWIM (Do What I Mean) at the UI level seems a good feature to aspire to. The
sanity check could (and should) be done using an independent method (say
manually check a couple of things, or is that too out-of-dated?).

------
j7ake
Everything sounds great about Julia but it's lacking sufficient critical mass
to develop useful packages to make scientists and data analysts effective.

At the moment the bottleneck in our scientific computing and data analysis
workflow is not waiting for code to run but rather quickly inplementing,
evaluating, and iterating different models on datasets.

~~~
freyir
When I last looked at Julia, the language wasn't yet stable. It's not fun
developing packages for a language that changes from release to release, so I
don't expect their ecosystem to stand a chance until they get to v1.0. All the
advantages for package developers listed in this article are moot while the
language remains a moving target.

It was said that v1.0 was due in early/mid 2017, but it looks like it's still
a ways off.

There is (or was) a window of opportunity for Julia to steal mindshare in
academia from MATLAB and R, but it feels like Python is beating them to the
punch. Of course, Python had a 21 year head start.

~~~
sgt101
Talking to people in the community my impression was that 1.0 would appear
when 1.0 appeared and that they felt that given the difficulties faced by
other languages and the work required to produce a language that was fit for
purpose in the modern context, a gestation time of more than a couple of years
was reasonable.

In terms of community I think that the economics community and private equity
firms in particular seem to have picked Julia up enthusiastically.

Having said that, I suspect that it will be three years before Julia becomes
mainstream, and then it will be a minority choice for five or six more - if it
is the big success it deserves to be!

------
crwalker
Julia is my go-to language for numerical work.

Compared to other solutions I've used like python + numpy + pandas, Matlab,
Mathcad, heh even Excel, Julia is a breath of fresh air. Fast, clean,
powerful.

~~~
salqadri
The feature to observe the underlying AST is amazing!

~~~
jey
And ccall makes it trivial and a delight to call subroutines written in C++
with Eigen and OpenMP.

------
williamstein
Strangely, the only mention of Cython is to point at that we have had less
developers than Julia: "as evidenced by the over 500 committers to just the
Base language, more than projects like Cython has ever had!"

~~~
ChrisRackauckas
I don't find it strange: I wrote this to say why I like using Julia and point
out what the community is missing, not as a comparison to every other JIT in
existence. But if you want to know why I gave up on Cython, I'll lay it out
for you. I tried it almost 2 years ago because some documents in a course had
IPython notebooks which used it. So I did some standard scientific computing
stuff like write some Runge-Kutta methods and yes its speed was fine (that was
a pretty big part of the blog post: if you try hard and use the right tools
you'll get pretty much the same performance anywhere). That's not the problem
at all.

The problem was extending it to be more widely useful in my own research. I
wanted to make those same compiled functions also work with complex numbers to
integrate spectral discretizations of a stochastic PDE (instead of the finite
difference one from before). I found some SO posts like:

[https://stackoverflow.com/questions/30054019/complex-
numbers...](https://stackoverflow.com/questions/30054019/complex-numbers-in-
cython) [https://stackoverflow.com/questions/27906862/complex-
valued-...](https://stackoverflow.com/questions/27906862/complex-valued-
calculations-using-cython)

At that point it stopped looking like Python at all. I always found the SciPy
syntax a little verbose since I had used a lot of MATLAB before (but I wanted
to make this project not require a license to run) (this QuantEcon cheatsheet
is a good demonstration of what syntax is like in my domain:
[https://cheatsheets.quantecon.org/](https://cheatsheets.quantecon.org/)). But
to make this kind of "complex or not" logic work in compiled Cython, I
resorted to conditional compilation
([http://cython.readthedocs.io/en/latest/src/userguide/languag...](http://cython.readthedocs.io/en/latest/src/userguide/language_basics.html#conditional-
compilation)). These days I understand that what I created was essentially a
multiple dispatch mechanism.

Anyways, at around that time I started experimenting with other tools,
especially Julia, because I really was getting frustrated whenever I had to
"go beyond doubles" and write something that was extendable instead of a one-
use script. Maybe there's some tricks I was missing, but I found it really
hard in Python and MATLAB. Soon after, my PhD adviser and I started arguing
about whether one of the properties in the simulation's solution was due to
floating point errors. I couldn't convince him, so I wanted to write this
integrator so it was fast and compiled, but allowed arbitrary precision so
that way I could prove that it still existed even with very high precision. I
couldn't find a page which explained how to do high precision arithmetic in
Cython or Numba, so I completely gave up. Needless to say, I decided to re-
write a small portion of this in Julia and it worked really well, pretty much
instantly. Then I was digging around the Julia package listing and Viral
pointed me to a big opportunity
([https://github.com/JuliaDiffEq/ODE.jl/issues/64](https://github.com/JuliaDiffEq/ODE.jl/issues/64))
and I have been developing a lot of Julia differential equation solvers ever
since.

Obviously YMMV, but after computing a lot without a "first-choice language"
(between R, Python, C, MATLAB, Mathematica) for quite awhile, I kept with
Julia because I didn't have issues when I hit less standard tasks, and I found
it very easy to contribute fixes to other people's projects because it was
just Julia code. This stochastic PDE integrator story is just one
(significant) project that led me in this direction.

~~~
syllogism
Well...It _is_ strange to omit Cython, because that's what the package authors
actually use :). It's a huge part of answer to the question you pose about how
package development works in Python. Cython isn't perfect, but it works very
well.

To answer the specific question you had about multiple dispatch: Cython's had
fused types for a while now, although I guess they weren't so prominent in the
docs when you were trying to solve your problem.

The other problem with your argument is, I think you have the dynamics
slightly backwards. Complicated libraries will go where the users are, not the
other way around. Maybe my NLP library spaCy would've been easier to write in
Nim or D. This didn't matter. I wrote it in Cython because I saw that the
userbase would in Python. This has proven correct. It also has the effect of
drawing slightly more users to Python, continuing the feedback loop. But each
library's marginal impact on the developer community is small, so you're never
going to get the marginal package author to switch language for the sake of
convenience. What good is it to have a convenient experience developing a
package nobody will use?

~~~
ChrisRackauckas
The problem is, I needed the library. I didn't have the time and resources to
build it in Python, while it was a night project for a week to build it in
Julia. As a methods researcher I'm going to use the tool that doesn't impede
my research but allows me to distribute robust and performant implementations,
which after trying lot of other tools I've found is Julia.

------
j7ake
I looked at your blog post on solving differential equations and it looks
pretty attractive. I will install Julia and play around with this differential
equation solver. At the moment R and python are awkward with differential
equations, and I don't want to be married to matlab.

------
jampekka
Too bad they somehow thought it was a good idea to make the syntax resemble
MATLAB of all languages. Perhaps most of the nausea inducing warts could be
worked around with some kind of transcompilation, although some semantic
issues, such as one-based indexing, would remain.

It'll be a sad day if Julia starts to get such popularity that high quality
libraries will be Julia-only.

~~~
azag0
One-based indexing is not a semantic issue, it's a language-design decision
you may disagree with.

~~~
PeachPlum
Julia 0.5 introduced support for any indexing scheme you care to invent.

1-based 0-based 20-based

[https://docs.julialang.org/en/latest/devdocs/offset-
arrays/](https://docs.julialang.org/en/latest/devdocs/offset-arrays/)

~~~
attractivechaos
That is an ugly hack, mainly because it was not in the original language
design.

~~~
pjmlp
Why ugly? It looks similar to what I know in the Pascal family, where indexes
can be ranges or enumerations.

~~~
attractivechaos
It is ugly because 1) 1-based indexing and x-based indexing are treated
differently; 2) x-based indexing has to use more complex syntax, which in
effect discourages the use of non-1 indexing; 3) this strategy sets potential
pitfalls (e.g. implementing length and size for non-1 indexing arrays). A
cleaner design, I guess, would be to specify index range on declaration like
pascal static arrays and use low(A):high(A) for iteration rather than
1:length(A). This, however, complicates 1-based use cases.

Generally, I don't think there is a good way to achieve flexible indexing
without causing troubles somewhere, so I don't think Julia has really solved
the problem.

~~~
ChrisRackauckas
1) No, they are just different dispatches to getindex. 2) No, iteration is
through indices(A) or eachindex(A), etc., which are the preferred way of
iterating anyways. You shouldn't do 1:length(A) which is a MATLABism that
works but I would say isn't good Julia. 3) Defining new dispatches for length
and size is a pretty standard use of the language?

"Non-standard" arrays with non-standard indexing already work in lots of
packages. It could be better (that's one of the things that I am advocating
for), but it's not a language tooling issue whenever it's a problem, it was
the developer going `::Array` and thus requiring a contiguous 1-base index
array where other AbstractArrays would actually work.

~~~
ChrisRackauckas
@attractivechaos I don't know how to reply to your last reply, so I'll do it
here. 1:length(A) is bad because it's using a standard construction for
intervals of numbers, but using it for indices. We don't want to get rid of it
because 1:5 or 0:0.2:1 is something that is very common and necessary, but I
don't see how to tell one that they should instead use eachindex(A) except
through proper docs. 1:length(A) is so common in MATLAB though that I am sure
people will carry it over, and I'll PR to their library to fix it. I'm not
sure how to fix a knowledge issue like that.

You're not understanding generic types and its relation to (1). There's only
one way to access an array: getindex. That's the function that's called with
A[i]. However, you can use an immutable to put a thin (zero-cost) wrapper over
an array, and define dispatches to getindex to do whatever you need it to do.
So it's both implicit syntactically because the user just does A[i], but it's
explicit because the user has to choose a different type. getindex is then
usually inlined and then compiled according to the type, making it a thin
abstraction over the implementation.

There are iterators which don't have a size or length. You can write generic
algorithms which require an AbstractArray which HasLength and query at compile
time for things like that and throw appropriate errors (those are called
traits).

There is still a lot of development to do here, but the basics like this are
pretty much solved except when new users treat Julia like MATLAB, but I'm not
sure how anyone could control for that.

~~~
conistonwater
You can click on the timestamp, and there will be a reply link there. I think
reply links are hidden for a little bit of time after posting, but I'm not
sure why.

~~~
pygy_
This is an anti-flame war feature, designed to let people cool off before
replying (fast paced discussions were often contentious before that was
introduced).

~~~
attractivechaos
I guess so. This is a well thought feature. I like it.

------
mhd
Is there a good use case for Julia outside the "math" community, when your
alternatives wouldn't be R or Numpy, but Ruby or C#?

~~~
parenthephobia
Perhaps it's a borderline case, but I've used Julia to make a "big data"
database server, backed by a mmap'ed column store.

Because the compiler's available at run-time, queries can be compiled into
efficient kernels that can run in parallel over multi-gigabyte arrays orders
of magnitude faster than MySQL or Postgres on the same hardware.

Without Julia, I would have had to find some _other_ way to compile queries
into machine code at run-time, which for me would have ruled out all the
languages you listed. In practical terms I would have abandoned the project.

~~~
flavio81
Excellent use case.

> _Without Julia, I would have had to find some other way to compile queries
> into machine code at run-time_

Note that you could also do it in Common Lisp.

But I agree, Julia is very powerful, perhaps one of the most powerful recent
languages.

------
stabbles
One issue I have with Julia is that it is fast _the second time_ you run your
code. And developing code is mainly running things just once. In practice you
might find yourself waiting on compilation a lot.

~~~
azag0
That all depends on factoring. If running your code once means evaluating some
function hundred times, then that's no issue.

------
_Codemonkeyism
"is a good generic type-stable function for any number which has zero and +
defined. That's quite unique: I can put floating point numbers in here,
symbolic expressions from SymEngine.jl, ArbFloats from the user-defined
ArbFloats.jl fast arbitrary precision library, etc."

Is it really unique? Isn't that just a Monoid (e.g. in Haskell, Scala, ...) or
am I wrong?

~~~
StefanKarpinski
I think that unique is an overstatement there, but in the context it's a
comparison to other numerical computing systems, where this kind of support
for generic code is less common.

~~~
ChrisRackauckas
Yes,i it was an overstatement. But, while I do see it can be done with these
Monoids, I haven't come across these kinds of numerical linear algebra
libraries that allow generic code in other languages (here's an example of
what I find in Haskell that requires double:
[https://hackage.haskell.org/package/hmatrix-0.14.0.1/docs/Nu...](https://hackage.haskell.org/package/hmatrix-0.14.0.1/docs/Numeric-
LinearAlgebra-Algorithms.html))

------
domador
"...the majority of programmers are not developers."

Could someone please explain the difference between the two terms? I've always
used them synonymously.

~~~
ChrisRackauckas
Thanks for bringing this up. It may be more of a domain-specific use of the
terms. In science and math, most of the people who are "programming" are not
really that deep into programming. Most people go to a workshop on "here's how
to use R to do some regressions", and they will know a small portion of the
language and usually rely on some libraries to handle most of the heavy
lifting. For example, the size of the community that actually develops code
for analysis in bioinformatics pales in comparison to the size of the
community that is doing "bench" biology and performing the analyses. There is
a clear distinction because in many cases the training is very different (CS
and math backgrounds, vs more science backgrounds) and the "average day" and
research focus are different. You can swap out biology with pretty much any
other field and see the same split and this is the "package user" vs "package
developer" split in technical computing.

------
rurban
> Julia's JiT is not like other JiTs, and it helps package development

Julia's JIT is a simple plain method jit, the easy one. He doesn't describe
the pro's and contra's of method jit vs tracing jit. In short, method jits
explode in memory usage and forbid expensive optimizations. The advantages are
of course as described easyness to work with, reproduce and debug. Most JITs
start as simple method jit, and then advance to Tracing JITs. Esp. with
performance orientated languages with a lot of vectorization potential.

It's a great language. But the JIT will be improved sooner or later. Esp. with
the memory-expensive type-optimizations.

------
skybrian
I'm wondering about this part: "using this strategy Julia actually can produce
static binaries like compiled C or Fortran code."

Is this something that works now, something planned, or just speculation?

~~~
ViralBShah
It does work. It is not user friendly just yet, and compiler work needs to be
done - but yes, you can get binaries and shared libraries today.

[https://github.com/JuliaComputing/static-
julia](https://github.com/JuliaComputing/static-julia)

------
RivieraKid
I really like Julia overall but I'm undecided whether it's good as a general
purpose language. Right now I'm working on a few-thousands-lines-of-code
project and sometimes wish Julia was more like Swift:

\- Writing code with Nullables is cumbersome and verbose compared to Swift.

\- The object.method() notation is sometimes more readable, especially in more
complex expression. Plus, in an IDE it works well with completion.

\- The ordering of types in a file matters.

\- Overall, Swift code looks a tiny bit more readable, cleaner.

\- No interfaces.

~~~
jernfrost
I get what you mean, but I kind of miss the other when working with one. For
larger code bases Swift feels "safer", but Julia tends to feel more enjoyable
and fast to try out things with.

But yeah I REALLY wish the Julia guys can come up with a nice way of dealing
with Nullable.

But I actually don't miss the `object.method()` notation. I find it is so much
more straightforward to compose things functionally when everything is a plain
function. I feel methods just adds complexity to a language. For readability I
tend to use the form `x |> f |> g |> h` if I need to make it easier to read a
call like `h(g(f(x)))`.

I agree completion is a bit nicer with `object.method()` but function
completion works quite well in the REPL and Juno. I use `methodswith()` to
locate relevant functions for a type.

In some ways I think it is actually easier to deal with than in Swift, as
Swift base classes have so many methods you can't find the stuff you are
interested in quickly.

I have kind of wanted Swift to be the solution for everything, but I see that
the API design philosophy for Swift makes it difficult to turn it into a
language which is as nice for data science as Julia. There is no focus on
making stuff like matrix classes, multidimensional arrays, shell integration
etc.

Also I don't quite like that Swift ties me so much to an IDE. Writing Swift
code with a plain text editor and a REPL isn't as nice as doing it with Julia.

------
anon_342njlkesr
Yeah, the language design of julia is brilliant (multiple dispatch, typing,
llvm use, zero-cost abstractions, @code_native to see why your code is slow).

This allows you to write fast code in julia, which is impossible in python
(you can call into very fast C/Fortran libraries with nice bindings, though).

On the other hand, I really hate the syntax. One-based array indexing (ok,
minor), blocks ending with "end", and most importantly unicode support.

Really, who thought that it was a good idea to allow symbol names that are
unreachable on a standard US keyboard? WTF? This makes it supremely
inconvenient to use libraries that happen to export symbols with crazy names.
If you must, specify a name mangling scheme and let people who want to see
crazy symbols use an IDE. Seriously, am I supposed to use a hex-editor when
auditing julia code?

I totally agree with the author that package discovery and uniformity are a
big problem. Indeed, this is even moving in the wrong direction: More and more
functionality is removed from Base and put into external packages. I would
prefer a more "batteries included" style, with uniform quality and
documentation for standard functionality (splitting into different namespaces
is good, though), python-style.

Second non-cosmetic problem is that the language documentation is atrocious,
both from a completeness and pedagogical viewpoint. Pyhton is again the ideal
to aspire to.

But the point of the article stands: It is easy to write fast julia code, and
the Julia (non-C/C++) parts of the Julia core form a nice tutorial for how
"good" julia code looks like. If a function is not well-documented, look at
the source code. In python, you quickly run into the C-wall (function is
really implemented in C and the way the wrappers work is really non-uniform);
in julia this is more rare, and the wrappers tend to be much easier to pierce
(ok, julia does a ccall, figure out the code of the target; the wrappers are
human-generated and readable and don't come out of a complex build
environment).

But yeah, you shouldn't use julia for systems programming until a good
standard way for unmanaged code has been fixed, if ever (mixing types that are
garbage-collected and types that are programmer-memory-managed, you want
garbage-collected types for performance-irrelevant parts and programmer-
managed types whenever precise memory alignment matters for your performance).
Oh, and the nullpointer support sucks big time.

My personal hope is that the python->julia interface improves. Then python
users will be able to profit from fast, easily developed julia packages.

~~~
jernfrost
I greatly prefer Julia syntax. `end` makes the code blocks stand out more
easily than }. I find it easier to see the indentation at a glance than when
just dealing with a single thin character.

Also I like that Julia prefers shorts words over special characters. C/C++ use
far too many special characters.

That might run counter to my delight at unicode support. I think it is quite
nice to be able to write mathematical code using the same symbols as used in
mathematics. I use the Julia REPL to write this where you got latex
completions to get unicode characters.

"Second non-cosmetic problem is that the language documentation is atrocious,
both from a completeness and pedagogical viewpoint. Pyhton is again the ideal
to aspire to."

I could not disagree more. Here is an account of Julia vs Python from mostly a
pedagogical point of view: [https://medium.com/@Jernfrost/python-vs-julia-
observations-e...](https://medium.com/@Jernfrost/python-vs-julia-
observations-e61ee667fa95)

A few points. Documentation is often easier to read. E.g. look at the example
of the `print` function.

Function usually have more sensible names in Julia and you don't have to guess
which package they are hidden in for common things such as working with
strings, paths and arrays. Part of this is due to Julia multiple dispatch
which allows reusing the same function name for related functionality, while
python is forced to invent unique function names too often. Even when it
doesn't make sense.

I'd say Julia adheres to the Python zen of least surprise. Checking if a
collection is empty, can be done with `isempty()` which is similar to a number
of other languages. Python in contrast treats empty lists as boolean objects
which are false when empty. How is that obvious?

~~~
anon_342njlkesr
Re unicode:

When writing latex, you don't want to encounter unicode greek sigma. You want
\sigma, as 6 7bit-ascii chars. Same in julia; sure, define a display mode that
translates certain things into unicode for people like you, but keep
compatibility with code-editors/people/tools who do not understand unicode. In
short: I want to it to be possible to use a dumb text-editor, not an IDE/word-
processor. (ok, the text editor will need to understand UTF8, because unicode
string literals are really important; but please never go beyond a small
white-listed subset of 7bit-ascii for language tokens).

~~~
jernfrost
LuaTex which is displacing Latex is doing just that, increasingly using
unicode directly. I’ve never used a plain editor on my Mac which DIDN’T handle
unicode. In fact I use a plain text editor to write julia code whith unicode
symbols. Anyway it is a tiny portion of the code and the Julia public API
never force you to use unocode. You can always chose a non-unicode variant of
the API.

Not using UTF8 in this day and age is just begging for problems.

At least on my mac you got OS wide tools for working with unicode.

------
barche
Great article! Coming from C++, I agree Julia feels a lot like "C++ done
right", i.e. where C++ forces you to jump through hoops with the verbose
template syntax, Julia does generics by default. Also, it's great not having
to wonder for every function argument declaration if you should add *, &, &&
or any of the const variants.

------
AlexCoventry
I tried julia last year, and it was a nightmare of version skew. Has it
improved in that regard at all?

~~~
ChrisRackauckas
If you need something stable, wait until a bit after 1.0, like you would with
any Windows release. Right now it's expected that things will change and break
with language updates, but the next one is the 1.0 which is the "we stop
breaking things now"

~~~
AlexCoventry
That's what I was told about 0.4 -> 0.5 last year.

~~~
ChrisRackauckas
By who? Someone who isn't part of the development team? There was an issue set
for v0.5 called "Arraypocolypse" that was meant to change a ton of things
related to arrays, and that was known months (a year?) before v0.5 was out.
Semvar is used for a reason: pre-1.0 is all breaking.

~~~
AlexCoventry
People on gitter, IIRC... I'm sure there's a record of it somewhere. Half the
packages I wanted to use were still on 0.4, half were on 0.5, and the
combination was incompatible.

------
bigJack9
Julia is really fun to work with.I really love the REPL, multiple dispatch and
the way you easily introspect code upto native assembly code.

------
tomoya
"i like julia too"

