it's not obvious to me what's their revenue model?
Julia Computing raises $24M Series A
41–50 of 246 posts
Re: Julia Computing raises $24M Series A
#42Congrats Julia team!
Re: Julia Computing raises $24M Series A
#43Can 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…
While you have a valid perspective, the HN guidelines [1] do specifically ask us to assume good faith.
Re: Julia Computing raises $24M Series A
#44I'm sure there is some good in there to have some solid funding for additional development, but now that it's a commercial venture, I'm terrified to see the revenue model. The moment you build your profit platform on top of someone else's profit platform, you become someone else's servant.
This is my concern too. I skimmed the article and I guess its going to be something along the lines of locking certain sim modules behind a subscription like Autodesk/Fusion360?
Happy to be wrong here.
Re: Julia Computing raises $24M Series A
#45Can 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.
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!”?
Re: Julia Computing raises $24M Series A
#46Congrats 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…
There is another important niche I am particularly excited about: programming language research geeks and lisp geeks. The pervasive multiple-dispatch in Julia provides such a beautiful way to architecture a complicated piece of code.
Re: Julia Computing raises $24M Series A
#47it's not obvious to me what's their revenue model?
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 :).
Re: Julia Computing raises $24M Series A
#48Earlier 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!”?
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: And last time I checked, Numpy only parallelizes calls to supplied linear algebra routines, and only if you have the right library installed. A simple vector arithmetic operation like a + b will execute on one core only.
Re: Julia Computing raises $24M Series A
#49Earlier 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!”?
You're right, Python and R are good choices if your goals happen to align with what those libraries are optimised for, but outside of that you normally need to start writing your own C or C++.
Re: Julia Computing raises $24M Series A
#50Earlier 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...
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…
Interoperability between libraries that expect your code to be pure R / pure Python. If you use RCpp or Cython or CPython then you lose much of the magic behind the language that enables the cool (but frequently slow) features. My biggest pain point in this situation: you can not use SciPy or Pillow or Cython code with Jax/Pytorch/Tensorflow (except in very limited fashion).
Differential equation solvers that need to take a very custom function that works on fancy R/Python objects is another example of clumsiness in these drop-to-C-for-speed languages. It works and as a performance-nerd I enjoy writing such code, but it is clumsy.
That type interoperability is trivial in Julia.