Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Julia adoption keeps climbing

hpcwire.com

Post reply on HN
Print view View original

231–240 of 309 posts

Re: Julia adoption keeps climbing

#231

Post by [deleted] »

watwatinthewat wrote: post #110
chalst wrote: post #87

Earlier quoted context omitted.

There are warts with the beginner experience with Python, principally the awful situation with packaging. If you care about performance in code that mixes together several packages in nontrivial ways, Julia is way better than Python. There's a far broader range of libraries in Python than Julia, but none of them are going to prevent adoption of Julia when its performance advantages are crucial, because of the excelle…

I'm not sure the package problem is really a problem for beginners. Just within the last year firsthand I've seen people in undergraduate classes, in graduate classes, and at work try Python the first time, and the default install of Anaconda worked for them in every case. The classes were taught by different professors, and they all suggested Anaconda independently and were not Python programmers. It is overkill/bru…

[deleted]

Re: Julia adoption keeps climbing

#232

Post by StefanKarpinski »

veddox wrote: post #219
StefanKarpinski wrote: post #183

Earlier quoted context omitted.

Julia absolutely is a general purpose language and has been from the beginning. However, there are plenty of languages that are fine for building websites, whereas there are no other languages with the combination of speed and usability that Julia offers in technical computing. It's a lovely language for doing all kinds of work and I personally mostly use it for non-technical computing these days — specifically to im…

Oh, hello, interesting to see you here :D Perhaps you ought to say that you're a co-creator of the language...

True, I'm obviously biased, but at least I can attest to the intention: Julia has always been intended for general purpose computing with the additional (and very challenging requirement) that it be a general purpose language that's also excellent at technical computing, which turns out to be a remarkably hard additional requirement.

Re: Julia adoption keeps climbing

#233

Post by [deleted] »

cricci16 wrote: post #8

In my modest experience the perfect Julia slogan would be: "fast as C, easy as python, but NEVER the two together" All the sentences: "When you’re writing various algorithms, you don’t necessarily want to think about whether you’re on a GPU, or whether you’re on a distributed computer. You don’t necessarily want to think about how you’ve implemented the specific data structure. What you want to do is talk about what…

[deleted]

Re: Julia adoption keeps climbing

#234

Post by 6gvONxR4sf7o »

jakobnissen wrote: post #77
cricci16 wrote: post #8

In my modest experience the perfect Julia slogan would be: "fast as C, easy as python, but NEVER the two together" All the sentences: "When you’re writing various algorithms, you don’t necessarily want to think about whether you’re on a GPU, or whether you’re on a distributed computer. You don’t necessarily want to think about how you’ve implemented the specific data structure. What you want to do is talk about what…

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 that kind of naively written function be closer to C or Python?

Re: Julia adoption keeps climbing

#235

Post by DNF2 »

ajankelo wrote: post #61

Julia is fantastic with a great community. The one issue I have though is the use of greek symbols, while great for those formally trained, may have a negative impact on wider adoption for deep learning.

Python also allows Greek letters.

There are no Greek letters forced upon you, they aren't even used in Base, and barely if at all, in the stdlibs.

It is a feature for you to use, if you want. (And they dramatically improve code readability in heavily mathematical code.)

Re: Julia adoption keeps climbing

#236

Post by dunefox »

causalmodels wrote: post #230

Can anyone recommend some good resources to learn Julia? I am hoping there is something akin to the Rust Book [1] since watching youtube videos is too slow and the exercism option listed on the website is too cumbersome. [1] https://doc.rust-lang.org/book/

This might be helpful: https://benlauwens.github.io/ThinkJulia.jl/latest/book.html

Re: Julia adoption keeps climbing

#237

Post by StefanKarpinski »

legerdemain wrote: post #217
jpfr wrote: 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…

I'm using Julia (because of the hype) to prototype out some numerical optimization stuff. There is a million functions for reshaping multidimensional arrays. The syntax is uncannily like Matlab: retrieving the last element of an array with `[end]`, indexing into a collection with an array of booleans, element-wise versions of operators prepended with dot, etc. However, I keep running into niggling corner cases that k…

As sibling posts have pointed out, you can do all of those things:

1. You can trivially write a `getproperty` method for a tuple. It is considered to be type piracy and thus runs the risk of colliding with someone else's definition, but the language absolutely lets you do it.

2. You can broadcast over the fields of a `NamedTuple` by defining appropriate methods. Again, it's type piracy, so take that into consideration, but the language lets you do this easily as well.

3. The https://github.com/JuliaArrays/PaddedViews.jl package implements exactly what you're saying Julia won't let you do.

If anything, Julia errs on the side of allowing you to do too many things! There are very few things the language really won't let you do.

Re: Julia adoption keeps climbing

#238

Post by tpoacher »

oxinabox wrote: post #195
StefanKarpinski wrote: post #144

Earlier quoted context omitted.

This "Julia marketing conspiracy theory" that many people on HN seem to believe is so bizarre. What big tech company do you think is behind this incredible, shrewd and presumably well-funded marketing campaign? Julia is the only new major programming language of the last decade that doesn't have a major tech giant backing it. Adoption and development are pretty much entirely grass roots. If you see a lot of enthusias…

Trying to think of others. Kotlin was 2011, and is JetBrains. JetBrain's is 1500 people. So big, but not giant. Rust is 2013 Mozilla is only 750 people So perhaps Major Tech Giant is over-stating it. But definately most other things in the last decade have a major established tech firm backing it. Julia has basically nothing. Starting out as a MIT project, and then Julia Computing is a tiny startup; with like what 50…

Hi Lyndon. Yes, but that's exactly what I meant! I think my phrasing was off. For a company of that size, I've seen very good activity promoting the julia brand, both officially and through word-of-mouth networks. (your own Cambridge meetups notwithstanding). Therefore, I think much of the hype is at least partly that, rather than just the technical merits of the language (which I agree it has plenty). I don't remember this kind of 'buzz' before v1. Back then it was just people who saw promise in its features. Now people seem to be promoting it quite actively.

I've seen a shift in the winds, that's all I'm saying. I wasn't mean to come off so negative. (certainly not as negative as Chris took it!)

Re: Julia adoption keeps climbing

#239

Post by antpls »

> "Because Julia’s compiler is different from the interpreters used for languages like Python or R, you may find that Julia’s performance is unintuitive at first. If you find that something is slow, we highly recommend reading through the Performance Tips section before trying anything else. Once you understand how Julia works, it’s easy to write code that’s nearly as fast as C."

If Julia needs a "Performance Tips" section to produce fast code, I might as well use Python.

The "speed" from Julia comes from LLVM, but there is nothing stopping Python to use LLVM as well where it _makes sense_ (which is the case with XLA in TensorFlow, for example).

I see no plus value in learning Julia over existing tools, there is nothing revolutionary or nothing that could alleviate future risks.

Re: Julia adoption keeps climbing

#240

Post by legerdemain »

StefanKarpinski wrote: post #237
legerdemain wrote: post #217

Earlier quoted context omitted.

I'm using Julia (because of the hype) to prototype out some numerical optimization stuff. There is a million functions for reshaping multidimensional arrays. The syntax is uncannily like Matlab: retrieving the last element of an array with `[end]`, indexing into a collection with an array of booleans, element-wise versions of operators prepended with dot, etc. However, I keep running into niggling corner cases that k…

As sibling posts have pointed out, you can do all of those things: 1. You can trivially write a `getproperty` method for a tuple. It is considered to be type piracy and thus runs the risk of colliding with someone else's definition, but the language absolutely lets you do it. 2. You can broadcast over the fields of a `NamedTuple` by defining appropriate methods. Again, it's type piracy, so take that into consideratio…

I meant literally this:

  julia> (x = 1, y = 2) .+ (x = 1, y = 2)

  ERROR: ArgumentError: broadcasting over dictionaries and `NamedTuple`s is reserved
Post reply on HN