Time to shill this again. Julia is an amazingly nice language to use. Having parametric polymorphism and multimethods in the same language is really fucking neat. Lisp macros are also really great to have whenever you have a problem where a DSL is warranted.
Also, having extensive code introspection & benchmarking tools in the REPL has ended up having a really good effect on the library ecosystem. It almost completely eliminates the "absurdly slow corporate library" syndrome that you see in Java, when library authors frequently benchmark their code because it is easy to do.
Julia is a language on one asked for. All kinds of numeric, statistical and scientific code work fine by wrapping C++ in Python, something Python (CPython specifically) is uniquely good at because of the way the interpreter is written.
Given this, there is no niche for Julia. They claim it's good to be able to do everything in one language. That's true, but the benefit isn't enough to challenge the huge Python ecosystem for numeric programming.
Jack Long
As an avid R user, I'm pro julia. Go shill, go!
Jack Bennett
They said the same thing about MATLAB The GIL is a huge unsolvable issue that will eventually make Python die off
Luke Rivera
i use julia for mathematics, i like it alot and working with matlab is easy since the syntaxs are so similiar.
James Miller
>They said the same thing about MATLAB Yes but Python has gained huge market share against MATLAB in the last 20 years.
>The GIL is a huge unsolvable issue that will eventually make Python die off It's a huge unsolvable problem, but becoming less relevant with GPUs and other custom hardware for machine learning. Once you are offloading the heavy numeric lifting to the GPU or other processors, things like the GIL become irrelevant.
Jonathan Wood
I like that it's named after me, I don't like anything else about it. I will hammer on Python until it works for what I need no matter how unsuited it is
Ryder Stewart
Writing GPU code in Python + CUDA is an absolute mess.
Julia is much nicer to write GPU code in than C++, and can achieve much better speeds than Python calling GPU libraries since you can fuse operations together.
Also, enjoy needing to call the sin, cos, sqrt functions from Torch instead of the ones from the python stdlib because Python's functions aren't extensible, so you can't use libraries external to the framework you are using.
While using a pure Julia GPU framework, any external functions that can be SIMDed will just work on GPU's as well, regardless of which library it comes from.
Michael Davis
Did you just say that CPython is good at wrapping C functions? Have you even worked with Python's slot system?
Anything intended to call C is saner than CPython's C story. Pypy is better at it. Ruby is better at it. Lua and LuaJIT are better at it. Even Haskell is better at calling C than Python is.
Cooper Mitchell
The fact that Cython exists and is widely used should tell you that writing C extensions for CPython is a horrible story.
Josiah Phillips
Lisp macros you say? Does it have homoiconicity?
Samuel Robinson
Not as explicitly as Lisp does, but the syntax is designed to have a fairly clean AST, and you can work with it freely and pass around code as data, and write macros with defmacro.
Out of the box it's slightly annoying to work with AST's but there are libraries that define a bunch of macros to make writing macros easier and which let you match fairly complicated patterns easily.
Shill it all you want, I already love it. Julia is just so much faster and nicer than Python's scipy/numpy/pandas bullshit that i've nearly dropped the language.
Dylan Ramirez
If you were to compare the pros and cons to lisp, where would you say the strengths of Julia lay?
Grayson Rogers
Still better at array operations than basically any 0-indexed language. And you can define arrays that start at any index if you want to, or which range between -infinity and +infinity and grow as necessary.
James Richardson
Pros: *) Speed. From my experience, it's faster than any current lisp implementation including SBCL and the proprietary lisps. SBCL might be a bit ahead on GC performance, but Julia has the better compiler output with LLVM.
*) Better type system which is integrated with the compiler, built with CLOS-like multimethods in mind (every function is the equivalent of a generic function in CL). Multimethods compile monomorphized methods whenever they encounter a new type combination, so you don't need to add type annotation other than for defining different methods. The JIT compiler has access to all the type information and tries to infer types when it can to optimize away typechecks, which it is really good at. Has parametric polymorphism where you can define arrays of a single type, or define dispatch rules that depend on a parametrized type signature.
*) One single implementation with no fragmentation, and more users than CL and Scheme combined at this point. Most stack overflow questions are about how to use specific libraries or advanced features rather than about basic features.
*) Really good libraries if you're planning to use it specifically for mathy stuff, with best-in-class libraries for many specific domains, like say solving ordinary differential equations. OK-for-a-new-language libraries for other domains. Really good at calling other languages and at replacing the shell.
*) Looks a bit more Algol like at first glance and is approachable to new programmers.
Downsides:
*) Has macros, but it's not Racket. Syntax tree is a bit more varied than just S-expressions,
*) No serious metaclass support if you really liked CLOS-heavy stuff, or full MOP. You technically have covariant metaclasses as a consequences of how the type system works, but it's not really something that's intended to be used.
*) Half of those users seem to be in academia. It is varied STEM academia though, as opposed to mostly CS academia for say Scheme.
As a physicist, i REALLY hope julia gets adopted as a language, but i kind of doubt it will happen. MOST non-programmers aren't really interested in learning multiple languages, and as a single-language, python is better suited for scientists. It requires less programming know-how and is just a better all-rounder. It also won't get any real traction in high-performance computing, as C is ultimately faster.
That being said, i fucking love that a language that is basically as simple as python can produce fast programs, and i really hope that i am wrong.
Adrian Watson
I am amazing, I know ;)
Jacob Nelson
For loops are still slow as balls with CPython. Which limits you to doing everything in library calls or taking a huge performance hit.
Ayden Cox
Julia is the Rust killer
Jacob Ortiz
I don't see how it is relevant language at all. Data science has consolidated around Python where all top libraries are implemented in C.
What exactly is it supposed to replace? Matlab? Good luck getting people off that GUI. F#? R?
Jeremiah Peterson
>julia shill but everybody use python >perl shil use python, it's more popular >bash shill python is better
>I don't see how it is relevant language at all. Data science has consolidated around Python where all top libraries are implemented in C. This is exactly why Julia will replace Python, Python is a shit language that can only be used as a wrapper around C libraries, whereas you can write the libraries in Julia. Python has a completely unusable package/module system which is why everyone who uses Python has to use the condo package manager that comes with Anaconda. Using Python in STEM means you are stuck using other peoples libraries and can never make libraries on your own. Also high order functions in Python is a joke, whereas they are very powerful in Julia. OO in Python is a joke, Julia avoids OO altogether meaning that functions are the most important data type rather than making functions part of a static data type like in OO. This is makes Julia a more data oriented language as functions are not tied to certain data types.
Christian Reed
Lua can do the same thing, because it also was influenced by Fortran, but idiots will forever think it's 1-based exclusively and they are ignorant to the fact that there's actual algorithms out there that work better with 1-based indexing instead of 0, which is why this is a supported feature in the first place.
