Giving up on Julia • Hacker News Board

Re: Giving up on Julia

#11

Post by jerf » Fri, May 13, 2016, 7:29 PM UTC

You know, you take a potshot at Go in there, but I observe that none of the negative bullet points apply to Go. My real point here not being "Go rocks", but that languages are more than just the collection of bullet-point features they claim on their home page. I think this is another one of those things that says obvious when I say it directly, but a lot of people are not letting it inform their actions.

Also I love that first alphabet image on that page.

Re: Giving up on Julia

#12

Post by bjkfjgnbkfg » Fri, May 13, 2016, 7:30 PM UTC

You also might be interested in: https://www.reddit.com/r/Julia/comments/3rxg1x/is_julia_movi...

Re: Giving up on Julia

#13

Post by ihnorton » Fri, May 13, 2016, 7:32 PM UTC

KenoFischer wrote: post #9

Happy to address these points: - Startup performance/memory usage Yes, we are definitely very acutely aware of these. Julia is not currently optimized for frequently run short scripts. That's the price on pays for having to bring up the entire runtime system (initializing the compiler, RNG, external libraries etc). The good news is that there will be a solution to this soon, which is to statically compile your julia…

> For packages that needs arrays of indices, it would be quite easy to define an `IndexArray` type that does the translation automatically.

(just to add: there is currently an open pull request from a core array-focused developer adding such support to base)

Re: Giving up on Julia

#14

Post by daxfohl » Fri, May 13, 2016, 7:36 PM UTC

Seems like for the last five years every language has been gaining popularity. Now they're all losing popularity. Except rust, perhaps, and elm. What gives?

Re: Giving up on Julia

#15

Post by Frompo » Fri, May 13, 2016, 7:37 PM UTC

If you want to replace Matlab you should use Octave, julia is for making your next climate model, not for "hello world" ricing

Re: Giving up on Julia

#16

Post by tavert » Fri, May 13, 2016, 7:43 PM UTC

marmaduke wrote: post #8

Numba package for Python gives you the LLVM JIT for numerical work. I really don't see how Julia is relevant anymore.

Types that aren't dense numpy arrays.

Re: Giving up on Julia

#17

Post by metrognome » Fri, May 13, 2016, 7:43 PM UTC

When the author compares the number of CPU instructions that sprintf compiles to in both C and Julia, he fails to take into account dynamic linking in C:

  jmp	__sprintf_chk

I would guess that another few hundred instructions run as a result of this jmp. Thus, the difference in the number of instructions that C's sprintf and Julia's @sprintf compile to are not as drastic as the author makes it seem.

Re: Giving up on Julia

#18

Post by Etzos » Fri, May 13, 2016, 7:44 PM UTC

jerf wrote: post #11

You know, you take a potshot at Go in there, but I observe that none of the negative bullet points apply to Go. My real point here not being "Go rocks", but that languages are more than just the collection of bullet-point features they claim on their home page. I think this is another one of those things that says obvious when I say it directly, but a lot of people are not letting it inform their actions. Also I love…

Was it really a potshot at Go? Maybe I read it incorrectly but what I thought was being said was that all the "modern" features that Julia/Python/other newer languages have are not available in Go (think stuff like list comprehensions). I don't think that's a potshot as it's not really a negative, just a difference in design. Go doesn't have those features and many times does not want those features, and there is nothing bad about that and nothing bad about stating such.

Re: Giving up on Julia

#19

Post by vitaut » Fri, May 13, 2016, 7:49 PM UTC

KenoFischer wrote: post #9

Happy to address these points: - Startup performance/memory usage Yes, we are definitely very acutely aware of these. Julia is not currently optimized for frequently run short scripts. That's the price on pays for having to bring up the entire runtime system (initializing the compiler, RNG, external libraries etc). The good news is that there will be a solution to this soon, which is to statically compile your julia…

Thanks for the detailed response. I hope that my post wasn't too harsh, the intent was mostly to attract attention to the current issues not to undermine the great work that you and others have been doing. I'm glad that many of the issues that I mentioned are being addressed. Maybe I'll give Julia another go in some time =).

The question of syntax is subjective of course. From the set {C-like, Python, MATLAB} I'd definitely like to see more influence of the first two and less from the last one.

Re: Giving up on Julia

#20

Post by vitaut » Fri, May 13, 2016, 7:50 PM UTC

metrognome wrote: post #17

When the author compares the number of CPU instructions that sprintf compiles to in both C and Julia, he fails to take into account dynamic linking in C: jmp __sprintf_chk I would guess that another few hundred instructions run as a result of this jmp. Thus, the difference in the number of instructions that C's sprintf and Julia's @sprintf compile to are not as drastic as the author makes it seem.

__sprintf_chk is shared between all calls to sprintf which is not true for Julia.