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

Julia Computing raises $24M Series A

hpcwire.com

Post reply on HN
Print view View original

71–80 of 246 posts

Re: Julia Computing raises $24M Series A

#71

Post by jjoonathan »

awaythrowact wrote: post #39

Congrats to the Julia team. I am a python developer who has dabbled with Julia but it never stuck for me. I think Julia was built by academics for other academics running innovative high performance computing tasks. It excels at the intersection of 1) big data, so speed is important, and 2) innovative code, so you can't just use someone else's C package. Indeed, Julia's biggest successful applications outside academi…

> The next PyTorch needs to be written in Julia. Will that happen? Maybe! I hope so!

The Two Language Problem makes this more likely than one might think. Those high level python packages that plaster over python's many mediocrities have to be written and maintained by someone, and while extremistan bears the brunt of the pain and has done a remarkable job shielding mediocristan, it's extremistan that gets to decide which language to use for the next killer app.

Of course, python has more inertia than god, so it won't go quietly.

Re: Julia Computing raises $24M Series A

#72

Post by ssivark »

awaythrowact wrote: post #39

Congrats to the Julia team. I am a python developer who has dabbled with Julia but it never stuck for me. I think Julia was built by academics for other academics running innovative high performance computing tasks. It excels at the intersection of 1) big data, so speed is important, and 2) innovative code, so you can't just use someone else's C package. Indeed, Julia's biggest successful applications outside academi…

> do not need innovative code

I think this is a good deciding factor. Not just for “big data”. In my experience, with its combination of flexibility and raw speed, Julia makes implementing new algorithms (from scratch) a breezy experience. The strong research/academic presence in the community also helps towards encouraging decent Julia libraries for a lot of cutting edge work.

So if you are working in an area where that could make a significant difference, it’s an excellent reason to use Julia.

> will need to develop killer app packages. The next PyTorch needs to be written in Julia. Will that happen?

If enough cutting-edge work happens in Julia, it’s likely that a few great tools/platforms will emerge from that. We’re already seeing that in the scientific modeling ecosystem (as an example), with Differential Equations infrastructure and PumasAI.

Re: Julia Computing raises $24M Series A

#73

Post by ziotom78 »

devoutsalsa wrote: post #45
leephillips wrote: post #15

Earlier quoted context omitted.

If you are doing very high-performance numerical work, your choices¹ are Fortran, C, C++, or Julia. Julia is way more fun to program in than the other choices. Also, it has some properties² that make code re-use and re-combination especially easy. 1 https://www.hpcwire.com/off-the-wire/julia-joins-petaflop-cl... 2 https://arstechnica.com/science/2020/10/the-unreasonable-eff...

Doesn’t Python offer this speed in it’s scientific libraries, too? Or is the answer “yes, if you use the libraries are written in Fortran, C, C++, or Julia!”?

NumPy is not a good comparison, because Julia can produce faster code which takes less memory [1]. The Python library that is closest to Julia's spirit is Numba [2], and in fact I was able to learn Numba in a few hours thanks to my previous exposure to Julia. (It probably helps that they are both based on LLVM, unlike NumPy.)

However, Numba is quite limited because it only works well for mathematical code (it is not able to apply its optimizations to complex objects, like lists of dictionaries), while on the other side Julia's compiler applies its optimizations to everything.

[1] https://discourse.julialang.org/t/comparing-python-julia-and...

[2] https://numba.pydata.org/

Re: Julia Computing raises $24M Series A

#74

Post by leephillips »

spenczar5 wrote: post #54
leephillips wrote: post #48

Earlier quoted context omitted.

When those libraries are fast, it is because they are using Numpy routines written in Fortran or C. And you can get a lot done with those libraries, of course. But they’re only fast if your code can be fit into stereotyped vector patterns. As soon as you need to write a loop, you get slow Python performance. Python + Scipy would not be a good choice for writing an ocean circulation or galaxy merger simulation. EDIT:…

I work in research software for astronomy, and I cannot agree with that. A very large amount of astronomy software is in Python. Numba has gone a long way toward making non-vectorized array operations very fast from Python. Most people use a ton of numpy and scipy. It turns out that phrasing things as array operations with numpy operators is quite natural in this field, including for things like galaxy merger simulat…

I’m aware that there is plenty of serious computation done with these tools. I don’t want to overstate; I merely meant that, for a fresh project, Julia is now a better choice for a large-scale simulation. Note that no combination of any of the faster implementations of Python + Numpy libraries has ever been used at the most demanding level of scientific computation. That has always been Fortran, with some C and C++, and now Julia.

“It turns out that phrasing things as array operations with numpy operators is quite natural in this field”

But if A and B are numpy arrays, then A + B will calculate the elementwise sum on a single core only, correct? It will vectorize, but not parallelize. All large-scale computation is multi-core.

Re: Julia Computing raises $24M Series A

#75

Post by exdsq »

coldtea wrote: post #25
djhaskin987 wrote: post #2

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.

> Why use it, when there are so many other good languages out there with more community/support? Honest question. Such a question seems sort of in bad faith (or loaded), since the selling points of Julia have been hammered time and again on HN and elsewhere, and are prominent on its website. It's a 1 minute search to find them, and if someone is already aware that there's this thing called Julia to the point that the…

You assume they've seen the posts about Julia on HN. If you're not interested in PL it's fair to assume they might not click on those posts.

Re: Julia Computing raises $24M Series A

#76

Post by mr_overalls »

lycopodiopsida wrote: post #66
mr_overalls wrote: post #60

Julia seems like such a superior language compared to R. What would be required for it to supplant R for statistical work (or some subset of it)?

“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.

Re: Julia Computing raises $24M Series A

#77

Post by systemvoltage »

lycopodiopsida wrote: post #66
mr_overalls wrote: post #60

Julia seems like such a superior language compared to R. What would be required for it to supplant R for statistical work (or some subset of it)?

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

And clone/bribe Hadley Wickham :-) He is a tour de force of R.

Re: Julia Computing raises $24M Series A

#78

Post by KenoFischer »

jstx1 wrote: post #59
KenoFischer wrote: post #55

Earlier quoted context omitted.

These kind of concerns are not unreasonable in general of course, but in this case let me point out that Julia Computing has been a commercial enterprise for more than six years. Also, our commerical product is deliberately not Julia, but rather we're building our products on top of Julia, just like anyone else might. In fact there are several startups unrelated to us that have built multimillion dollar businesses en…

You're not just one among them given how much control you have over the language itself. Those other companies aren't founded by the co-creators of and main contributors to the language.

Sure, but there's two separate concerns here. One is that money will turn us evil and we'll exercise undue influence. My counterpoint was that JC has been around for six years now and in that time we've actually strengthened Julia significantly as an independent project. My other point though was about concentration risk. I think far more common than people turning evil is that companies go all out raising money, become the only people developing a project and then if the revenue doesn't come as planned, the company and the project fail together with unpleasant results. At this point, if Julia Computing fails, Julia the language will survive no problem. Of course we're not planning on failing, but before going out on this commercial path, it was hugely important for all of us that Julia is on solid footing. For must of us, what we've built in Julia is our "life's work" (ok, it's only been 10 years, but that's a substantial effort still) and we're not planning to let that just die.

Re: Julia Computing raises $24M Series A

#79

Post by SatvikBeri »

devoutsalsa wrote: post #45
leephillips wrote: post #15

Earlier quoted context omitted.

If you are doing very high-performance numerical work, your choices¹ are Fortran, C, C++, or Julia. Julia is way more fun to program in than the other choices. Also, it has some properties² that make code re-use and re-combination especially easy. 1 https://www.hpcwire.com/off-the-wire/julia-joins-petaflop-cl... 2 https://arstechnica.com/science/2020/10/the-unreasonable-eff...

Doesn’t Python offer this speed in it’s scientific libraries, too? Or is the answer “yes, if you use the libraries are written in Fortran, C, C++, or Julia!”?

There are a few reasons why Julia still tends to be faster than numpy:

* Julia can do loop fusion when broadcasting, while numpy can't, meaning numpy uses a lot more memory during complex operations. (Numba can handle loop fusion, but it's generally much more restrictive.)

* A lot of code in real applications is glue code in Python, which is slow. I've literally found in some applications that That said, if your code is mostly in numba with no pure python glue code (not just numpy), you probably won't see much of a difference.

Re: Julia Computing raises $24M Series A

#80

Post by KenoFischer »

hawk_ wrote: post #63
KenoFischer wrote: post #47

Earlier quoted context omitted.

Nothing complicated. Stream 1: Build amazing products for particular domains, charge license fees Stream 2: Build a great SaaS platform for running Julia, charge for compute Since all of our domain products are built in Julia and often involve significant compute cost for their intended application, hopefully both at the same time :).

thanks for the answer Keno. i guess an example Stream 1 product is Pumas. i didn't realize it's a separate product from Julia. my background is in finance and i am curious if you have any plans to break into that domain (examples on your website include julia language use)

Finance was a focus area early on and we have a fair number of consulting clients there and JuliaHub is available of course, but we were never able to figure out a dedicated domain-specific, non-niche product to sell into the space. Maybe in the future.
Post reply on HN