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

101–110 of 309 posts

Re: Julia adoption keeps climbing

#101

Post by i_am_proteus »

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…

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

Re: Julia adoption keeps climbing

#102

Post by ku-man »

veddox wrote: post #93
qaq wrote: post #34

On what time scale? Julia is really nice lang. but it will take decades for it to put a serious dent in Python. If web side of things matures fast and someone builds a killer framework it might carve out a niche there too.

It's not meant for web, it's meant for scientific computing. And it has already left a mark on that field.

Then Julia should stop describing itself as a general-purpose programming language.

Re: Julia adoption keeps climbing

#103

Post by chalst »

mlthoughts2018 wrote: post #88
szemet wrote: post #74

Earlier quoted context omitted.

> Using extension modules is just a time-tested, highly organized, modular, robust design pattern. I really don't get this. I'am fully on the side that limitations may increase design quality. E.g I accept the argument that Haskell immutability often leads to good design, I also believe the same true for Rust ownership rules (it often forces a design where components have a well defined responsibility: this component…

> “But having a performance boundary between components, why would that help?” It helps precisely so you don’t pay premature abstraction costs to over-generalize the performance patterns. One of my biggest complaints with Julia is that zealots for the language insist these permeating abstractions are costless, but they totally aren’t. Sometimes I’m way better off if not everything up the entire language stack is diff…

> One of my biggest complaints with Julia is that zealots for the language insist these permeating abstractions are costless, but they totally aren’t.

This sounds like it might be interesting, but your later comments about overhead and abstraction costs sounds like you maybe don't understand what Julia's JIT is actually doing and how it leverages multiple dispatch and unboxing. Could you be a bit more concrete?

Re: Julia adoption keeps climbing

#104

Post by stabbles »

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…

    julia> supertype(String) == supertype(SubString) == AbstractString
    true
If you insist just use f(s::AbstractString)

Re: Julia adoption keeps climbing

#105

Post by Grimm1 »

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…

I said something similar in another thread, but for me it doesn't have to be better than Python, as that is largely going to be subjective, the package ecosystem just has to grow and have some offering, at all, for the things that I do.

https://fluxml.ai/Flux.jl/stable/

Is still very barebones compared to Torch/TF/Flax and I would be hamstringing myself by switching to Julia even if I find the language otherwise attractive.

Re: Julia adoption keeps climbing

#107

Post by mlthoughts2018 »

chalst wrote: post #103
mlthoughts2018 wrote: post #88

Earlier quoted context omitted.

> “But having a performance boundary between components, why would that help?” It helps precisely so you don’t pay premature abstraction costs to over-generalize the performance patterns. One of my biggest complaints with Julia is that zealots for the language insist these permeating abstractions are costless, but they totally aren’t. Sometimes I’m way better off if not everything up the entire language stack is diff…

> One of my biggest complaints with Julia is that zealots for the language insist these permeating abstractions are costless, but they totally aren’t. This sounds like it might be interesting, but your later comments about overhead and abstraction costs sounds like you maybe don't understand what Julia's JIT is actually doing and how it leverages multiple dispatch and unboxing. Could you be a bit more concrete?

No I think that’s what I’m saying. When raising the issue that using multiple dispatch this way is premature abstraction that has intrinsic costs, all I get is the religious pamphlet about multiple dispatch.

Re: Julia adoption keeps climbing

#108

Post by Jtsummers »

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.

Ada was named after Ada Lovelace, for context. And it’s definitely not a common name anymore, at least in the US. It dropped off significantly through the 20th century with a spike several years ago.

Re: Julia adoption keeps climbing

#109

Post by laichzeit0 »

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

Re: Julia adoption keeps climbing

#110

Post by watwatinthewat »

chalst wrote: post #87
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…

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/brute force to install all the Anaconda default packages when a beginner is not going to use over maybe 5-10 libraries, but it's a solution that has worked flawlessly for beginners from my experience watching non-software engineers and "non-technical" people using Linux, Windows, and MacOS try Python for the first time in math and data science classes.

Post reply on HN