15 ms·

Julia Computing raises $24M Series A

378 points by dklend122 5y ago

djhaskin987 5y ago
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.
- RandomWorker 5y ago
  Basically, the syntax is similar to matlap as well as lots of the same features around functional and variable deceleration as python. The best thing for sure is the native support for parallel processing. Where python is single tread.
- Kranar 5y ago
  I think your question presupposes a lot of assumptions that may not be right. For one, I don't know that Julia is like a "big deal", certainly Python is the big deal in this field and I doubt Julia is looking to displace it wholesale. That said, Julia is a great addition to the scientific computing landscape because of its performance compared to other languages and its use of modern programming features. Python is just really really slow compared to Julia and parallelism in Python is a huge pain. Fortran is really really fast but that comes at a cost of being awkward to use and coming with a great deal of baggage. Julia is fast, feels modern, and has pretty easy parallelism. Then there's Matlab, Mathematica, and they are also pretty good but they're closed source/proprietary, so their ecosystem is mostly limited and driven by commercial interests. Nothing wrong with that intrinsically and they're all widely used but it's one way Julia differentiates itself, by making the language open and making money through services.
  - ChrisRackauckas 5y ago
    Julia Computing is not a services company. There are commercial products built off of this stack which are the core of Julia Computing. For example, https://pumas.ai/ https://pumas.ai/ is a product for pharmacology modeling and simulation, and runs on the JuliaHub cloud platform of Julia Computing. It is already a big deal in the industry, with the quote everyone refers to "Pumas has emerged as our 'go-to' tool for most of our analyses in recent months" from the Director Head of Clinical Pharmacology and Pharmacometrics at Moderna Therepeutics during 2020 (for details, see the full approved press release from the Pumas.ai website). JuliaSim is another major product which is being released soon, along with JuliaSPICE publicly in the pipeline. But indeed, Julia Computing differentiates itself from something like MATLAB or Mathematica by leveraging a strong open source community on which these products are developed. These products add a lot of the details that are generally lacking in the open source space, such as strong adherents to file formats, regulatory compliance and validation, GUIs, etc. which are required to take such a product from "this guy can use it" to a fully marketable product usable by non-computational scientists. I will elaborate a bit more on this at JuliaCon next week in my talk on the release of JuliaSim.
    - codekilla 5y ago
      Wanted to ask if JuliaDB is something that might get more development attention? Or will that remain a community project? (I see it’s been in need of a release for awhile.)
      - ChrisRackauckas 5y ago
        It is not in our current set of major products. That said, informal office discussions mentioned JuliaDB as recently as last week, so it's not forgotten. If there's a demonstrated market, say a need for new high-performance cloud data science tools as part of the pharmaceutical domains we work in, then something like JuliaDB could possibly be revived in the future (of course, this is no guarantee).
      - ViralBShah 5y ago
        In general, the community has discussed reviving the project (or at least the ideas and some of its codebase). Julia computing will also be contributing as part of that revival.
        codekilla 5y ago
        Thank you both for the comments. I believe I remember early on there were some comparisons to kdb+/q. I think there is some pretty great potential with an offering like this (an in-memory database integrated with the language, coupled with solid static storage) from the Julia community going forward. I can envision some use cases in genomics/transcriptomics.
- nvrspyx 5y ago
  From what I understand, Julia is dynamically typed and similar to a scripting language like Python or Ruby, but is also compiled, so it has performance similar to C/C++ (it's also written in itself). It also has built-in support for parallelism, multi threading, GPU compute, and distributed compute. I'm sure others can provide more insight. I've only dabbled in it and haven't used it extensively in any sense of the word.
- deleted 5y ago
  [deleted]
- oscardssmith 5y ago
  Short answer is that it is (imo) by far the best language for writing generic and fast math. Multiple dispatch allows you to write math using normal notation and not have to jump through hoops to do so.
  - enriquto 5y ago
    can you show a simple example of that? I tend to see multiple dispatch as a mental burden, (e.g.: when I see a function call, where will it be dispatched? the answer dependa on the types that I'm juggling, that may not even be visible at that point...)
    - oscardssmith 5y ago
      The key to make multiple dispatch work well is that you shouldn't have to think about what method gets called. For this to work out, you need to make sure that you only add a method to a function if it does the "same thing" (so don't use >> for printing for example). To Dr the benefit of this in action, consider that in Julia 1im+2//3 (the syntax for sqrt(-1)+2 thirds) works and gives you a complex rational number (2//3+1//1 im). To get this behavior in most other languages, you would have to write special code for complex numbers with rational coefficients, but in Julia this just works since complex and rational numbers can be constructed using anything that has arithmetic defined. This goes all the way up the stack in Julia. You can put these numbers in a matrix, and matrix multiplication will just work, you can plot functions using these numbers, you can do gpu computation with them etc. All of this works (and is fast) because multiple dispatch can pick the right method based on all the argument types.
      - enriquto 5y ago
        > make sure that you only add a method to a function if it does the "same thing" But this only concerns when I'm writing the code myself. If I read some code and I see a few nested function calls, there's a combinatorial explosion of possible types that gives me vertigo. > complex and rational numbers can be constructed using anything that has arithmetic defined. seriously? this does not seem right, it cannot be like that. If I build a complex number out of complex numbers, I expect a regular complex number, not a "doubly complex" number with complex coefficients, akin to a quaternion. Or do you? There is surely some hidden dirty magic to avoid that case.
- CapmCrackaWaka 5y ago
  It’s a solid combination of performance, easy syntax and flexible environment. A big drawback of Python is that any performant code is actually written in a lower level language, with foreign function calls. That’s not to say that there are no disadvantages to Julia. I personally see Julia as a beefed up, new and improved R.
- leephillips 5y ago
  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-club/ https://www.hpcwire.com/off-the-wire/julia-joins-petaflop-cl... 2 https://arstechnica.com/science/2020/10/the-unreasonable-effectiveness-of-the-julia-programming-language/ https://arstechnica.com/science/2020/10/the-unreasonable-eff...
  - notafraudster 5y ago
    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 think it's a cool language and an increasingly vibrant ecosystem and have been consistently impressed when Julia devs have spoke at events I've attended)
    - _Wintermute 5y ago
      I think the argument is that most R users don't know C++. So Julia avoids the "2 language problem" that you get with modern scientific computing.
    - QuadmasterXLII 5y ago
      I think that's just being clumped in with "Use C++," which he mentioned as an option
      - galangalalgol 5y ago
        and the ffi adds a lot of overhead for granular data. Julia just works fast. My only friction has been offline development, which isn't well supported yet.
    - 5y ago
- cbkeller 5y ago
  Composability via dispatch-oriented programming, e.g. [1] It also pretty much solved my version of the two-language problem, but that means different things to different people so ymmv. [1] https://www.youtube.com/watch?v=kc9HwsxE1OY https://www.youtube.com/watch?v=kc9HwsxE1OY
- axpy906 5y ago
  My understanding is that it runs faster than native python and R. That said with Numba and other libraries, see no point.
  - NeutralForest 5y ago
    It's easier to write Julia code than to deal with Numba tbh and the ecosystem around Julia makes the code composable which is often not the case if you write Numba code and have to deal with other libraries.
  - tfehring 5y ago
    Numba is great for pure functions on primitive types but it breaks down when you need to pass objects around. PyPy is fantastic for single-threaded applications but doesn't play nicely with multiprocessing or distributed computing IME. Numpy helps for stuff you can vectorize, but there's a lot of stuff you can't (or can but shouldn't); it also brings lots of minor inconveniences by virtue of not being a native type - e.g., the code to JSON serialize a `Union[Sequence[float], np.ndarray]` isn't exactly Pythonic.
    - oscardssmith 5y ago
      Also, numpy has about a 100x overhead door small arrays (10 or fewer elements).
  - danuker 5y ago
    > runs faster than native python and R That's a bit of an understatement. It's about as fast as C and Rust (ignoring JIT compilation time). https://julialang.org/benchmarks/ https://julialang.org/benchmarks/
  - dklend122 5y ago
    Composability, speed, static analysis, type system, abstractions, user defined compiler passes, metaprogramming, ffi, soon static compilation, differentiability and more create an effect that far exceeds numba
- duped 5y ago
  There really aren't that many languages out there trying to be on the cutting edge of JIT for scientific computing with a great REPL experience. There are a few areas where developers have to prototype in a language like Python or MATLAB to design their systems, generate test data, and even just plot stuff during debugging then rewrite in C/C++ for speed. It's an enormous time sink that is prone to errors, and leads to terrible SWE culture. If Julia can provide both the REPL/debugging experience of a language like Python or MATLAB with a fast enough JIT to use in production it would be an enormous boon to productivity and robustness. There are a few limiting factors but I don't think they're absolute.
- coldtea 5y ago
  >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 they think it's made to be "a big deal", they surely have seen them. So, what could the answer to the question above be? Some objective number that shows Julia is 25.6% better than Java or Rust or R or whatever? But first, who said it's a "big deal"? It's just a language that has some development action, seems some adoption, and secured a modest fundng for its company. That's not some earth shattering hype (if you want to see that, try to read about when Java was introduced. Or, to a much lesser degree, Ada, for that matter). You use a language because you've evaluated it for your needs and agree with the benefits and tradeoffs. Julia is high level and at the same time very fast for numerical computing allowing you to keep a clean codebase that's not a mix of C, C++, Fortran and your "real" language, while still getting most of the speed and easy parallelization. It also has special focus on support for that, for data science, statistics, and science in general. It's also well designed. On the other hand, it has slow startup/load times, incomplete documentation, smaller ecosystem, and several smaller usability issues.
  - cbkeller 5y ago
    While you have a valid perspective, the HN guidelines [1] do specifically ask us to assume good faith. [1] https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
  - exdsq 5y ago
    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.
- agumonkey 5y ago
  kinda tries to make coding like python but running like fortran (without having to resort side-batteries like numpy/scipy) designers seems to have a good amount of PLT knowledge and made good foundations
- SatvikBeri 5y ago
  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.
  - xiaodai 5y ago
    did you end up using package compiler as well?
    - SatvikBeri 5y ago
      No, the pipelines are long enough that compilation time isn't a big issue.
- ziotom78 5y ago
  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 case. Its support for multiple dispatch and custom operators lets you to write very efficient code without sacrificing readability, which is a big plus. Support for HPC computing is very good too.
  - amkkma 5y ago
    >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
    - ziotom78 5y ago
      Yeah, you are right, these limitations are not much of a matter of the language itself.
    - oxinabox 5y ago
      > For scripting, interpreted Julia is coming. Citation for this? Julia has had a built-in interpretted since 1.0, in 2017 use `--compile=min`, or `--compile=none` to make use of it. And JuliaInterpretter.jl has been working since 2018. Both are very slow -- slower than adding in the compile time for most applications. As I understand it, this is because a number of things in how the language works are predicated on having a optimizing JIT compiler. As is how the standard library and basically all packages are written. Julia is going to over time become nicer for scripting, just because of various improvements. In particular, I put more hope on caching native code than on any new interpreter.
KenoFischer 5y ago
I guess this would be a good place to mention that we're hiring for lots of positions, so if you would like to help build JuliaHub, or work on compilers, or come play with SDRs, please take a look at our job openings :) : https://juliacomputing.com/jobs/ https://juliacomputing.com/jobs/
- p_j_w 5y ago
  >or come play with SDRs This sounds like an absolute dream!
  - paulgb 5y ago
    What's SDR in this context? Not software-defined radio, right? (Though I suppose Julia is a good fit for signal processing!)
    - KenoFischer 5y ago
      Yes, software-defined radio, we have a very broad set of interests, and that happens to be one of the open jobs :).
      - slownews45 5y ago
        Very cool. SDR's are in the process of taking over ham radio I think as well (give it another 5 years). So flexible.
      - p_j_w 5y ago
        Understandable if you can't answer this question, but how much work have you guys done with SDRs and arrays?
        KenoFischer 5y ago
        This project is just starting, so I have hardware sitting on my desk and have used it a bit, but other than that not much.
sidpatil 5y ago
The article mentions a circuit simulation package named JuliaSPICE, but I can't find any intonation on it. Can someone please provide a link?
- oscardssmith 5y ago
  It's not released yet. Official announcement is happening at juliacon in 2 weeks
- KenoFischer 5y ago
  There's not really much public about it yet. There'll be a technical talk about it at JuliaCon and we're talking to initial potential customers about it, but it's not quite ready for the wider community yet. If you want some of the technical details, I talked about it a bit in this earlier thread https://news.ycombinator.com/item?id=26425659 https://news.ycombinator.com/item?id=26425659 about the DARPA funding for our neural surrogates work in circuits (which will be part of the product offering, though the larger product is a modern simulator + analog design environment, which is supposed to address some of the pain of existing systems with the ML bits being a really nice bonus).
  - KenoFischer 5y ago
    Oh, I suppose I should add if you're looking to use something like this in a commercial setting, please feel free to reach out. Either directly to me, or just email info@ and you'll get routed to the right place.
- ChrisRackauckas 5y ago
  For the earliest details, see the press release from our DARPA project: https://juliacomputing.com/media/2021/03/darpa-ditto/ https://juliacomputing.com/media/2021/03/darpa-ditto/ . This is being done in a way where a fully usable software is the result, so that those accelerations are not just a one-off prototype but a product that everyone else can use by the end. For more details, wait until next week's JuliaCon.
caleb-allen 5y ago
Congratulations to Julia Computing!
NeutralForest 5y ago
Congrats, it's a big step in the right direction to support Julia development!
darksaints 5y ago
I'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.
- meowkit 5y ago
  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.
- mbauman 5y ago
  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_computing https://julialang.org/blog/2019/02/julia-entities/#julia_com...
- KenoFischer 5y ago
  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.
  - jstx1 5y ago
    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.
deleted 5y ago
[deleted]
awaythrowact 5y ago
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 academica closely resemble an academic HPC project (eg Pumas). I think it will continue to have success in that niche. And that's not a small niche! Maybe it's enough to support a billion dollar company. But most of us in industry are not in that niche. Most companies are not dealing with truly big data, on our scale, it is cheaper to expand the cluster than it is to rewrite everything in Julia. Most who ARE dealing with truly big data, do not need innovative code; basic summary statistics and logistic regression will be good enough, or maybe some cloud provider's prepackaged turn key neural nets scale out training system if they want to do something fancy. I think for Julia to have an impact outside of academia (and academia-like things in industry) it will need to develop killer app packages. The next PyTorch needs to be written in Julia. Will that happen? Maybe! I hope so! The world would be better off with more cool data science packages. But I think the sales pitch of "it's like Pandas and scikit but faster!" is not going to win many converts. So is Jax, Numba, Dask, Ray, Pachyderm, and the many other attempts within the Python community of scaling and speeding Python, that require much less work and expense on my part for the same outcome. Again, congrats to the team, I will continue to follow Julia closely, and I'm excited to see what innovative capabilities come out of the Julia ecosystem for data scientists like me.
- krastanov 5y ago
  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.
  - ampdepolymerase 5y ago
    Those two niches don't pay. They are effectively useless outside of the occasional evangelism on HN.
hawk_ 5y ago
it's not obvious to me what's their revenue model?
- KenoFischer 5y ago
  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 :).
  - hawk_ 5y ago
    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)
    - KenoFischer 5y ago
      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.
      - hpcjoe 5y ago
        FWIW: I am using it as a general purpose language at the intersection of large data sets, analytics, and related bits. At a prop shop. YMMV, but I find it is fantastic in this use case. And I don't have to worry about semantic space.
      - snicker7 5y ago
        Lots of finance companies shell out a lot of money for KDB+, a fast real-time database. Other than performance, the main selling point is that it comes with its own imperative language (K/Q). You can build entire API's and trading systems in Q: persistence, load balancing, streaming analytics, &tc. In that way, Q solves a different "two-language problem". There are not many serious competitors. If Julia had its own lean realtime database implementation, then I can see it becomming a killer language for finance. JuliaDB/OnlineStats is probably 60% of the way there.
gfodor 5y ago
Congrats Julia team!
- StefanKarpinski 5y ago
  Thanks, man :D
mccoyb 5y ago
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-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.
mr_overalls 5y ago
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)?
- lycopodiopsida 5y ago
  “Only” to write a very high amount of high-quality statistical and plot packages…
  - mr_overalls 5y ago
    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.
    - tylermw 5y ago
      "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-the-fastest-dataframe-libraries/ https://www.ritchievink.com/blog/2021/02/28/i-wrote-one-of-t...
      - mbauman 5y ago
        > The fastest data.frame library in ALL interpreted languages is consistently data.table, which is R. DataFrames.jl is very rapidly catching up and starting to surpass it. After hitting a stable v1.0 they've begun focusing on performance and those benchmarks have changed significantly over the past three months. Here's the live view: https://h2oai.github.io/db-benchmark/ https://h2oai.github.io/db-benchmark/
        nojito 5y ago
alfalfasprout 5y ago
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 a true game changer for ML in industry.
- tbenst 5y ago
  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
  - amkkma 5y ago
    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
    - Royi 5y ago
      Do you have updated comparison with some data of performance and memory vs. PyTorch / TF?
      - amkkma 5y ago
        I don't have a comprehensive suite of numbers at the moment (which is why I qualified it with "I believe"). My tentative conclusion is based on experience by a flux maintainer benchmarking forwards and backwards passes compared to pytorch, along with reports like this: https://discourse.julialang.org/t/flux-came-a-long-way/62288 https://discourse.julialang.org/t/flux-came-a-long-way/62288
didip 5y ago
Will there be a JupyterHub-like written in Julia in the near future, then? Because that's clearly where the money is.
- notthemessiah 5y ago
  I honestly haven't thought much about Jupyter since I moved to Pluto.jl (Observable-style reactive notebook): https://github.com/fonsp/Pluto.jl https://github.com/fonsp/Pluto.jl
- amkkma 5y ago
  It exists in the form of https://juliahub.com/lp/ https://juliahub.com/lp/
gnicholas 5y ago
Are A-rounds now well into the $20M range? I remember when they hit $10M and assumed they had continued to grow somewhat. But I didn't realized we'd blown well past $20M — when did that happen?
- oscardssmith 5y ago
  I think a lot of it is that this is a series A for a 6 year old company that is already making money. Most other startups would be on series B, so comparing this number to a 10 person startup for a company that doesn't have a product yet doesn't make a lot of sense.
  - mrits 5y ago
    I don't have recent data but I'd guess most startups would have been dead for several years, not on series B.
sneilan1 5y ago
I'm confused as to why Julia, a programming language is worth so much money. If the makers of Julia have already given away their source code here, https://github.com/JuliaLang/julia https://github.com/JuliaLang/julia what are they selling that's worth a 24 million series A round? Is the Julia business model similar to Redhat or Canonical where they sell consulting services?
- amkkma 5y ago
  Hi. Good question. This is addressed in several places in the comment thread by Keno and Chris.
  - sneilan1 5y ago
    Thank you. I'll do a search for that.
- freemint 5y ago
  Julia Computing is a company that employs (some of) the core contributors of Julia and develops enterprise solutions. Such as: - the first Julia IDE Juni now depreciated. - On premise package server - A wrapper over AWS called JuliaRun that has a nice web interface - paid "we make a core developer stare at RR traces of your problems" - FDA approved software for drug development and pharmacokinetics as https://juliacomputing.com/products/pumas/ https://juliacomputing.com/products/pumas/ It is not the programming language that is the product.
infogulch 5y ago
Congrats! I tried Julia for the first time last week and it was great. I've been playing with the idea of defining a hash function for lists that can be composed with other hashes to find the hash of the concatenation of the lists. I tried to do this with matrix multiplication of the hash of each list item, but with integer mod 256 elements random matrices are very likely to be singular and after enough multiplications degenerates to the zero matrix. However, with finite field (aka Galois fields) elements, such a matrix is much more likely to be invertible and therefore not degenerate. But I don't really know anything about finite fields, so how should I approach it? Here's where Julia comes in: with some help I was able to combine two libraries, LinearAlgebraX.jl which has functions for matrices with exact elements, with GaloisFields.jl which implements many types of GF, and wrote up a working demo implementation of this "list hash" idea in a Pluto.jl [2] notebook and published it [0] (and a question on SO [1]) after a few days without having any Julia experience at all. Julia seems pretty approachable, has great libraries, and is very powerful (I was even able to do a simple multithreaded implementation in 5 lines). [0]: https://blog.infogulch.com/2021/07/15/Merklist-GF.html https://blog.infogulch.com/2021/07/15/Merklist-GF.html [1]: https://crypto.stackexchange.com/questions/92139/using-random-invertible-matrices-over-finite-fields-to-define-the-hash-of-a-list?noredirect=1&lq=1 https://crypto.stackexchange.com/questions/92139/using-rando... [2]: https://github.com/fonsp/Pluto.jl https://github.com/fonsp/Pluto.jl
spywaregorilla 5y ago
I played with Julia a bit in grad school. Although I didn't end up using it much after that I thought it was a lovely language. Forget python, I hope Julia manages to kill off Matlab and its weird stranglehold on various pockets of academia. Congrats to the team here.
- mint2 5y ago
  Matlab, the SAS of academia and certain engineering fields.
  - helmholtz 5y ago
    I won't hear of it. Matlab is great. Superb at manipulating matrices, great for getting started with differential equations, world-class plotting library, and massively forgiving. All the things a computational engineer like me needs. I would never use it for producing software meant for distribution, but people mainly hate on it because it's 'cool', without realising that it excels at what it does. I fucking love matlab.
    - swordsmith 5y ago
      +1 on this. Matlab toolboxes are much more well tested, has thorough documentation and work much better out of the box, especially for controls and signal processing. Working with scipy can be a pain sometimes with incorrect or unstable results.
    - maybelsyrup 5y ago
      I know little about Matlab, but I know a lot about SAS, where it's the default analytical environment in public health practice and research. SAS is trash, and a ripoff to boot. R has made good inroads, giving SAS a tiny bit of pressure, but frankly it needs more. Bring on Julia! And python and anything else.
      - xiaodai 5y ago
        that's why SAS developed Viya so you can run Python and R code.
tvladeck 5y ago
I would really love to use Julia, and for my team to as well. But we are too locked into R to even begin. If I were these folks, I would focus on the flow, not stock, of data analysts. Get the next generation locked in to Julia. Turn R into SPSS
- cauthon 5y ago
  They have to offer a plotting library that’s at least half as decent as ggplot if they want people to jump ship. Gotta be able to visualize your results easily and they’ve been stuck with a half-baked interface to python plotting libraries for years
  - moelf 5y ago
    http://makie.juliaplots.org/stable/ http://makie.juliaplots.org/stable/ hopefully will soon be a dominant force in this direction
aazaa 5y ago
> Julia Computing, founded by the creators of the Julia high-performance programming language, today announced the completion of a $24M Series A fundraising round led by Dorilton Ventures, with participation from Menlo Ventures, General Catalyst, and HighSage Ventures. ... What products/services does Julia Computing sell to justify that Series A? The article doesn't mention anything. Although the company website lists some "products," there are no price tags or subscription plans attached to anything. And even if there are revenue-generating products/services on the horizon, how will the company protect itself from smaller, more nimble competitors that don't have a platform obligation to fulfill? How is this not another Docker? Don't get me wrong, both Julia and Docker are amazing, but have we entered the phase of the VC-funded deliberate non-profit?
- mbauman 5y ago
  > What products/services does Julia Computing sell to justify that Series A? The article doesn't mention anything. That's the entire second paragraph of the article. JuliaHub is a paid cloud computing service for running Julia code and JuliaSim/JuliaSPICE/Pumas are paid domain-specific modeling and simulation products. See also some of the other comments here from Keno[1] and Chris Rackauckas[2]: 1. https://news.ycombinator.com/item?id=27884386 https://news.ycombinator.com/item?id=27884386 2. https://news.ycombinator.com/item?id=27887122 https://news.ycombinator.com/item?id=27887122
  - aazaa 5y ago
    I'm equating "product" with "revenue-generating product." A bit presumptuous, I know, (the objective of a company is to make money from those who buy its products and services, where products and services are something other than shares) but the article doesn't mention any source of revenue for the company.
    - mbauman 5y ago
      Yes, that's what I figured you meant, and that's precisely what that paragraph and my comment above detail. You can enter a credit card into JuliaHub and start running large scale distributed compute on CPUs and GPUs right now. Or you can email us about procuring an enterprise version for your whole team and/or licensing JuliaSim or Pumas.
deleted 5y ago
[deleted]
DreamScatter 5y ago
I just quit using Julia language and am switching to Wolfram language. Well, I still might use Julia personally in the future, but my days of contributing to the community are over. The julia community is thankless, and the people at Julia computing are mean spirited and they think it's acceptable to harm people having good intentions (like me), having contributed thousands of hours of free time to help people on their forum and releasing my own packages used by thousands of people. Julia Computing just raised a bunch of money, but they are just pocketing it for themselves while they stomp their foot on people they perceive as unworthy. Yea, it's a good language, but the people behind it are very selfish and harmful to the free software community.
- fishmaster 5y ago
  Impressive FUD.
DreamScatter 5y ago
They are pocketing millions of dollars, but stomp their foot on the community. They are only hiring 5 more people, despite getting millions and millions of dollars. The people behind this project are not good well intentioned people. The language itself is great, due to the thankless work of many contributors who never got paid. The people behind the language are selfish and they intentionally harmed some Julia language projects, such as Grassmann.jl by banning valuable contributors who had good intentions and spent thousands of hours of their time contributing to the community.

378 points by dklend122 5y ago

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.

RandomWorker 5y ago
Basically, the syntax is similar to matlap as well as lots of the same features around functional and variable deceleration as python. The best thing for sure is the native support for parallel processing. Where python is single tread.
Kranar 5y ago
I think your question presupposes a lot of assumptions that may not be right. For one, I don't know that Julia is like a "big deal", certainly Python is the big deal in this field and I doubt Julia is looking to displace it wholesale. That said, Julia is a great addition to the scientific computing landscape because of its performance compared to other languages and its use of modern programming features. Python is just really really slow compared to Julia and parallelism in Python is a huge pain. Fortran is really really fast but that comes at a cost of being awkward to use and coming with a great deal of baggage. Julia is fast, feels modern, and has pretty easy parallelism. Then there's Matlab, Mathematica, and they are also pretty good but they're closed source/proprietary, so their ecosystem is mostly limited and driven by commercial interests. Nothing wrong with that intrinsically and they're all widely used but it's one way Julia differentiates itself, by making the language open and making money through services.
- ChrisRackauckas 5y ago
  Julia Computing is not a services company. There are commercial products built off of this stack which are the core of Julia Computing. For example, https://pumas.ai/ https://pumas.ai/ is a product for pharmacology modeling and simulation, and runs on the JuliaHub cloud platform of Julia Computing. It is already a big deal in the industry, with the quote everyone refers to "Pumas has emerged as our 'go-to' tool for most of our analyses in recent months" from the Director Head of Clinical Pharmacology and Pharmacometrics at Moderna Therepeutics during 2020 (for details, see the full approved press release from the Pumas.ai website). JuliaSim is another major product which is being released soon, along with JuliaSPICE publicly in the pipeline. But indeed, Julia Computing differentiates itself from something like MATLAB or Mathematica by leveraging a strong open source community on which these products are developed. These products add a lot of the details that are generally lacking in the open source space, such as strong adherents to file formats, regulatory compliance and validation, GUIs, etc. which are required to take such a product from "this guy can use it" to a fully marketable product usable by non-computational scientists. I will elaborate a bit more on this at JuliaCon next week in my talk on the release of JuliaSim.
  - codekilla 5y ago
    Wanted to ask if JuliaDB is something that might get more development attention? Or will that remain a community project? (I see it’s been in need of a release for awhile.)
    - ChrisRackauckas 5y ago
      It is not in our current set of major products. That said, informal office discussions mentioned JuliaDB as recently as last week, so it's not forgotten. If there's a demonstrated market, say a need for new high-performance cloud data science tools as part of the pharmaceutical domains we work in, then something like JuliaDB could possibly be revived in the future (of course, this is no guarantee).
    - ViralBShah 5y ago
      In general, the community has discussed reviving the project (or at least the ideas and some of its codebase). Julia computing will also be contributing as part of that revival.
      - codekilla 5y ago
        Thank you both for the comments. I believe I remember early on there were some comparisons to kdb+/q. I think there is some pretty great potential with an offering like this (an in-memory database integrated with the language, coupled with solid static storage) from the Julia community going forward. I can envision some use cases in genomics/transcriptomics.
nvrspyx 5y ago
From what I understand, Julia is dynamically typed and similar to a scripting language like Python or Ruby, but is also compiled, so it has performance similar to C/C++ (it's also written in itself). It also has built-in support for parallelism, multi threading, GPU compute, and distributed compute. I'm sure others can provide more insight. I've only dabbled in it and haven't used it extensively in any sense of the word.
deleted 5y ago
[deleted]
oscardssmith 5y ago
Short answer is that it is (imo) by far the best language for writing generic and fast math. Multiple dispatch allows you to write math using normal notation and not have to jump through hoops to do so.
- enriquto 5y ago
  can you show a simple example of that? I tend to see multiple dispatch as a mental burden, (e.g.: when I see a function call, where will it be dispatched? the answer dependa on the types that I'm juggling, that may not even be visible at that point...)
  - oscardssmith 5y ago
    The key to make multiple dispatch work well is that you shouldn't have to think about what method gets called. For this to work out, you need to make sure that you only add a method to a function if it does the "same thing" (so don't use >> for printing for example). To Dr the benefit of this in action, consider that in Julia 1im+2//3 (the syntax for sqrt(-1)+2 thirds) works and gives you a complex rational number (2//3+1//1 im). To get this behavior in most other languages, you would have to write special code for complex numbers with rational coefficients, but in Julia this just works since complex and rational numbers can be constructed using anything that has arithmetic defined. This goes all the way up the stack in Julia. You can put these numbers in a matrix, and matrix multiplication will just work, you can plot functions using these numbers, you can do gpu computation with them etc. All of this works (and is fast) because multiple dispatch can pick the right method based on all the argument types.
    - enriquto 5y ago
      > make sure that you only add a method to a function if it does the "same thing" But this only concerns when I'm writing the code myself. If I read some code and I see a few nested function calls, there's a combinatorial explosion of possible types that gives me vertigo. > complex and rational numbers can be constructed using anything that has arithmetic defined. seriously? this does not seem right, it cannot be like that. If I build a complex number out of complex numbers, I expect a regular complex number, not a "doubly complex" number with complex coefficients, akin to a quaternion. Or do you? There is surely some hidden dirty magic to avoid that case.
CapmCrackaWaka 5y ago
It’s a solid combination of performance, easy syntax and flexible environment. A big drawback of Python is that any performant code is actually written in a lower level language, with foreign function calls. That’s not to say that there are no disadvantages to Julia. I personally see Julia as a beefed up, new and improved R.
leephillips 5y ago
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-club/ https://www.hpcwire.com/off-the-wire/julia-joins-petaflop-cl... 2 https://arstechnica.com/science/2020/10/the-unreasonable-effectiveness-of-the-julia-programming-language/ https://arstechnica.com/science/2020/10/the-unreasonable-eff...
- notafraudster 5y ago
  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 think it's a cool language and an increasingly vibrant ecosystem and have been consistently impressed when Julia devs have spoke at events I've attended)
  - _Wintermute 5y ago
    I think the argument is that most R users don't know C++. So Julia avoids the "2 language problem" that you get with modern scientific computing.
  - QuadmasterXLII 5y ago
    I think that's just being clumped in with "Use C++," which he mentioned as an option
    - galangalalgol 5y ago
      and the ffi adds a lot of overhead for granular data. Julia just works fast. My only friction has been offline development, which isn't well supported yet.
  - 5y ago
cbkeller 5y ago
Composability via dispatch-oriented programming, e.g. [1] It also pretty much solved my version of the two-language problem, but that means different things to different people so ymmv. [1] https://www.youtube.com/watch?v=kc9HwsxE1OY https://www.youtube.com/watch?v=kc9HwsxE1OY
axpy906 5y ago
My understanding is that it runs faster than native python and R. That said with Numba and other libraries, see no point.
- NeutralForest 5y ago
  It's easier to write Julia code than to deal with Numba tbh and the ecosystem around Julia makes the code composable which is often not the case if you write Numba code and have to deal with other libraries.
- tfehring 5y ago
  Numba is great for pure functions on primitive types but it breaks down when you need to pass objects around. PyPy is fantastic for single-threaded applications but doesn't play nicely with multiprocessing or distributed computing IME. Numpy helps for stuff you can vectorize, but there's a lot of stuff you can't (or can but shouldn't); it also brings lots of minor inconveniences by virtue of not being a native type - e.g., the code to JSON serialize a `Union[Sequence[float], np.ndarray]` isn't exactly Pythonic.
  - oscardssmith 5y ago
    Also, numpy has about a 100x overhead door small arrays (10 or fewer elements).
- danuker 5y ago
  > runs faster than native python and R That's a bit of an understatement. It's about as fast as C and Rust (ignoring JIT compilation time). https://julialang.org/benchmarks/ https://julialang.org/benchmarks/
- dklend122 5y ago
  Composability, speed, static analysis, type system, abstractions, user defined compiler passes, metaprogramming, ffi, soon static compilation, differentiability and more create an effect that far exceeds numba
duped 5y ago
There really aren't that many languages out there trying to be on the cutting edge of JIT for scientific computing with a great REPL experience. There are a few areas where developers have to prototype in a language like Python or MATLAB to design their systems, generate test data, and even just plot stuff during debugging then rewrite in C/C++ for speed. It's an enormous time sink that is prone to errors, and leads to terrible SWE culture. If Julia can provide both the REPL/debugging experience of a language like Python or MATLAB with a fast enough JIT to use in production it would be an enormous boon to productivity and robustness. There are a few limiting factors but I don't think they're absolute.
coldtea 5y ago
>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 they think it's made to be "a big deal", they surely have seen them. So, what could the answer to the question above be? Some objective number that shows Julia is 25.6% better than Java or Rust or R or whatever? But first, who said it's a "big deal"? It's just a language that has some development action, seems some adoption, and secured a modest fundng for its company. That's not some earth shattering hype (if you want to see that, try to read about when Java was introduced. Or, to a much lesser degree, Ada, for that matter). You use a language because you've evaluated it for your needs and agree with the benefits and tradeoffs. Julia is high level and at the same time very fast for numerical computing allowing you to keep a clean codebase that's not a mix of C, C++, Fortran and your "real" language, while still getting most of the speed and easy parallelization. It also has special focus on support for that, for data science, statistics, and science in general. It's also well designed. On the other hand, it has slow startup/load times, incomplete documentation, smaller ecosystem, and several smaller usability issues.
- cbkeller 5y ago
  While you have a valid perspective, the HN guidelines [1] do specifically ask us to assume good faith. [1] https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- exdsq 5y ago
  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.
agumonkey 5y ago
kinda tries to make coding like python but running like fortran (without having to resort side-batteries like numpy/scipy) designers seems to have a good amount of PLT knowledge and made good foundations
SatvikBeri 5y ago
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.
- xiaodai 5y ago
  did you end up using package compiler as well?
  - SatvikBeri 5y ago
    No, the pipelines are long enough that compilation time isn't a big issue.
ziotom78 5y ago
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 case. Its support for multiple dispatch and custom operators lets you to write very efficient code without sacrificing readability, which is a big plus. Support for HPC computing is very good too.
- amkkma 5y ago
  >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
  - ziotom78 5y ago
    Yeah, you are right, these limitations are not much of a matter of the language itself.
  - oxinabox 5y ago
    > For scripting, interpreted Julia is coming. Citation for this? Julia has had a built-in interpretted since 1.0, in 2017 use `--compile=min`, or `--compile=none` to make use of it. And JuliaInterpretter.jl has been working since 2018. Both are very slow -- slower than adding in the compile time for most applications. As I understand it, this is because a number of things in how the language works are predicated on having a optimizing JIT compiler. As is how the standard library and basically all packages are written. Julia is going to over time become nicer for scripting, just because of various improvements. In particular, I put more hope on caching native code than on any new interpreter.

KenoFischer 5y ago

I guess this would be a good place to mention that we're hiring for lots of positions, so if you would like to help build JuliaHub, or work on compilers, or come play with SDRs, please take a look at our job openings :) : https://juliacomputing.com/jobs/ https://juliacomputing.com/jobs/

p_j_w 5y ago
>or come play with SDRs This sounds like an absolute dream!
- paulgb 5y ago
  What's SDR in this context? Not software-defined radio, right? (Though I suppose Julia is a good fit for signal processing!)
  - KenoFischer 5y ago
    Yes, software-defined radio, we have a very broad set of interests, and that happens to be one of the open jobs :).
    - slownews45 5y ago
      Very cool. SDR's are in the process of taking over ham radio I think as well (give it another 5 years). So flexible.
    - p_j_w 5y ago
      Understandable if you can't answer this question, but how much work have you guys done with SDRs and arrays?
      - KenoFischer 5y ago
        This project is just starting, so I have hardware sitting on my desk and have used it a bit, but other than that not much.

sidpatil 5y ago

The article mentions a circuit simulation package named JuliaSPICE, but I can't find any intonation on it. Can someone please provide a link?

oscardssmith 5y ago
It's not released yet. Official announcement is happening at juliacon in 2 weeks
KenoFischer 5y ago
There's not really much public about it yet. There'll be a technical talk about it at JuliaCon and we're talking to initial potential customers about it, but it's not quite ready for the wider community yet. If you want some of the technical details, I talked about it a bit in this earlier thread https://news.ycombinator.com/item?id=26425659 https://news.ycombinator.com/item?id=26425659 about the DARPA funding for our neural surrogates work in circuits (which will be part of the product offering, though the larger product is a modern simulator + analog design environment, which is supposed to address some of the pain of existing systems with the ML bits being a really nice bonus).
- KenoFischer 5y ago
  Oh, I suppose I should add if you're looking to use something like this in a commercial setting, please feel free to reach out. Either directly to me, or just email info@ and you'll get routed to the right place.
ChrisRackauckas 5y ago
For the earliest details, see the press release from our DARPA project: https://juliacomputing.com/media/2021/03/darpa-ditto/ https://juliacomputing.com/media/2021/03/darpa-ditto/ . This is being done in a way where a fully usable software is the result, so that those accelerations are not just a one-off prototype but a product that everyone else can use by the end. For more details, wait until next week's JuliaCon.

caleb-allen 5y ago

Congratulations to Julia Computing!

NeutralForest 5y ago

Congrats, it's a big step in the right direction to support Julia development!

darksaints 5y ago

I'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.

meowkit 5y ago
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.
mbauman 5y ago
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_computing https://julialang.org/blog/2019/02/julia-entities/#julia_com...
KenoFischer 5y ago
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.
- jstx1 5y ago
  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.

deleted 5y ago

[deleted]

awaythrowact 5y ago

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 academica closely resemble an academic HPC project (eg Pumas). I think it will continue to have success in that niche. And that's not a small niche! Maybe it's enough to support a billion dollar company. But most of us in industry are not in that niche. Most companies are not dealing with truly big data, on our scale, it is cheaper to expand the cluster than it is to rewrite everything in Julia. Most who ARE dealing with truly big data, do not need innovative code; basic summary statistics and logistic regression will be good enough, or maybe some cloud provider's prepackaged turn key neural nets scale out training system if they want to do something fancy. I think for Julia to have an impact outside of academia (and academia-like things in industry) it will need to develop killer app packages. The next PyTorch needs to be written in Julia. Will that happen? Maybe! I hope so! The world would be better off with more cool data science packages. But I think the sales pitch of "it's like Pandas and scikit but faster!" is not going to win many converts. So is Jax, Numba, Dask, Ray, Pachyderm, and the many other attempts within the Python community of scaling and speeding Python, that require much less work and expense on my part for the same outcome. Again, congrats to the team, I will continue to follow Julia closely, and I'm excited to see what innovative capabilities come out of the Julia ecosystem for data scientists like me.

krastanov 5y ago
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.
- ampdepolymerase 5y ago
  Those two niches don't pay. They are effectively useless outside of the occasional evangelism on HN.

hawk_ 5y ago

it's not obvious to me what's their revenue model?

KenoFischer 5y ago
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 :).
- hawk_ 5y ago
  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)
  - KenoFischer 5y ago
    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.
    - hpcjoe 5y ago
      FWIW: I am using it as a general purpose language at the intersection of large data sets, analytics, and related bits. At a prop shop. YMMV, but I find it is fantastic in this use case. And I don't have to worry about semantic space.
    - snicker7 5y ago
      Lots of finance companies shell out a lot of money for KDB+, a fast real-time database. Other than performance, the main selling point is that it comes with its own imperative language (K/Q). You can build entire API's and trading systems in Q: persistence, load balancing, streaming analytics, &tc. In that way, Q solves a different "two-language problem". There are not many serious competitors. If Julia had its own lean realtime database implementation, then I can see it becomming a killer language for finance. JuliaDB/OnlineStats is probably 60% of the way there.

gfodor 5y ago

Congrats Julia team!

StefanKarpinski 5y ago
Thanks, man :D

mccoyb 5y ago

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

mr_overalls 5y ago

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)?

lycopodiopsida 5y ago
“Only” to write a very high amount of high-quality statistical and plot packages…
- mr_overalls 5y ago
  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.
  - tylermw 5y ago
    "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-the-fastest-dataframe-libraries/ https://www.ritchievink.com/blog/2021/02/28/i-wrote-one-of-t...
    - mbauman 5y ago
      > The fastest data.frame library in ALL interpreted languages is consistently data.table, which is R. DataFrames.jl is very rapidly catching up and starting to surpass it. After hitting a stable v1.0 they've begun focusing on performance and those benchmarks have changed significantly over the past three months. Here's the live view: https://h2oai.github.io/db-benchmark/ https://h2oai.github.io/db-benchmark/
      - nojito 5y ago

alfalfasprout 5y ago

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 a true game changer for ML in industry.

tbenst 5y ago
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
- amkkma 5y ago
  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
  - Royi 5y ago
    Do you have updated comparison with some data of performance and memory vs. PyTorch / TF?
    - amkkma 5y ago
      I don't have a comprehensive suite of numbers at the moment (which is why I qualified it with "I believe"). My tentative conclusion is based on experience by a flux maintainer benchmarking forwards and backwards passes compared to pytorch, along with reports like this: https://discourse.julialang.org/t/flux-came-a-long-way/62288 https://discourse.julialang.org/t/flux-came-a-long-way/62288

didip 5y ago

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

notthemessiah 5y ago
I honestly haven't thought much about Jupyter since I moved to Pluto.jl (Observable-style reactive notebook): https://github.com/fonsp/Pluto.jl https://github.com/fonsp/Pluto.jl
amkkma 5y ago
It exists in the form of https://juliahub.com/lp/ https://juliahub.com/lp/

gnicholas 5y ago

Are A-rounds now well into the $20M range? I remember when they hit $10M and assumed they had continued to grow somewhat. But I didn't realized we'd blown well past $20M — when did that happen?

oscardssmith 5y ago
I think a lot of it is that this is a series A for a 6 year old company that is already making money. Most other startups would be on series B, so comparing this number to a 10 person startup for a company that doesn't have a product yet doesn't make a lot of sense.
- mrits 5y ago
  I don't have recent data but I'd guess most startups would have been dead for several years, not on series B.

sneilan1 5y ago

I'm confused as to why Julia, a programming language is worth so much money. If the makers of Julia have already given away their source code here, https://github.com/JuliaLang/julia https://github.com/JuliaLang/julia what are they selling that's worth a 24 million series A round? Is the Julia business model similar to Redhat or Canonical where they sell consulting services?

amkkma 5y ago
Hi. Good question. This is addressed in several places in the comment thread by Keno and Chris.
- sneilan1 5y ago
  Thank you. I'll do a search for that.
freemint 5y ago
Julia Computing is a company that employs (some of) the core contributors of Julia and develops enterprise solutions. Such as: - the first Julia IDE Juni now depreciated. - On premise package server - A wrapper over AWS called JuliaRun that has a nice web interface - paid "we make a core developer stare at RR traces of your problems" - FDA approved software for drug development and pharmacokinetics as https://juliacomputing.com/products/pumas/ https://juliacomputing.com/products/pumas/ It is not the programming language that is the product.

infogulch 5y ago

Congrats! I tried Julia for the first time last week and it was great. I've been playing with the idea of defining a hash function for lists that can be composed with other hashes to find the hash of the concatenation of the lists. I tried to do this with matrix multiplication of the hash of each list item, but with integer mod 256 elements random matrices are very likely to be singular and after enough multiplications degenerates to the zero matrix. However, with finite field (aka Galois fields) elements, such a matrix is much more likely to be invertible and therefore not degenerate. But I don't really know anything about finite fields, so how should I approach it? Here's where Julia comes in: with some help I was able to combine two libraries, LinearAlgebraX.jl which has functions for matrices with exact elements, with GaloisFields.jl which implements many types of GF, and wrote up a working demo implementation of this "list hash" idea in a Pluto.jl [2] notebook and published it [0] (and a question on SO [1]) after a few days without having any Julia experience at all. Julia seems pretty approachable, has great libraries, and is very powerful (I was even able to do a simple multithreaded implementation in 5 lines). [0]: https://blog.infogulch.com/2021/07/15/Merklist-GF.html https://blog.infogulch.com/2021/07/15/Merklist-GF.html [1]: https://crypto.stackexchange.com/questions/92139/using-random-invertible-matrices-over-finite-fields-to-define-the-hash-of-a-list?noredirect=1&lq=1 https://crypto.stackexchange.com/questions/92139/using-rando... [2]: https://github.com/fonsp/Pluto.jl https://github.com/fonsp/Pluto.jl

spywaregorilla 5y ago

I played with Julia a bit in grad school. Although I didn't end up using it much after that I thought it was a lovely language. Forget python, I hope Julia manages to kill off Matlab and its weird stranglehold on various pockets of academia. Congrats to the team here.

mint2 5y ago
Matlab, the SAS of academia and certain engineering fields.
- helmholtz 5y ago
  I won't hear of it. Matlab is great. Superb at manipulating matrices, great for getting started with differential equations, world-class plotting library, and massively forgiving. All the things a computational engineer like me needs. I would never use it for producing software meant for distribution, but people mainly hate on it because it's 'cool', without realising that it excels at what it does. I fucking love matlab.
  - swordsmith 5y ago
    +1 on this. Matlab toolboxes are much more well tested, has thorough documentation and work much better out of the box, especially for controls and signal processing. Working with scipy can be a pain sometimes with incorrect or unstable results.
  - maybelsyrup 5y ago
    I know little about Matlab, but I know a lot about SAS, where it's the default analytical environment in public health practice and research. SAS is trash, and a ripoff to boot. R has made good inroads, giving SAS a tiny bit of pressure, but frankly it needs more. Bring on Julia! And python and anything else.
    - xiaodai 5y ago
      that's why SAS developed Viya so you can run Python and R code.

tvladeck 5y ago

I would really love to use Julia, and for my team to as well. But we are too locked into R to even begin. If I were these folks, I would focus on the flow, not stock, of data analysts. Get the next generation locked in to Julia. Turn R into SPSS

cauthon 5y ago
They have to offer a plotting library that’s at least half as decent as ggplot if they want people to jump ship. Gotta be able to visualize your results easily and they’ve been stuck with a half-baked interface to python plotting libraries for years
- moelf 5y ago
  http://makie.juliaplots.org/stable/ http://makie.juliaplots.org/stable/ hopefully will soon be a dominant force in this direction

aazaa 5y ago

> Julia Computing, founded by the creators of the Julia high-performance programming language, today announced the completion of a $24M Series A fundraising round led by Dorilton Ventures, with participation from Menlo Ventures, General Catalyst, and HighSage Ventures. ... What products/services does Julia Computing sell to justify that Series A? The article doesn't mention anything. Although the company website lists some "products," there are no price tags or subscription plans attached to anything. And even if there are revenue-generating products/services on the horizon, how will the company protect itself from smaller, more nimble competitors that don't have a platform obligation to fulfill? How is this not another Docker? Don't get me wrong, both Julia and Docker are amazing, but have we entered the phase of the VC-funded deliberate non-profit?

mbauman 5y ago
> What products/services does Julia Computing sell to justify that Series A? The article doesn't mention anything. That's the entire second paragraph of the article. JuliaHub is a paid cloud computing service for running Julia code and JuliaSim/JuliaSPICE/Pumas are paid domain-specific modeling and simulation products. See also some of the other comments here from Keno[1] and Chris Rackauckas[2]: 1. https://news.ycombinator.com/item?id=27884386 https://news.ycombinator.com/item?id=27884386 2. https://news.ycombinator.com/item?id=27887122 https://news.ycombinator.com/item?id=27887122
- aazaa 5y ago
  I'm equating "product" with "revenue-generating product." A bit presumptuous, I know, (the objective of a company is to make money from those who buy its products and services, where products and services are something other than shares) but the article doesn't mention any source of revenue for the company.
  - mbauman 5y ago
    Yes, that's what I figured you meant, and that's precisely what that paragraph and my comment above detail. You can enter a credit card into JuliaHub and start running large scale distributed compute on CPUs and GPUs right now. Or you can email us about procuring an enterprise version for your whole team and/or licensing JuliaSim or Pumas.

deleted 5y ago

[deleted]

DreamScatter 5y ago

I just quit using Julia language and am switching to Wolfram language. Well, I still might use Julia personally in the future, but my days of contributing to the community are over. The julia community is thankless, and the people at Julia computing are mean spirited and they think it's acceptable to harm people having good intentions (like me), having contributed thousands of hours of free time to help people on their forum and releasing my own packages used by thousands of people. Julia Computing just raised a bunch of money, but they are just pocketing it for themselves while they stomp their foot on people they perceive as unworthy. Yea, it's a good language, but the people behind it are very selfish and harmful to the free software community.

fishmaster 5y ago
Impressive FUD.

DreamScatter 5y ago

They are pocketing millions of dollars, but stomp their foot on the community. They are only hiring 5 more people, despite getting millions and millions of dollars. The people behind this project are not good well intentioned people. The language itself is great, due to the thankless work of many contributors who never got paid. The people behind the language are selfish and they intentionally harmed some Julia language projects, such as Grassmann.jl by banning valuable contributors who had good intentions and spent thousands of hours of their time contributing to the community.