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

111–120 of 309 posts

Re: Julia adoption keeps climbing

#111

Post by cricci16 »

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…

"A more correct but less sexy slogan for Julia is that it has the best performance/expressiveness tradeoff you have ever seen."

This I almost fully agree

Re: Julia adoption keeps climbing

#112

Post by jpfr »

awefasdfasdf wrote: post #95
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…

Small aside. Do you use the beamer package for your slides?

Yes. Beamer LaTeX with the Metropolis theme and Fira Sans as the main font.

Re: Julia adoption keeps climbing

#113

Post by melling »

superbcarrot wrote: post #4

Julia is a nice language, it's just tough to compete with Python. - The beginner experience in Julia is still much worse than it is in Python. Stuff that should work intuitively sometimes doesn't, and when you get a cryptic error message, it's difficult to find relevant help online. And when you do find help, some of it is out of date because the language has changed over the past few years. - You can squeeze a lot o…

Python used to be tough to compete with Perl.

But then times change... It’s usually the tooling and libraries. Now I don’t want to go back to Perl.

And I’d certainly be willing to give Julia a try.

Re: Julia adoption keeps climbing

#114

Post by oivey »

laichzeit0 wrote: post #109

Is it correct to state that in 5 to 10 years we’ll see Julia as the default for new Data Science projects? (ML and statistical inference). I’m not a biggie on switching tool sets just because something is becoming “hot”. I like to start using something when it’s boring and battle tested, the youngsters can do the bleeding. But it seems like the likely candidate if something is going to displace the Python and R ecosy…

I’m a huge Julia proponent (and before, a huge Python proponent over Matlab), but I would be careful about claiming that Julia will be the coming standard. Python has a crazy amount inertia and excellent projects still in the pipeline.

I think Julia will eventually win because writing your code in one language which isn’t C or FORTRAN is extremely productive and leads to much more composable libraries. The progress that’s been made on, for example, deep learning frameworks is impressive given the lack of massive investment from FAANG. I hope this leads to it dethroning Python, but it might not. If anything will, I think it has the best chance.

I’d suggest you give it a try anyway because its really not a hard language to learn. The ecosystem itself is quite good. The fact that you can write fast code without C extensions leaves you less dependent on the ecosystem, too.

Re: Julia adoption keeps climbing

#115

Post by 0-_-0 »

oefrha wrote: post #56
pansa2 wrote: post #49

Earlier quoted context omitted.

> prototyped in Python, then ported to C++ This need to rewrite, of course, is what Julia is trying to avoid. My workflow is exactly the same, and I’d love to be able to write code in a high-level language like Python and then use that directly instead of having to rewrite. However, in my case the reason for rewriting isn’t just performance, but also to be able to build compiled binaries. Julia aims to be as high-lev…

Nim? I know it has Python-like syntax and aims to be performant, but don’t know much beyond that.

Indeed, the Julia autodiff implementation linked above would look very similar in Nim as well.

Re: Julia adoption keeps climbing

#116

Post by galangalalgol »

mlthoughts2018 wrote: post #58
pansa2 wrote: post #49

Earlier quoted context omitted.

> prototyped in Python, then ported to C++ This need to rewrite, of course, is what Julia is trying to avoid. My workflow is exactly the same, and I’d love to be able to write code in a high-level language like Python and then use that directly instead of having to rewrite. However, in my case the reason for rewriting isn’t just performance, but also to be able to build compiled binaries. Julia aims to be as high-lev…

Cython - in fact I think in 2021 if you want to write a pure C or pure C++ program, Cython is the best way to go, and just disable use of CPython. The “need to rewrite” is actually a sort of advantage with Cython. You only target small pieces of your program to be compiled to C or C++ for optimization, and the rest where runtime is already fast enough or otherwise doesn’t matter, you seamlessly write in plain Python.…

Does compiling with cython decrease the ffi overhead of the calls into native code? My problems with numpy have always been that I have to make a lot of calls on small bits of data and the ffi overhead eats all my performance gains. If I put more logic on the native side and made fewer bigger calls it would be faster, but that often doesn't make sense, or is a slope where putting the logic unto native pulls a data structure over or another related bit of logic until I just have a tiny bit of python left.

Re: Julia adoption keeps climbing

#118

Post by oivey »

salt-licker wrote: post #91

Julia’s type system is not particularly user-friendly. For example, it has both a “String” and a “SubString” type which cannot always be interchanged. Their language design seem to be much more concerned with execution speed than programmer productivity — Python has the balance in the opposite direction, but they’ve been gradually improving performance for years, and this is much easier to improve after the language…

I’ve generally found they can be interchanged in the way you would expect as a Python user: duck typing. I have more experience using SubArrays, but I think the underlying machinery in the language is basically the same.

Adding performance after the fact is not easy. This is why most numerical Python projects depend on C extensions rather improvements to the Python runtime. Writing C extensions or jamming your algorithm into the shape of existing C accelerated APIs is often not very time efficient.

Re: Julia adoption keeps climbing

#119

Post by mhd »

D13Fd wrote: post #78
mhd wrote: post #66

Earlier quoted context omitted.

What about "Ada", "Miranda" or "Haskell"? First names, too, albeit ones much less common these days. ("Linda" the language isn't even in that category, popularity-wise, although the source of the name seems to be a weirder story)

I had no idea that “Ada” and “Haskell” were intended to be people names. Those are not super common names. And I had totally forgotten about Miranda, which I agree has the same issue.

I see, that's what I thought. No problem with naming languages after people, but it's easier if it's an homage to a certain person. Common first and last names alone often point to confusing people, and there might be a certain dissonance between the mental images ("I pulled some Julias pigtails in kindergarten, now I have her name on a CV?").

The same problem would probably arise if the last names would be more common, too. "Pascal" and "Turing are probably rare enough ('though "Pascal" was a bit in fashion as a boy's name in Germany when I was young).

Re: Julia adoption keeps climbing

#120

Post by goerz »

enriquto wrote: post #79
spacedome wrote: post #69

Earlier quoted context omitted.

You absolutely can use regular jupyter notebooks for julia! Pluto has some advantages, like being stored as a normal julia file. The julia startup time issues affect both.

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

Sounds like you want jupytext
Post reply on HN