6 ms·
This is a copy from a comment I did in an earlier thread a couple of weeks ago, but I think it still applies: I really like Julia. I'm currently playing around
by terhechte 13y ago
This is a copy from a comment I did in an earlier thread a couple of weeks ago, but I think it still applies:
I really like Julia. I'm currently playing around with it whenever I find some spare time. I don't see it as a competitor to R, I think it could well be something along the lines of Python or Go.
It is LLVM based, and already really fast even though it is still a 0.2 and the JIT seems to have a lot of room for optimisation.
Whats more, it seems to offer just the right blend of language features: - Easily include C libraries via a simple ffi [1] - It is homoiconic like Lisp and thus allows for fantastic macro facilities [2]
- It has solid parallel programming support via a Coroutines implementation (Tasks) (similar to Goroutines as far as I can tell)
- It is a non-pure functional language
- In contrast to Go it has generics, so functional constructs like map, apply, drop, reduce, fold, partition & friends are already in there (or can easily be implemented) [3]
- It has optional types, so that you can assign types and the compiler will check for it and mark errors and will be able to create optimised code, but you don't have to [4]
- Running external programs is a joy [5] (Example: a=readall(`echo hello`))
The community seems to be very alive. There's a simple web framework called "Morsel" and I've recently set it up against a couple of contenders from the web framework benchmark (cpoll-cppsp, phreeze, and some others), and even though it is still a version 0.2, the performance for the json serialization benchmark would be pretty close to Scalatra (I yet have to publish these numbers, will do so soon).
I really hope that Julia will grow, as I love the choices that went into the design of the language, and it would be a shame if it would be only a replacement for R instead of something much bigger, as it is such a nice language.
(original: https://news.ycombinator.com/item?id=6172751 https://news.ycombinator.com/item?id=6172751)
[1] http://docs.julialang.org/en/latest/manual/calling-c-and-fortran-code/ http://docs.julialang.org/en/latest/manual/calling-c-and-for...
[2] http://docs.julialang.org/en/latest/manual/metaprogramming/ http://docs.julialang.org/en/latest/manual/metaprogramming/
[3] http://docs.julialang.org/en/latest/stdlib/base/#general-collections http://docs.julialang.org/en/latest/stdlib/base/#general-col...
[4] http://docs.julialang.org/en/latest/manual/types/ http://docs.julialang.org/en/latest/manual/types/
[5] http://docs.julialang.org/en/latest/manual/running-external-programs/ http://docs.julialang.org/en/latest/manual/running-external-...
- deleted 13y ago[deleted]
- ScottBurson 13y agoThere is a lot to like about Julia. It's obviously heavily influenced by Common Lisp. I see offhand only one thing I really don't like: they are using object semantics rather than value semantics for arrays. So for example: A = [0, 1, 2, 3] B = A A[1] = 2 // now B[1] == 2 Their manual section on arrays says this: In Julia, all arguments to functions are passed by reference. Some technical computing languages pass arrays by value, and this is convenient in many cases. In Julia, modifications made to input arrays within a function will be visible in the parent function. but as the above example shows, it's really the semantics of assignment we're talking about here, not just that of function calls. I believe that value semantics is easier to understand and less bug-prone, particularly for nonexpert programmers. It can also be implemented well enough that the small efficiency cost is worth paying in most cases. For one take on how to do this, see my my FSet functional collections library for Common Lisp[0]. For another, see the Clojure collection types. [0] http://common-lisp.net/project/fset http://common-lisp.net/project/fset
- StefanKarpinski 13y agoUsing value semantics for arrays is lovely in concept but ends up being really annoying and impractical for writing really high-performance array code. This is one of the most common complaints of library authors attempting to write fast, efficient code in Matlab and is one of the many reasons why one ends up having to write all performance-critical code in C using Matlab data structures. Clojure is reputed to get remarkable performance on a broad variety of data structures, but I've had a hard time finding benchmarks comparing Clojure's purely functional arrays with normal linearly indexed arrays – if you have some references to such comparisons, I'd love to see them. In my experience, nothing beats a plain old linearly indexed, mutable array when that's what you need. Making that basic structure unavailable in a language intended for high-performance numerical computing strikes me as utterly perverse.
- cgag 13y ago