Try Julia | Hacker News Reader

Try Julia

forio.com

108 pointsbsg75103 comments

Fun with Julia:

    julia> 3 ** 60
    syntax: use ^ instead of **

    julia> 3 ^ 60
    -3535985420588157519

    julia> factorial(45)
    -8797348664486920192

    julia> factorial(75)
    0

    julia> 5 * 5555555555555555555
    -9115710369641325457

    julia> 5 * 55555555555555555555
    syntax: invalid numeric constant 55555555555555555555

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.

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.

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.

Do you have an example of a language with arbitrary-precision overflow by default and comparable performance?

> 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?

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).

>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...

Common Lisp with SBCL:

   (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

Every conformant non-toy Common Lisp implementation?

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).

>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.

Scientific programmers don't expect a behavior different than Julia's from a modern language.

>I understand that things get trickier when trying to implement arbitrary-precision arithmetic while keeping performance high.

It's not merely "trickier". It's impossible to be fast enough.

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.

Julia uses machine arithmetic for integer computations. The alternatives have serious drawbacks in technical computing, see

http://docs.julialang.org/en/latest/manual/faq/#why-does-jul...

Try wrapping each of these in BigInt. Example: factorial(BigInt(1000))

Julia defaults to what is fast on your machine. If you want to use BigInt you can do so but it doesn't do so by default.

You can also use 128bit integers in Julia. Example: rand(Int128, 10)

BTW, the invalid numeric constants thing was fixed

    julia> 55555555555555555555
    55555555555555555555

    julia> typeof(55555555555555555555)
    Int128

    julia> typeof(5555555555555555555555555555555555555555)
    BigInt (constructor with 7 methods)

Yes, Julia doesn't auto-convert to BigInt, it's a trade-off between performance and easy-to-useness, but they've definitely made the right decision.

You have to convert to BigInt or BigFloat like this:

   julia> big(3) ^ 60
   42391158275216203514294433201

Why not have them as BigInt and donwconvert to machine sized ints explicitly?

In any case. If you think of it as a nicer C, it works very well. It is a slight disappointment if you think of it as a nicer Python.

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).

Am I crazy for feeling like Julia is the new HN darling like clojure, go, ruby, lisp, and scala before it?

It seems like in the last week it just started popping up on HN every couple days.

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.

I hope you're right.

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 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.

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'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.

Not directly related to performance, but you might be interested in this: https://github.com/helgee/JPLEphemeris.jl

Very cool, thanks for the tips!

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.

[1] http://naif.jpl.nasa.gov/naif/

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.

It's really easy to try Julia by just downloading it: http://julialang.org/downloads/.

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).

Any reasoning behind such a generically bold statement?

> Any reasoning behind such a generically bold statement?

If and when they're right, they can smugly point out how forward thinking they were.

- Good performance

- Lisp-like macros and other metaprogramming facilities

- It's a general purpose language

- Multiple dispatch

- Designed for parallelism and distributed computation

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.

Same here. In my so-far limited experience, it feels like the upgrade to Python 2 that I wish Python 3 had been.

+1 Besides libs and ecosystem in general, I don't see any advantage Python / Ruby / Clojure have over Julia.

And libs/tooling naturally come along with active use, which I think Julia is going to start seeing real soon. At least from me!

I agree, the libs ecosystem is growing at an amazing pace (partly because macros make it easy to create wrappers around C, Python or Java libs).

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.

Removing loops or mutability from Julia would be a terrible decision. There's nothing inherently wrong with mutability or imperative programming.

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.

The Server version of Ubuntu or the 12.04 version does not have the add-apt-repository command. How can i add a PPA to the server without this command? Answer in http://askubuntu.com/questions/38021/how-to-add-a-ppa-on-a-s...

There are several options, I chose the one with sudo gedit /etc/apt/sources.list and

1514 sudo gedit /etc/apt/sources.list 1515 sudo apt-get update #not needed 1516 sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 3D3D3ACC 1517 sudo apt-get update 1518 sudo apt-get install julia (there are broken dependencies) 1519 sudo apt-get install libopenblas-base 1520 sudo apt-get update 1521 sudo apt-get install libopenblas-base 1522 sudo apt-get install libatlas-base-dev 1523 sudo apt-get install libopenblas-base 1524 sudo apt-get install julia 1525 julia 1526 history | tail 1527 history | tail -n 20

Not seeing a prompt. It might be because of the internal "POST http://forio.com/julia/repl/sessions 503 (Service Unavailable)" error?

Probably got "slashdotted".

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.

OK, we've added more servers of larger instance types! You should be good now.

Is round(x) broken?

    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{:π},)

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))

Weird that they have round(pi) as an example.

It may have worked at some point. The language evolves pretty quickly at the moment.

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.

This issue was also reported at https://github.com/JuliaLang/julia/issues/5561

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.

That annoys me too but it isn't a big deal, it'll probably get fixed in the future.

You change a function, and that change doesn't get reflected in upstream calls—this isn't a big deal? Are you kidding me?

I don't see it as a big deal. You do, so my advice is to wait for 1.0.

Except that the linked thread on Github mentions that supporting the redefinition of functions isn't a v1.0 issue.

It's assigned to the 1.0 mileston.

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.

>This issue was brought to my attention by pals who had investigated Julia and rejected it for this very reason.

You should pick different advisors.

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.

That's only an issue for quick iterating tests in the REPL. The REPL is not a priority.

You're not supposed to rename functions in your code -- are you kidding me you're hang up on this?

No kidding—this is a show-stopper for me.

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!

Julia certainly allows you to redefine functions, it simply doesn't trigger automatic upstream recompilation.

https://gist.github.com/anonymous/8656066

> 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:

http://docs.julialang.org/en/release-0.2/manual/faq/#how-can...

But I admit it's not immediately obvious, and we should probably put it front-and-center somewhere.

> 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.

Good luck!

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.

>I'd suggest that the authors consider how this missing feature reflects on their efforts when people are forming first impressions.

I'd suggest you slow down on the entitlement.

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.

>Clearly these people are working under a very different set of priorities than me.

Yes, they are pragmatists.

Plus they know that the language is the first priority, not the REPL.

(to the point of making a pilgrimage to visit Kahan early on)

What does that mean?

"The Father of Floating Point" http://en.wikipedia.org/wiki/William_Kahan

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.)

You could have had more users if your url was:

https://cloud.sagemath.com/new/jl ;-)

Can julia yet do the equivalent of the following Octave code:

proportion_value = x ./ sum(x)

The blocker for me with julia is translating my vectorized way of thinking into loops. I know the loops are optimized, but yuck.

Yes, this works in Julia without any changes.

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?

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

> 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.

>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.

koding.com is another way to get an interactive REPL online: https://koding.com/Julia

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).

a big white page is not really the best introduction ever (or am i missing the point/humor?)

It was working, until I submitted it here. Maybe too many people Trying Julia.

Yup, we've been properly slashdotted. Attempting to bring up more servers and shrinking session timeout. But...

All fixed now. We have added more servers of larger instance types to support the Julia RELP.

Doesn't seem to work - would love to find a great resource on Julia

I've found the docs[1] to be extremely easy to follow, as a nice blend between a tutorial and a spec.

[1]: http://docs.julialang.org/en/latest/manual/

Try again, please. We spun up more and larger instances to handle the interest from HN.

Adblock on Chrome is blocking the command prompt by default. At least on my system...

After typing next about 20 times without seeing anything interesting, I quit.

Everything returns:

   Undefined
   500

Is this broken?

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.

Fixed now. We have added more servers of larger instance types. It should work great now.

The pi constant didn't work for me

no method round(MathConst{:π},)

Reply on news.ycombinator.com