This isn't C. The expectations have changed thanks to scripting languages. If I'm supposed to use this promising language to do calculations and manipulate data, I'd expect to be able to natively handle large numbers without overflowing.
Beacause it would make writing fast code inconvinient, it's a tradeoff, a right choice clearly imo. How often do you need BigInts?
I try to use Julia instead of Python now if I don't need specific libs, it definitey feels like a nicer language to me (i.e. I can get stuff done faster).
Julia supports arbitrary precision arithmetic just fine, but you need to explicitly use it. Overflow checks don't matter in Python or Ruby where everything is relatively slow.
I don't think many here argue that Julia doesn't support it. In fact it would be rather disastrous if it didn't, because it wouldn't make for a very nice scientific language if the biggest int value was 2^64-1.
The question is why aren't large numbers the default, or why doesn't it do automatic up and down conversion and so on.
> because it wouldn't make for a very nice scientific language
Scientific languages generally don't use aribitrary precision arithmetic. Examples: MATLAB, scipy/numpy/pandas. The reason is that they're optimized for the key use case of large linear algebra calculations. Making arbitrary precision the default would require an overflow or type/tag test in the inner loop dramatically reducing performance. The goal of these languages is to operate at near peak cpu bandwidth.
When wide ranging precision is needed floats are used despite their flaws, because again, the performance matters so much. FEM, CFD and similar engineering calculations can effectively use as much computation as you have hardware and patience for. Machine Learning will too if you're dataset is larger than trivial.
The Julia folks know what they're doing and it's what the community they're targeting expects.
My point wasn't that it can't be done. My point was about usability and what programmers have come to expect from a modern language. I understand that things get trickier when trying to implement arbitrary-precision arithmetic while keeping performance high.
My guess is that it would lead to at least 10x slowdown in very maths heavy code. So, considering that the main goal of Julia was performance, it doesn't make any sense. And you can easily convert to arbitrary precision with big(1234).
> Do you have an example of a language with arbitrary-precision overflow by default and comparable performance?
No, but that also means Julia isn't much special then either right?
Maybe it is just me but Julia positions itself as a better Python not just a better C, in that position, can you really blame people if they misunderstand and expect same "high level" behavior from it?
>No, but that also means Julia isn't much special then either right?
That's a really dumb conclusion. It's special in other things it offers (from a better Matlab like language with crazy ass speed to homoiconicy and great FFI). Who said it's only special if it fulfils some specific rainbow-unicorn pipe dream?
It also doesn't read the programmer's thought -- so not special in that regard either.
>Maybe it is just me but Julia positions itself as a better Python not just a better C, in that position, can you really blame people if they misunderstand and expect same "high level" behavior from it?
Lots of people also find Go a "better Python", and Go is like assembly compared to Julia...
Better Python in the sense of Python for scientific computing: eg Pandas et all. They aren't targeting all the use cases of Python (for example, I doubt anyone would suggest writing a monit style tool in Julia).
(defun double (x)
(+ x x)) ; BigInts (or floats, for that matter)
(defun double (x)
(declare (type fixnum x))
(+ x x)) ; will emit an error if X is more than a long
(defun double (x)
(declare (type fixnum x)
(optimize speed (safety 0)))
(the fixnum (+ x x))) ; trusts that everything is a long - basically like C
HN goes through phases, which I rather like. This way, we get semi-in-depth coverage of topics serially instead of always uniformly dividing our attention among all interesting projects at the same time.
Nimrod's turn is coming soon. And it is well-deserving. It has already had some pre-HN-darling attention here, which is what brought it to my attention. I'm very intrigued by it. http://nimrod-lang.org/
I don't really see the problem with this. A lot of the languages you mention have been slowly and sustainably building support, even when they aren't on the front page of HN.
It makes sense. We hear about a language, take an initially skeptical approach to it, research it, try it out, and report our findings to others we think might be interested (i.e. HN).
I've been struggling with building a C++ library for astrodynamics simulations (anything involving the motion of objects in space) within my research group for the last four year. The biggest problem is that for our applications, performance-wise a lot of high-level languages just don't cut it (particularly MATLAB, which is pushed down our throat from freshman year onwards). After some deliberation (and before Python really caught my eye) I opted for C++. That unfortunately brings with it an incredibly steep learning curve for new students who typically aren't interested in programming, but just want to get to the fun space mission analysis stuff. As a result, the project has grown a lot, but interest is waning. Julia seems like the ideal blend between high-level and high-performance.
As a general question, is Julia Studio the best way to go about setting up a workflow? Or should I go with something like a Julia plugin for Sublime Text (which I believe exists). Or are there any other tools out there that make Julia dev straightforward?
Regarding workflow, the best option is IJulia (https://github.com/JuliaLang/IJulia.jl) which has nice integration with plotting and useful things like LaTeX. Vi and Emacs are well-supported, and I know the Sublime tools have gotten a lot of attention from several people.
That JPL Ephemeris library has given me an idea. I think I might try porting over the NAIF Spice [1] toolkit to Julia. It has MATLAB, IDL, C and FORTRAN ports so I think Julia would fit right in there.
I just use Sublime Text and often copy/paste or include("code.jl") to REPL. I use Eclipse for Java development, but I just don't see a lot of added value for a Julia IDE.
I'm becoming increasingly convinced that Julia is the future of technical computing. We've just started pulling together a BioJulia team - if anyone is interested drop an email (in profile).
Honestly I'm convinced it's a lot more generally applicable than scientific computing. Much of heavy lifting I had to do in C, I can now do in Julia with nearly the same speed and efficiency. Plus, for a lot of the problems I would have chosen Python, Ruby, or even Clojure for, I could really see myself using Julia now.
Eh, in the case of Closure pervasive immutability, I don't want to write imperative code anymore. I am sure you could write in a functional style in Julia but all the code I have seen seems to rely pretty heavily on explicit stateful loops. At that seems to be a design choice not just for speed but, from what I have read elsewhere, to be familiar to Fortran and Matlab people, seems like a bad trade off to me.
I just was answering the case for the advantage of Clojure over Julia as a general purpose language. And pervasive immutability is an advantage in that case. I agree Julia needs mutable arrays, I think for the domain it is targeting mutable arrays are a must but that should not mean that it needs big old imperative loops absolutely everywhere either.
Imperative and mutable isn't inherently wrong, even in a general purpose language like Julia.
In Clojure it's hard to write imperative code, which was one of the reasons I've left. Sometimes, imperative programming is the best way to code something. Sometimes it's best to do it in a functional way. Julia can do both.
The same is true for mutability. I understand the advantages of immutability but I think it's overhyped. Besides the obvious advantage of mutability - performance - it sometimes makes for more readable and shorter code. And what if you have some complex nested state and need to change a small part of it?
BTW - what do you mean by functional programming exactly, how does it differ from imperative programming in your view?
I also really like Clojure (we use it exclusively at work) especially thanks to its referential transparency. But I don't think I'll ever want to exclusively write in a Clojure style. Sometimes I prefer imperative stateful algorithms.
I can see Julia replacing Go for a lot of people, specifically those who came from a Python or Ruby background and are using Go for the kind of things more typically written in those languages. I bet Julia will shine in this problem space.
Yes, we've been slammed. We are shrinking the timeout and bring up more servers. But our capacity is not unlimited. Folks might have to come back later.
Julia's standard library includes a host of mathematical functions, in addition to the standard operators. Complex numbers are also supported, using the built-in im unit:
round(pi)
lcm(54, 392, 232) # least common multiple
sqrt(square(100))
e^(pi * im)
log(e ^ 2) + log10(100)
When you're ready, type "next" to continue
julia> round(pi)
no method round(MathConst{:π},)
To give some context, several common math constants are use the MathConst type to provide multi-precision constants. This allows e.g. a*pi to be extremely accurate if a is, e.g. a BigInt.
round(x) only works for a few specialised types of x. help(round) tells you that it will return the same type then. Of course for a type of MathConst{:π}, that won’t work. For generic types, you need to at least specify the number of digits (round(pi, 3)). (See also: methods(round))
Julia appears to be a perfect fit for much of what I do at work. I tried it, got very excited, and then facepalmed earlier today. Let's define two functions in the REPL:
function foo()
return 42
end
function bar()
return foo()
end
Evaluating bar() gives 42, just as one would expect.
Now let's redefine foo():
function foo()
return 69
end
Evaluating bar() still gives 42!
Not getting something so basic correct tells me to avoid the whole thing for fear of getting subtly screwed by some other oversight. Actually, oversight isn't the right word, since broken automatic compilation has been a known problem for two years: https://github.com/JuliaLang/julia/issues/265.
Not getting something so basic correct tells me to avoid the whole thing for fear of getting subtly screwed by some other oversight.
No one denies that this is a problem, and it will be fixed. But I disagree that it represents a fundamental flaw. For iterative development, it is a minor inconvenience, so other priorities have taken precedence. If you are redefining functions in this way in tested code, there may be bigger problems to worry about.
The Julia developers have paid fastidious attention to correctness (to the point of making a pilgrimage to visit Kahan early on). The type system is well thought-out and nice to use. Spurious crashes are almost nonexistent (and fixed within hours, without fail). The foundation is solid, but it's still a work in progress, and it will take some time to shake these sorts of features out.
I was cheering out loud when I first downloaded Julia and started working with it. The type system, multiple dispatch, so much win! I'm working on ionospheric ray tracing at my day job and would love to use Julia.
But when I can write a nine-line example that produces incorrect output—no thanks. Especially when one of the lead developers (see the linked thread) states that supporting function redefinition isn't needed for v1.0. Clearly these people are working under a very different set of priorities than me.
"The foundation is solid"—I do not think it means what you think it means.
I think everyone involved with Julia agrees that this is something that eventually needs to work, although it is not as big of a deal if you are loading code from disk, as opposed to writing functions at the REPL. See https://github.com/JuliaLang/julia/issues/265.
That's the issues thread that I included in my initial post. Quoting from it: "When you redefine a method, the resulting behavior is undefined."
And these people expect to be taken seriously? Sell crazy someplace else, we're all stocked up here. The honest approach would be to forbid redefining functions.
This issue was brought to my attention by pals who had investigated Julia and rejected it for this very reason. No way I'll use it for anything. And that will be my recommendation to anyone who asks me about it.
Nope, I should buy them beers since Julia is wholly unsuited for what I'm trying to do, which is interactive network performance analysis and interactive development of ionospheric ray-tracing code.
It's funny: I've forwarded this issue to several pals with experience in language & compiler design, and to a man they were dismayed that something so basic was going unfixed or was even broken in the first place.
I'm running Emacs with a split window for development. R runs in the bottom window, and the source file I'm editing is in the top. This lets me send code to R for evaluation and supports an incremental style of development. I'll slowly build up functions, and this sometimes requires editing functions that my current function uses. This style of development is typical for people using R, Matlab, Lisp, or any language featuring a REPL. But you can't do it in Julia.
Julia needs to support this style of development if it's to garner support from people using these languages. Full stop.
And the fact that Julia doesn't support updating functions makes me think that something is very broken down in the core of the language. The tone of the GitHub thread is: "We don't know how to fix this." Scary!
> I'm running Emacs with a split window for development. R runs in the bottom window, and the source file I'm editing is in the top. This lets me send code to R for evaluation and supports an incremental style of development. I'll slowly build up functions, and this sometimes requires editing functions that my current function uses. This style of development is typical for people using R, Matlab, Lisp, or any language featuring a REPL. But you can't do it in Julia.
This is what everyone does in Julia too, with Emacs, IJulia, and others. Here is how to do it: put "module X" at the beginning of your file, and an extra "end" as the last line. Each time you send the file to Julia, the module is recompiled, and inter-dependent functions are updated to the latest version. Problem solved. This is mentioned (in a slightly different context) in the FAQ:
> But I admit it's not immediately obvious, and we should probably put it front-and-center somewhere.
No, the authors should fix automatic recompilation. It's difficult for me to imagine how this bug even exists. The fact that it does coupled with the excuses and blaming the messenger surrounding it tells me that the authors don't know what they're doing and that I should steer clear for fear of running into similar flaws.
If you can't adapt your workflow to work around the current shortcomings of Julia as a language, it's perfectly reasonable to complain about that. What is frustrating people in this thread is that you are implying that because automatic recompilation of dependent functions isn't implemented (in a language that is not yet production quality nor represented as such), the authors must be mentally deficient. You are receiving a vocal response not because we want to sweep Julia's shortcomings under the rug, but because we know that Julia's authors are quite intelligent people and we disagree that the absence of this feature at this time reflects poorly on them. I hope that, once Julia reaches v1.0 and has proper recompilation of dependent functions, you'll give it another shot.
I'd suggest that the authors consider how this missing feature reflects on their efforts when people are forming first impressions. I've made my opinion clear, and the developer pals that I brought into the loop were, without exception, similarly aghast.
I'm reminded of how some Python devotees are unable to see how the v2.7/v3.x split turns of newcomers. The impression given is that the community can't make up its mind on which way to go and that the best approach is to avoid the language all together.
You can also try Julia in your browser here: https://cloud.sagemath.com
However, you have to (1) make a free account, (2) create a project, (3) open project, click on "+New", click Terminal, (4) type "julia". If you create a .jl file instead of a Terminal (at +New), you'll have proper Julia syntax highlighting and indentation; you can then run that file from the terminal... (Disclaimer: I'm the founder of SageMathCloud.)
Julia is very fast, 0.12 second, 0.60 second for sbcl (lisp)
julia>function haz(n)
s = 0
for i in 1:n
if i % 2 == 0
s = s+1
else
s = s-1
end
end
s
end
haz (generic function with 1 method)
julia> @elapsed haz(10^8)
0.12459633
Compare with lisp sbcl on the same machine:
(defun haz(n)
(let ((s 0))
(declare (optimize (speed 3) (safety 0))
(fixnum n s))
(loop for i fixnum from 1 upto n
do (if (zerop (mod n 2)) (incf n) (decf n))
finally (return s))))
A lot of the comments I see about Julia (and other trendy high level languages) are of the following form:
"I can do things I needed C to do before, and almost as fast"
which leads me personally to ask,
If you could do this in C before, and faster, then why are you switching?
Most people will say "because C is bad/difficult/clumsy for doing X"
which leads me to say,
why are you using C to do X?
I sincerely believe (as a computational scientist) that a combination of a high-level language for real-time interactive exploration and prototyping with a fast language like C for doing the actual gruntwork, is the best.
Attempts to combine the best of C (speed) with the best of scripting languages (easy to do things fast without having to pay attention to what you are doing) in my opinion end up merely joining the worst of both worlds rather than the best of both worlds.
Besides isn't programming about being specific? Do you really want to code stuff without having to worry about the details?
> I sincerely believe (as a computational scientist) that a combination of a high-level language for real-time interactive exploration and prototyping with a fast language like C for doing the actual gruntwork, is the best.
Converting to C can take a LOT of time, and is an order of magnitude less enjoyable than Julia. What about maintaining the code, making improvements, integrating with other code? And what if the prototyping needs too be fast too? It can become a massive pain in the ass. Why should I undergo that if I can just use Julia?
> Attempts to combine the best of C (speed) with the best of scripting languages (easy to do things fast without having to pay attention to what you are doing) in my opinion end up merely joining the worst of both worlds rather than the best of both worlds.
I've used both Julia and C and I think it's the exact opposite, it combines the best of both worlds.
You can see it as an alternative to Matlab/R (sorta)/numpy not C.
People only ever used C when speed was crucial and depending on what you were comfortable in or what you had learned maybe Fortran for speed instead of C.
Julia is meant for scientific computing with some nice features. As I see it it is similar enought to Matlab to be easily learned by those who use Matlab but has enough goodies that it can be a viable alternative.
Programming isn't about being specific it is about accomplishing a task and many times yes you don't want to have to worry about the details as long as it works the way it should.
I agree with what you say. More and more though as I get on in my career as a scientist I realize though that the details turn out to matter, sometimes a great deal.
Anyway I'm all in favour of an open, fast MATLAB alternative
>which leads me to say, why are you using C to do X?
Because they know C, it's fast and it has lots of libs available. They might also dislike Java or CL.
Not every engineering decision is perfect, lots of factors play in.
>Attempts to combine the best of C (speed) with the best of scripting languages (easy to do things fast without having to pay attention to what you are doing) in my opinion end up merely joining the worst of both worlds rather than the best of both worlds.
The "pay attention" things is to needless complexity (memory management etc). They only reason we put up with those things was to get speed. If we can get adequate speed without those, nobody cares about them.
>Besides isn't programming about being specific? Do you really want to code stuff without having to worry about the details?
No, programming is about getting results. Nobody cares about the details in the level of programming language minutuae.
We care about the "effort put in" and "quality/speed of results coming out" ratio.
oh awesome resource, thanks for the link! (looks down from overuse right now but still, cool!)
julia++, i started playing with it this weekend and i'm super pleased. i concur with another comment in this discussion that this is what i wish python had been evolving into. it gets me wondering if python is maybe being left behind compared to other dynamic languages or if it's just fad-ism at work (or me just learning more about languages and features).
Our Julia REPL servers been slammed. We are shrinking the timeout and bring up more servers. But our capacity is not unlimited. Folks might have to come back later. Sorry about that.
