Live data from Hacker News

Julia adoption keeps climbing

hpcwire.com

291–300 of 309 posts

Re: Julia adoption keeps climbing

#291
post #281
post #166

Earlier quoted context omitted.

I deeply loath R for its terrible type idiosyncracies, syntax, and slowness. However, even I must admit that it is incredibly good at what it was meant to do - analyse and display data. (And yes, the tidyverse is a huge improvement of the syntax, although it's telling that they basically reinvented the language to do so.) As an ecological modeller, I create my actual simulation models in Julia, because it is a much,…

I don't understand how people can loath R. If you take a functional approach, especially using pipes, dplyr and a split, apply, combine style, it is quite beautiful. Much nicer than trying to, say, divide a time period by an integer in Go.

> If you take a functional approach, especially using pipes, dplyr and a split, apply, combine style, it is quite beautiful

Sure, but what if you don't? Sometimes, this is the right way to do things, other times there are other approaches that are more natural/beautiful. In many cases, a loop with conditionals is much easier to understand.

Re: Julia adoption keeps climbing

#292
post #64

I'm a researcher, doing lots of numerical work both professionally and in hobby projects. While Julia has a lot of technical merits, there are just some superficial, syntax-level design decisions that strongly rub me the wrong way: 1-based indexing (makes interfacing with C code hard), explicit begin/end (verbose & ugly) and column-major indexing (personal preference). I understand that these follow in the footsteps…

Who am I to say what hills are worth dying on? But I don't want you to die at all - in case you're ever compelled to switch, I can't help you with end, but OffsetArrays.jl can help with your indexing woes, and I think there are packages to rotate matrices too (though not certain of that).

Re: Julia adoption keeps climbing

#293

Earlier quoted context omitted.

Underrated comment. Yeah, if you want C-like performance, you have to do some low-level considerations, that is unavoidable at some point. So the "speed of C, convenience of Python" is misleading. However, for many, many small tasks, today's compilers are smart enough that you can express your idea in a high-level language and the generated code will be maximally efficient. The real killer feature of Julia is that, w…

That's still a massive selling point. In python, getting speed can be weird and counterintuitive. In C, a straightforward algorithm can be blazing fast. For example, finding the length of the longest word in a string, you can just iterate through the string keeping track of a few indices. In cases like that, where the obvious simple C function is incredibly faster than the same python, where does Julia fit in? Would…

In that case, it's closer to C in speed, and usually more generic and "easy on the eyes". I don't know much about C, but seem to recall that it doesn't play well with unicode, usually treating text as bytes. Here's an equivalent Julia example:

    function longest_word(st::Union{String, SubString{String}})
        len = 0
        start = 1
        @inbounds for i in 1:ncodeunits(st)
            if codeunit(st, i) == UInt8(' ')
                len = max(len, i - start)
                start = i + 1
            end
        end
        max(len, ncodeunits(st) + 1 - start)
    end

This takes about 8.2 µs for a 8.5 Kb piece of text on my laptop, but that only works on ASCII text and only treats ' ' as whitespace, not e.g. '\n'. For a more generic one, you can do:

    function longest_word(st::Union{String, SubString{String}})
        len = i = 0
        start = 1
        for char in st
            i += 1
            if isspace(char)
                len = max(len, i - start)
                start = i + 1
            end
        end
        max(len, i + 1 - start)
    end
This is 20 µs for the same text, so still only 3 ns per char. The underlying functionality, namely String iteration and the `isspace` function, is also implemented in pure Julia.

Re: Julia adoption keeps climbing

#294

Earlier quoted context omitted.

I don't know. I also don't use pypy much, since python+numba is actually fast enough most of the time, and I always see pypy as a fallback to see if I can squeeze a little bit more performance before running a task.

Does Numba offer significantly faster compile times than Julia's JIT?

No, from my own (relatively limited) experience with Numba, if you enable "@nopython", it's about the same speed as Julia, which is the same speed as C.

The thing is that Numba is only applicable for simple numeric code. Last I checked it didn't even support custom classes. In fact, last I checked it didn't even support Numpy - to support "Numpy" it had to internally re-implement much of Numpy, which really says something bad about its use cases. In contrast, the Julia JIT speeds up the entire language from string processing to set operations.

Edit: To not be misleading: Julia and C (and Numba) have the same speed only in the simple cases you can apply Numba to. In more diverse workloads, C pulls ahead of Julia for various small reasons.

Re: Julia adoption keeps climbing

#295

Earlier quoted context omitted.

> being stored as a normal julia file. Oh, man, this is indeed a major feature. My main point of friction with jupyter notebooks is the stupid json ipynb format. Why can't it be just a regular language file with comments?

> My main point of friction with jupyter notebooks is the stupid json ipynb format. Why can't it be just a regular language file with comments? Have you ever used Jupyter notebooks? They contain code, rendered Markdown, images, plots, video players, widgets, etc. How do you see a "regular language file with comments" supporting this, instead of the "stupid ipynb format"? You can use plain text files with Jupyter, too…

Rmarkdown does this perfectly

Re: Julia adoption keeps climbing

#296
post #281

Earlier quoted context omitted.

I don't understand how people can loath R. If you take a functional approach, especially using pipes, dplyr and a split, apply, combine style, it is quite beautiful. Much nicer than trying to, say, divide a time period by an integer in Go.

I use a lot of R, and like many aspects of it. But the fact that `f(stop("Hi!"))` may or may not throw an error depending on the internals of `f` is a little maddening. (And there are tons of similar issues.)

Isn't that just lazy evaluation?

Re: Julia adoption keeps climbing

#297
post #23

I teach a graduate course in optimization methods for machine learning and engineering [1,2]. Julia is just perfect for teaching numerical algorithms. First, it removes the typical numpy syntax boilerplate. Due to its conciseness, Julia has mostly replaced showing pseudo-code on my slides. It can be just as concise / readable; and on top the students immeditaly get the "real thing" they can plug into Jupyter notebook…

This. Julia's combination of human-readable pseudocode-like code and speed makes it perfect for these applications, and seems to be driving adoption.

Also not seen before degree of code reuse.

Re: Julia adoption keeps climbing

#298
post #201

Earlier quoted context omitted.

>Julia has the focus on scientific and numerical computing, and is overtaking the python/numpy combo in that niche\ I agree. In fact if Julia hasn't overtaken Python in numerical computing by January 2022 I will consider it a huge failure.

Seriously?!? Julia has no hope of overtaking Python in numerical computing by 2032, expecting movement by 2022 is just delusional. Here is a better prediction: by 2022 people using Python for numerical computing who started doing so in the previous year will exceed the number of people who have ever downloaded Julia since it was first released.

No, not seriously. But also seriously. The article is based on % change which is of course ridiculous because the % increase of a small population isn't at all interesting. And GP also has a ridiculous claim. So I'm offering a stake in the ground to determine if Julia is on the track that GP claims. If GP wants to come back and discuss where the stake should be, it will be an interesting conversation.

Re: Julia adoption keeps climbing

#300
I recently decided to port some of my Python analysis code over to Julia since I've been doing a lot of ODE stuff lately. Overall I'm liking it, but I've found a couple things frustrating: 1) the docs and online issues/answers are a bit of a mess, partly because many of the accepted answers are from pre-1.0 days; 2) the error messages I've found are long and not very helpful. It takes much longer to track down a bug in Julia than Python code.
Post reply on HN