
The Julia Language – A fresh approach to technical computing - fishmaster
https://julialang.org/
======
ssivark
Given the number of Julia-related posts on the front page in the recent past,
I doubt there is a need for a post linking to the generic home page for the
language. That said, it would definitely be interesting discuss something
unique or specifically interesting.

~~~
fishmaster
Where else would you discuss the language itself?

~~~
DNF2
General (and specific) discussions about the Julia language can be had at
[https://discourse.julialang.org/latest](https://discourse.julialang.org/latest)
(the main Julialang forum), and on Reddit
[https://www.reddit.com/r/Julia/](https://www.reddit.com/r/Julia/)

~~~
fishmaster
... where else on HN, obviously.

------
hellofunk
One thing I've wondered about: I see it frequently written that someone new to
Julia sits down and write an algorithm, and despite that language's marketing,
the code runs at a fraction of C++ speeds. Eventually, the code gets a speedup
only after significant and non-obvious tuning that requires a lot of Julia
experience. That concerns me that this would be the common scenario, and I see
this written often in articles, blog posts, forums, etc. It's the one point
that has turned me off of diving too deeply into it.

~~~
ddragon
That's true, but it's because Julia looks like Python/Fortran/Matlab on the
surface but it's a really unique language that you can't really learn in one
day or two. Write Julia like Python and it will be slow (dynamic languages are
slow after all), write Julia like Fortran and it will be fast (static
languages are fast, but they are restrictive). And after you actually learn
the language you can fairly easily write extremely dynamic code that is around
80% of the speed of C just following a few rules (only consts on global
namespace, type stability, typing containers like struct, abusing multiple
dispatch/parametric types and profiling the eventual inference failures).

Being permissive lowers the barrier for non CS people, one of the main target
of the language, to start using the language, especially in the REPL/Notebook,
even if they are not the most effective at the language.

~~~
appleiigs
This is a feature of Julia I like. I write in my pythonic way, slow but good
enough. Then I tune it when I really need the speed. As you and others
mentioned, there's only a few things to do to get most of the way - put things
in functions, type stability, optimize array allocations. Also more here:
[https://docs.julialang.org/en/v1/manual/performance-
tips/](https://docs.julialang.org/en/v1/manual/performance-tips/)

~~~
eigenspace
It's important to emphasize that while this may _sound_ like what Python
people do with Numba or Cython, it's actually quite different because whether
or not you write "slow julia code" or write "fast julia code", it's all seen
by the same compiler.

A highly tuned kernel function can be inlined into a not so finely tuned outer
function and vice versa, our metaprogramming tools see both functions the
same, etc.

~~~
ddragon
Plus high performance Julia code (at the 80% of C range, maybe not at the 100%
range where micro-optimizations start to happen) isn't any less readable than
low performance Julia code. A common misconception is that annotating every
type and making it more imperative and C-like makes code faster, but as long
as you internalized what makes code slow, making fast code is surprisingly
just as concise as it would be in Python without any type annotation.

But since fast and slow code are so similar, and both give the same ultimate
result, it becomes less obvious for someone who is reading someone's code to
see what was made to make it fast (even if it's easy to see what the code does
because of it's high level nature). I think that's something that could
improve over time with better tooling, using the meta-capabilities of the
language to create linters and compiler suggestions that guide the users into
making the small changes in the code that makes the most difference.

------
devxpy
I like the idea that I can just write for loops instead of weird numpy magic,
I really do.

But languages doesn't work in silos. I don't want a fast language that I
cannot use for writing, say web servers, without rewriting 90% of django.

The proposition of python is that you get acceptable performance with an
insane package repository that means you can _ship_ so much faster.

And if you absolutely need to write for loops, use clever things like numba or
cython.

Stop reinventing the wheel people.

~~~
ddragon
It's kind of complicated to consider creating new programming languages as
reinventing the wheel. Every new language will be created with a smaller
ecosystem so someone will always have to rewrite X that some older language
already has. But they are also created with the knowledge of what worked well
and what didn't in those previous languages, so it's not reinventing the
wheel, but inventing a wheel that (attempts to) corrects the fundamental
mistakes/compromises that were inevitable with the knowledge and tools of that
time.

Julia was created with 20 years of extra knowledge from Python, Matlab, R and
other languages, and from a domain that basically didn't exist when Python was
designed, resulting in a set of features that cannot be added to Python at
this point. It's a different wheel, which can move faster so even if the cars
with the old wheel are way ahead, it can still eventually catch up (creating
libraries in Julia from scratch is easier and faster so it can compete even 20
years late and with much lower support). Should we stop trying to create
improved languages, stay with the languages we have now forever and simply
create increasingly "clever" ways to compensate any flaw (that can't be
directly fixed without breaking all that legacy)?

Plus Julia has web frameworks like Genie, but it's true that they are nowhere
near as mature (especially compared to a project that is considerably older
than Julia itself).

~~~
brylie
> creating libraries in Julia from scratch is easier and faster

Easier than what? In what ways is it faster?

~~~
ddragon
It's easier and faster because it's a more powerful language. You can achieve
fortran/C speeds without leaving the language (for example Tullio.jl and
LoopVectorization.jl competing with super optimized BLAS methods). Multiple
Dispatch means libraries can compose, for example Julia's main Machine
Learning library doesn't even need to know anything about GPUs to run all of
it's methods on it (said library is also only a few thousands of lines of high
level Julia, and the CUDA library is also 100% Julia). Even the state of the
art implementation of Tensorflow interface that couldn't work on Python (Swift
for Tensorflow, a fork of the swift compiler) had a competitor implemented as
pure Julia libraries (Zygote.jl, a source to source differentiation library)
thanks to it's metaprogamming capabilities.

I did mention from scratch because of course, if your library requires another
library that does not exist (and you don't want to use the FFI), it won't be
faster or easier (though I did mention in the previous comment that it's
something all new languages will have to go through, until it's not a problem
anymore).

