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

Why Julia

ucidatascienceinitiative.github.io

Post reply on HN
Print view View original

231–240 of 257 posts

Re: Why Julia

#231

Post by bluenose69 »

babahoyo wrote: post #177
sgillen wrote: post #170

Earlier quoted context omitted.

That's the trade off I guess, because of the JIT you have a slow initialization followed by very fast code. That's not really good for a lot of workflows though (if you're running a smallish script over and over for example).

If you are running a script over and over (or using small modules to do organize things) it will be very fast and easy to work with. The compilation is just for the first time a script is run, not every time. It really isn't a barrier any more than, say, waiting for `library` commands in R.

I don't think I've ever seen an R library() take more than about a second, and usually the action is complete as my finger is starting to raise from the 'return' key. When I tried "using Plots" in julia, it took several tens of seconds the first time, and several seconds in subsequent sessions. So, slower than R, but not terribly so. I suspect the real advantage of Julia is that it lets the analyst stick to a single language, without (as in the R case) having to write time-consuming components in C, C++, or Fortran.

Re: Why Julia

#232

Post by ethelward »

antpls wrote: post #146
ethelward wrote: post #28

Earlier quoted context omitted.

> In a nutshell: Julia is great when you're a grad student working mostly by yourself on small scale projects! But not so great in prod. Some people would disagree with that https://juliacomputing.com/case-studies/celeste.html

This was published on their own website, it is therefore biased toward a good perception of them. It doesn't seem to be a fair and independent review to help build an opinion.

And these were not published on their website:

https://arxiv.org/pdf/1801.10277.pdf

http://proceedings.mlr.press/v37/regier15.pdf

https://arxiv.org/pdf/1803.00113.pdf

I had to go so far as to read the project Github page to find them.

Re: Why Julia

#233

Post by vram22 »

jhayward wrote: post #199
vram22 wrote: post #159

Earlier quoted context omitted.

What does reshape actually do? Create a 1-D array from a 2-D one or vice versa, or just make appear to be so?

It alters the descriptor of the data layout, not how the data is actually stored.

Got it, thanks.

Re: Why Julia

#234

Post by improbable22 »

masklinn wrote: post #230
improbable22 wrote: post #78

Earlier quoted context omitted.

But you have to type `python3` which is 7 letters to 5, if we're counting :) Seriously though, it's hard to write one manual which gives everyone the perfect on-ramp for their needs. I actually think it's fair to aim it low, make it easy for matlab refugees to get started, interactively. People who know how namespacing works in several other languages (and intend to write big projects) are the ones well-equipped to k…

> But you have to type `python3` which is 7 letters to 5, if we're counting :) Of course, that was actually a pretty big consideration during the "vcs wars", both the length and the alternation of VCS commands. > I actually think it's fair to aim it low, make it easy for matlab refugees to get started, interactively. Then don't whine that people use that, and police your community. > Nobody has been victimised! Well…

My point was that counting letters in one short command seems myopic here, it's not something you type in isolation. Julia package names tend to be much longer and more explicit than python/R ones. But julia code (at least mine) tends to be more compact, partly because I can write things like A ⊗ B instead of np.kron(A,B).

As far as I'm aware there is no budget for a police force. There is, however, a double-your-money-back guarantee on all advice from blog posts!

I do think the manual could be clearer about using/import. Perhaps this should be emphasised under workflow [1], and packaging differences from Python included in the list [2]. The experts have forgotten what the pain-points were; contributions from those who have not are thus welcomed.

[1] https://docs.julialang.org/en/v1/manual/workflow-tips/ [2] https://docs.julialang.org/en/v1/manual/noteworthy-differenc...

Re: Why Julia

#235

Post by antpls »

ethelward wrote: post #232
antpls wrote: post #146

Earlier quoted context omitted.

This was published on their own website, it is therefore biased toward a good perception of them. It doesn't seem to be a fair and independent review to help build an opinion.

And these were not published on their website: https://arxiv.org/pdf/1801.10277.pdf http://proceedings.mlr.press/v37/regier15.pdf https://arxiv.org/pdf/1803.00113.pdf I had to go so far as to read the project Github page to find them.

In all those papers, there at least one member of the team in the author list, or a member of a partner organization (Intel, Lawrence Berkeley National Laboratory, etc). I wouldn't call them fair independent reviews of the language.

Re: Why Julia

#236

Post by skohan »

AllegedAlec wrote: post #229
skohan wrote: post #169

Earlier quoted context omitted.

What's convenient about Swift as a language which "tries to do everything" is that you can mix and match. Sometimes it's convenient to use different programming paradigms for different components.

It also makes the code a pain to read and maintain.

Difference of opinion. Swift is the most self-documenting language I have worked with between the named function parameters and the power of the type system.

Re: Why Julia

#237

Post by orbifold »

RivieraKid wrote: post #214
ModernMech wrote: post #212

Earlier quoted context omitted.

Which ways?

Faster startup, better printing of values, integrated package manager, integrated help system, filesystem autocompletion, etc.

Swift actually has faster startup, a better package manager by far, better custom printing support. It also has playground and jupyther notebook integration. Swift is a solid piece of engineering, Julia is a hacky toy.

Re: Why Julia

#240

Post by dnautics »

enriquto wrote: post #92
agumonkey wrote: post #91

Earlier quoted context omitted.

Hold on how long is MATLAB boot ?

maybe he was thiking about Octave, that is an interpreter for the same language as Matlab and it starts much faster.

Yeah but heaven help you if you need nested for loops in octave.
Post reply on HN