Live data from Hacker News

Julia Computing raises $24M Series A

hpcwire.com

101–110 of 246 posts

Re: Julia Computing raises $24M Series A

#101
post #94

Frankly I think the key thing that'll really get a lot of Julia adoption is a full-featured ML framework on par with TF, Pytorch, etc. What we've noticed is the vast majority of the time it's the data scientist's code that's slow not the actual ML model bit. So allowing them to write very performant code with a dumpy-like syntax and not have to deal with painfully slow pandas, lack of true parallelism, etc. would be…

Agreed! Flux & other Julia Ml packages are awesome and have best in class API. Performance and memory usage aren’t yet on par with TF/PyTorch (or at least when I last checked last year), but with more contributors and time I could see this closing and would love to use Julia for ML work

I believe we are currently at pytorch parity (and sometimes better) for speed. Memory usage depends....And this is without the extensive upcoming compiler improvements.

The reason for the lag is that Julia has been focusing on general composable compiler, codegen and metaprogramming infrastructure which isn't domain specific, whereas pytorch and friends has been putting lots of dev money into c++ ML focused optimizers.

Once the new compiler stuff is in place, it would be relatively trivial to write such optimizations, in user space, in pure Julia. Then exceeding that would be fairly simple also, plus things like static analysis of array shapes

Re: Julia Computing raises $24M Series A

#104
post #93

Earlier quoted context omitted.

Right. R's killer feature is its ecosystem. I'm wondering if most statisticians or researchers deal with data big enough that massively better performance would be enough motivation to switch.

"Massively better performance" is a bit misleading: Julia is only massively better at certain workflows. The fastest data.frame library in ALL interpreted languages is consistently data.table, which is R. For in-memory data analysis, Julia will have to offer more than performance to win over statisticians/researchers. Benchmarks: https://www.ritchievink.com/blog/2021/02/28/i-wrote-one-of-t...

In addition to the comment about df.jl catching up, they aren't comparable at all.

Julia's DF library is generic and allows user defined ops and types. You can put in GPU vectors, distributed vectors, custom number types etc. Julia optimizes all this stuff.

data.frame is just a giant chunk of c (c++) code that one must interact with in very specific ways

Re: Julia Computing raises $24M Series A

#105
post #99

Will there be a JupyterHub-like written in Julia in the near future, then? Because that's clearly where the money is.

I honestly haven't thought much about Jupyter since I moved to Pluto.jl (Observable-style reactive notebook):

https://github.com/fonsp/Pluto.jl

Re: Julia Computing raises $24M Series A

#106
post #57

Just a comment to participants who are suspicious of Julia usage over another, more popular language (for example) -- I think most Julia users are aware that the ecosystem is young, and that encouraging usage in new industry settings incurs an engineering debt associated with the fact that bringing a new language onto any project requires an upfront cost, followed by a maintenance cost. Most of these arguments are re…

> Some of these languages support abstractions which are strictly equivalent to static multi-method dispatch

Yes, and even with languages that have these abstractions, they aren't as pervasive as in Julia. Ex. There's a fundamental difference between typclasses and functions in haskell. In julia, there's no such distinction and code is more generic

Re: Julia Computing raises $24M Series A

#107

Earlier quoted context omitted.

“Only” to write a very high amount of high-quality statistical and plot packages…

Right. R's killer feature is its ecosystem. I'm wondering if most statisticians or researchers deal with data big enough that massively better performance would be enough motivation to switch.

You can write fast software with R, you just need to know how. The same applies to Julia - not everyone knows how to develop high-performance code.

Re: Julia Computing raises $24M Series A

#108

Earlier quoted context omitted.

What's the argument against using R and dropping into RCpp for very limited tasks? I (helped) write a very widely used R modelling package and while I wasn't doing anything on the numerical side, we seemed to get great performance from this approach -- and workflow-wise it wasn't too dissimilar to 25 years ago where I had to occasionally drop in X86 assembly to speed up C code! (Not a hater of Julia at all, very much…

One thing I don't like about the two langauge approach - deployment story get's more complicated it seems? In my case I went to deploy on a musl system and things with the two language just were a pain to get up and running. Conversely, everything that was native python ran fine in a musl based python container. Your native python code just moves also nicely between windows / linux / etc

Development story is as complicated as the tooling makes it to be. With good tooling that e.g. minimizes the amount of glue code and/or makes integration of building the native parts easy, the development story doesn't have to much more complicated.

Re: Julia Computing raises $24M Series A

#109

Can someone please explain to me, a mere mortal, what is the big deal with Julia. Why use it, when there are so many other good languages out there with more community/support? Honest question.

I am using Julia extensively since 2013, and I can say that it's awesome! But don't try to use it if you're looking for a general-purpose scripting language: Python is far better suited for this. Similarly, if you want to produce standalone executables, C++, Rust, Go or Nim are better. However, Julia is perfect if you write mathematical/physical/engineering simulations and data analysis codes, which is my typical use…

>Python is far better suited for this. Similarly, if you want to produce standalone executables, C++, Rust, Go or Nim are better.

That's the case now, because Julia made a design decision to focus on extreme composability, dynamism, generic codegen etc which involved compiler tradeoffs...but it's not inherent to the langauge.

For scripting, interpreted Julia is coming. For executables, small binary compilation is as well...particularly bullish on this given the new funding

Post reply on HN