61–70 of 242 posts
It has static types and is fast. The libraries for scientific computing are not there yet, but it lends very nicely to mathematical abstraction.
- One-based indexing setting aside whether zero- or one-based indexing is 'better'; R and MATLAB have one-based indexing, so the convention is likely familiar to many in the Julia target audience. still, as the OP says, (relatively) painless interoperability with C and C++ is an advertised Julia feature, both of which use zero-based index (although Fortran is one-based), and that mis-match is a definite obstacle to i…
I did enjoy the article and the linked article that spelled out ways to increase performance with Python. With any environment there are dramatic performance improvements to be had with a little bit of engineering and knowledge.
I've seen a bit of an odd shift towards Julia - People seem to be adopting it in droves from my perspective. That means that the development team is doing something very right. Given some of the people I've heard talking about Julia, I don't think it's going away any time soon.
This kind of feedback is good for the team. If you are going in another direction for the time being, stating why is always helpful. Glad to see a developer here in this thread.
You may be interested in Nim. If you can tolerate working without a REPL, Nim hits essentially all the bullet points you mentioned, from macros to coroutines, multiple dispatch, ability to call c trivially and python easily and so on. It has static types and is fast. The libraries for scientific computing are not there yet, but it lends very nicely to mathematical abstraction.
(Not trolling, genuinely curious).
Earlier quoted context omitted.
One-based indexing is also used in Fortran, which seems to be used in a great deal of numerical computing even today. Additionally, BLAS/LAPACK is an important linear algebra library written in Fortan. I am somewhat confused by your discussion of startup times. Since Julia is a "programming language for technical computing", what scenario are you imagining where startup times would be a significant concern?
No less than Dykstra has weighed in on the numbering of arrays. http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF Having worked with both, I'm inclined to prefer 0 based addressing in most cases. It's slightly less intuitive, but it generally leads to cleaner code.
The last set of programs I wrote in julia had run times of hours to days. A few extra seconds of startup time is well worth the 10x or better improvement over using python for the same tasks. The code was also tighter and easier to understand. A win all around.
Earlier quoted context omitted.
One-based indexing is also used in Fortran, which seems to be used in a great deal of numerical computing even today. Additionally, BLAS/LAPACK is an important linear algebra library written in Fortan. I am somewhat confused by your discussion of startup times. Since Julia is a "programming language for technical computing", what scenario are you imagining where startup times would be a significant concern?
Not just FORTRAN, but R and MATLAB also use one-based indexing. It's also, at least historically, the convention for matrix notation. IMO do whatever attracts more users, as that is what Julia needs most. Without a large community moving from MATLAB, R, and other languages, Julia will never take off.
In most functional languages using list indices are an anti-pattern. Pattern matching and generalized iteration is a much more elegant way to handle most things you would use an index for.
You may be interested in Nim. If you can tolerate working without a REPL, Nim hits essentially all the bullet points you mentioned, from macros to coroutines, multiple dispatch, ability to call c trivially and python easily and so on. It has static types and is fast. The libraries for scientific computing are not there yet, but it lends very nicely to mathematical abstraction.
How does Nim's "trivial" C interop work if Nim is garbage collected and C is not? (Not trolling, genuinely curious).
You can manually allocate memory if you want, and you can also pass pointers, either to manually allocated or gc memory. The gc will not run when c is working, since it is triggered by allocation
- Both Julia Computing and the Julia Lab have grown sizably over the past two years. The Lab now houses ten full-time researchers (up from four last year), with five new students coming online over the summer and fall. We also maintain more active research collaborations with more research groups at MIT and off-campus.
- Julia is a grateful recipient of 12 Google Summer of Code slots this year, compared to 8 for 2015's Julia Summer of Code program (sponsored by the Moore Foundation) and 4 for GSoC 2014.
- JuliaCon grew from 72 attendees in 2014 to 225 in 2015 and we are on track to meet or exceed last year's ticket sales for 2016.
- New packages continue to be registered on the central METADATA repository at roughly the same rate since June 2014. http://pkg.julialang.org/pulse.html
By some measures we are still a relatively small project, but I don't see any serious evidence for the imminent heat death of the Julia universe.
Earlier quoted context omitted.
How does Nim's "trivial" C interop work if Nim is garbage collected and C is not? (Not trolling, genuinely curious).
Nim compiles to c, hence you can just call c functions. All you need is a signature, which can even be generated automatically from a c header. You can manually allocate memory if you want, and you can also pass pointers, either to manually allocated or gc memory. The gc will not run when c is working, since it is triggered by allocation