Hacker News Reader

Comment by zbobet2012 | Hacker News Reader

zbobet2012

Julia is a great language, but it is still focused on the numerical computing world and is not "1.0" (language and API's are not locked down). I wouldn't really compare it to Go or Rust at this point. Go is focused on building services at its core (e.g. external event driven workflows). Aka microservices. Rust is focused on being a "traditional" systems programming language. Things like web browsers (duh), office suites, games, etc.

Julia is focused on taking the best of R, Python/Numpy, and Matlab. It is a _great_ language. But as far as I can see it's really focused on a different problem space.

View on HN

If you take a look at the features (esp. macros and multiple dispatch) you can see that is readily extensible for lots of applications. Thus the reason it is also sold as a "general purpose" language.

Additonally, the very good support for threading and multiprocessing means it has a good future with services, async IO, and with event-loop web servers (a la node.js and friends).

Finally, the focus on fast speed for numerical computation is particularly suited to games (as is the support for threading).

> good future with services, async IO, and with event-loop web servers [...] particularly suited to games

This all seems extremely unlikely (compared to e.g. widespread success in scientific computing, which is still far from assured). Good luck though.

This sounds like a small thing, but with 1-based arrays, I'd bet more on it taking share from MatLab/R than from Rust or Java.

I didn't think 1 based arrays would be a big deal, but whenever I try to port code from Julia to almost any other environment (C++, python/numpy, scala, JS), it becomes one of the hardest things to reason about quickly and correctly.

1-based arrays, and column-major layout of arrays annoyed me at first, however, one of the beautiful things is that much of Julia is written in Julia. If you want 0-based (or arbitrary based!) arrays, then simply use the https://github.com/JuliaArrays/OffsetArrays.jl package, and PermutedDimArrays have been added to Base, to handle some of the issues of dealing with row-major (and other sorts of memory layout) matrices.

Doesn't this mean that instead you're now dealing with inconsistent data representations?

Games are not going anywhere from a mostly C++ code base. New languages get adopted if they are too good to be true or they have enterprise adoption like Go. Even Python took 20 years to reach where it is now. Julia will take a long time to become a general programming language for all purposes.

Scientific Computing is a realistic goal just like Golang is a realistic language with Enterprise adoption. It may not be the most elegant language like Lisp but it is practical. (People don't want the perfect solution but one that works most of the time) (P.S I am vaguely quoting this from some anecdote about a discussion on Lisp and C)

Handling technical/scientific/numeric programming well is rather a hard nut to crack, and that is where the developers of Julia wanted a better solution for their own "greedy" programming needs, but Jeff Bezanson has been clear that it is also for general purpose programming (which is what I use it for). Many Julians are working to improve Julia for places that hadn't yet gotten as much attention (such as database access). I think in a couple of years, the canard of it being a "niche" language will be laid to rest.

> Julia is a great language, but it is still focused on the numerical computing world and is not "1.0"

Word on the street is that Julia is supposed to get a 1.0 announcement at JuliaCon, which started today.

Unfortunately 1.0 is delayed for a couple of months. 0.6 was released yesterday though, which already includes many of the features that were originally scheduled for 1.0.

Reply on news.ycombinator.com