it's not obvious to me what's their revenue model?
[deleted]
Julia Computing raises $24M Series A
51–60 of 246 posts
Re: Julia Computing raises $24M Series A
#52Can 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.
We had three big data pipelines written in numpy that we'd spent a lot of time optimizing. Rewriting them in Julia, we were able to get an 8x (serial -> serial), 14x (parallel -> serial), and 28x (parallel -> parallel) speedups respectively – and with clearer, more concise code. The difference is huge.
Re: Julia Computing raises $24M Series A
#53I'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.
Nothing has changed here. Julia Computing has always been a commercial venture — that's its reason-for-being, providing enterprise support and products built on the language. The Julia Language has always been (and always will be) open source. The two are completely separate[1], but we at Julia Computing invest greatly in the language itself — our success as a company is directly linked to the language's success.
1. https://julialang.org/blog/2019/02/julia-entities/#julia_com...
Re: Julia Computing raises $24M Series A
#54Earlier quoted context omitted.
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:…
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 simulations.
I work, in particular, on asteroid detection and orbit simulation, and it's all pretty much Python.
Re: Julia Computing raises $24M Series A
#55I'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.
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 entirely in Julia . At this point there's a bunch of companies that depend on Julia and are committed to it's future - we're just one among them.
Re: Julia Computing raises $24M Series A
#56Earlier quoted context omitted.
What's SDR in this context? Not software-defined radio, right? (Though I suppose Julia is a good fit for signal processing!)
Yes, software-defined radio, we have a very broad set of interests, and that happens to be one of the open jobs :).
Very cool. SDR's are in the process of taking over ham radio I think as well (give it another 5 years). So flexible.
Re: Julia Computing raises $24M Series A
#57Just 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-hashed on each new Julia post here. A few comments:
For most Julia users, any supposed rift between Python and Julia is not really a big deal -- we can just use PyCall.jl, a package whose interop I've personally used many times to wrap existing Python packages -- and supports native interop with Julia NumPy arrays. Wrapping C is similarly easy -- in fact, easier than "more advanced" languages like Haskell -- whose C FFI only supports passing opaque references over the line.
Ultimately, when arguments between languages in this space arise -- the long term question is the upfront cost, and the maintenance cost for a team. Despite the fact that Julia provides an excellent suite of wrapper functionality, I'm aware that introducing new Julia code into an existing team space suffers from the above issues.
I'm incredibly biased, but I will state: maintaining Julia code is infinitely easier than other uni-typed languages. I've had to learn medium-sized Python codebases, and it is a nightmare compared to a typed language. This total guessing game about how things flow, etc. It really is shocking. Additionally, multiple dispatch is one of those idioms where, one you learn about it, you can't really imagine how you did things before. I'm aware of equivalences between the set of language features (including type classes, multi-method dispatch, protocols or interfaces, etc).
Ultimately, the Julia code I write feels (totally subjectively) the most elegant of the languages I've used (including Rust, Haskell, Python, C, and Zig). Normally I go exploring these other languages for ideas -- and there are absolutely winners in this group -- but I usually come crawling back to Julia for its implementation of multiple dispatch. Some of these languages support abstractions which are strictly equivalent to static multi-method dispatch -- which I enjoy -- but I also really enjoy Julia's dynamism. And the compiler team is working to modularize aspects of the compiler so that deeper characteristics of Julia (even type inference and optimization) can be configured by library developers for advanced applications (like AD, for example). The notion of a modular JIT compiler is quite exciting to me.
Other common comments: time to first plot, no native compilation to binary, etc are being worked on. Especially the latter with new compiler work (which was ongoing before the new compielr work) -- seems feasible within a few quarter's time.
Re: Julia Computing raises $24M Series A
#58Earlier 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…
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
Re: Julia Computing raises $24M Series A
#59I'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.
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.
Re: Julia Computing raises $24M Series A
#60Julia 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)?