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

Giving up on Julia

zverovich.net

Post reply on HN
Print view View original

161–170 of 242 posts

Re: Giving up on Julia

#161

Post by tcpekin »

bluecalm wrote: post #75
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…

The thing about 1 based indexing is that it's a kind of in your face "this is different" decision from the point of view of a programmers of most popular languages. To be honest I wouldn't want to start investing my time into a language where people who proposed 1 based indexing are making design decisions. It's not that I think they are incompetent but it's clear they care way more about some different world than ab…

I don't really get the difference. I'm in academia i guess (grad school) and use MATLAB a bunch, as well as Python (not a CS major). I don't think it's that much work to switch between the two, and I don't understand why there's such a division. Why is this such a huge deal?

Re: Giving up on Julia

#162

Post by kstrauser »

unlinker wrote: post #34
hondaz54 wrote: post #32

Earlier quoted context omitted.

Obviously static/strong typing is winning. Last man standing are JavaScript and Python, the former transforms into a compilation target (like Elm), the latter doing some kind of gradual typing (like mypy). I think dynamic typing has its place, but more in experimental design and prototyping than in bigger application development (big IMHO).

Why is strong/dynamic typing considered such a big deal?

And why do people conflate them so? Python is strongly typed by any reasonable definition, but it's also dynamically typed. To contrast, I've heard C described as weakly, statically typed.

Strong typing is awesome. I personally think that dynamic typing is wonderful, too, but opinions vary about that.

Re: Giving up on Julia

#163

Post by [deleted] »

chrispeel wrote: post #145
SolarNet wrote: post #92

Earlier quoted context omitted.

> - Slowing down in development I think part of this problem is the community, multiple people have reported having bad interactions with core language devs. Also the policies for inclusion of features, how to propose features, how decisions are made with respect to the code base, etc. all seem poorly documented.

I have never had a bad interaction with the core language devs. OTOH, they are passionate about the language; I've found all the core developers I've met very helpful.

[deleted]

Re: Giving up on Julia

#164

Post by SolarNet »

chrispeel wrote: post #145
SolarNet wrote: post #92

Earlier quoted context omitted.

> - Slowing down in development I think part of this problem is the community, multiple people have reported having bad interactions with core language devs. Also the policies for inclusion of features, how to propose features, how decisions are made with respect to the code base, etc. all seem poorly documented.

I have never had a bad interaction with the core language devs. OTOH, they are passionate about the language; I've found all the core developers I've met very helpful.

I'm referring to one specific core dev. However they all know each other from MIT so it makes it difficult for them to deal with that fact. I can point to 3 public examples, in addition to a couple of private reports about problems which allow me to be certain. But admittedly it's all second hand to me (from people who work close to the language).

Re: Giving up on Julia

#165

Post by IndianAstronaut »

zintinio5 wrote: post #30

For many users of Julia, long-running performance matters more than microbenchmarks. Having converted a naively written Python program to Julia (there was a huge amount of computation being done over a large search space), I experienced a massive speedup even against PyPy. My Python scripts ran for about 10 hours before I called it quits (.6% of the work had been completed). Converting to Julia allowed me to finish w…

>AND it was easy to parallelize

This is what is killing me when I use Python. So hard to run things in parallel.

I have had luck with Go trying to do this and set up a concurrent application.

Re: Giving up on Julia

#166

Post by idunning »

mathgenius wrote: post #130
yoodenvranx wrote: post #88

As someone who does quite a lot of image and signal processing the fact that their arrays are 1-based is a complete deal breaker. The first few years of my career I worked with Matlab and I hated 1-based arrays with a passion. I think I never encountered a situation where the Matlab way makes stuff easier, almost always the 0-based index is the more natural choice. After I switched to Python/C I can say that I never…

I just cannot comprehend how anyone can use 1-based indexing. I have never used it myself though so there's always the possibility that I may just be missing out on something. Glad that you cleared this up.

Because index sets in mathematics are typically indexed beginning at 1? The most notable, and relevant, being indexing in matrices

Re: Giving up on Julia

#167

Post by tavert »

vitaut wrote: post #160
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…

Regarding the slowdown in development, perhaps it's a seasonal variation connected to GSoC. For example, notice a drop in postings since October in https://groups.google.com/forum/#!aboutgroup/julia-dev . This seems to be more or less consistent with the observation in http://www.davideaversa.it/2015/12/the-most-promising-langua... , but that's just a guess.

No summer of code students have had projects that involved work primarily on the core language since 2013. Not that many posts happen on julia-dev because most of the development communication happens on github.

Re: Giving up on Julia

#168

Post by IndianAstronaut »

pathsjs wrote: post #61

You may be interested in Nim. If you can tolerate working without a REPL, Nim hits essentially all the bullet points you mentioned, from macros to coroutines, multiple dispatch, ability to call c trivially and python easily and so on. It has static types and is fast. The libraries for scientific computing are not there yet, but it lends very nicely to mathematical abstraction.

>If you can tolerate working without a REPL

This is going to be a tough sell for any data analytics work.

Re: Giving up on Julia

#169

Post by ihnorton »

vitaut wrote: post #160
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…

Regarding the slowdown in development, perhaps it's a seasonal variation connected to GSoC. For example, notice a drop in postings since October in https://groups.google.com/forum/#!aboutgroup/julia-dev . This seems to be more or less consistent with the observation in http://www.davideaversa.it/2015/12/the-most-promising-langua... , but that's just a guess.

For better or worse, most development discussion happens on GitHub rather than julia-dev. I've been catching up on GitHub threads recently, and the progress towards 0.5 is really impressive -- both in the language itself, and in the tooling (especially the debugger). I think the nature of priorities has changed somewhat as the language matures, but I disagree that development has slowed. (disclosure: I'm a Julia committer, but have been a bit out of the loop for some months now)

There is certainly a need for better interim communication on progress between releases, to let people know what is happening without reading every GitHub thread.

Re: Giving up on Julia

#170

Post by vitaut »

bmh100 wrote: post #127
vitaut wrote: post #113

Earlier quoted context omitted.

> what scenario are you imagining where startup times would be a significant concern? Starting a REPL or running a computation that doesn't take long time, adjusting parameters, re-running. Startup time may not be too big in absolute numbers but it's noticeable and adds up quickly especially if you start using more packages rather than toy programs that I used as an example.

Sorry if I was being vague, but what situation would you re-run a short computation by executing the whole program again instead of using subroutines? Are we talking about a data scientist performing initial, exploratory analysis on a very small subset of data?

> Are we talking about a data scientist performing initial, exploratory analysis on a very small subset of data?

Yes, that's one example. Also when debugging one usually uses small data sets. There are plenty of cases where runtime is short.

I think the problem is that Julia is somewhat vague on how it should be used. If it stated explicitly that it is intended to be used in MATLAB-like fashion with one long-running instance that would save people from trying to use it as Python or other dynamic language.

Post reply on HN