Hacker News Re-Imagined

Julia Computing Raises $24M Series A

4 hours ago

Created a post 277 points @dklend122

Julia Computing Raises $24M Series A

@mccoyb 2 hours

Replying to @dklend122 🎙

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.

Reply


@caleb-allen 3 hours

Replying to @dklend122 🎙

Congratulations to Julia Computing!

Reply


@didip 1 hour

Replying to @dklend122 🎙

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

Reply


@mr_overalls 2 hours

Replying to @dklend122 🎙

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

Reply


@NeutralForest 3 hours

Replying to @dklend122 🎙

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

Reply


@djhaskin987 3 hours

Replying to @dklend122 🎙

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.

Reply


@gnicholas 1 hour

Replying to @dklend122 🎙

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?

Reply


@KenoFischer 3 hours

Replying to @dklend122 🎙

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/

Reply


@sidpatil 3 hours

Replying to @dklend122 🎙

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

Reply


@infogulch 53 minutes

Replying to @dklend122 🎙

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

[1]: https://crypto.stackexchange.com/questions/92139/using-rando...

[2]: https://github.com/fonsp/Pluto.jl

Reply


@tvladeck 6 minutes

Replying to @dklend122 🗣

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

Reply


@spywaregorilla 51 minutes

Replying to @dklend122 🎙

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.

Reply


@awaythrowact 2 hours

Replying to @dklend122 🎙

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.

Reply


@alfalfasprout 1 hour

Replying to @dklend122 🎙

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.

Reply


@hawk_ 2 hours

Replying to @dklend122 🎙

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

Reply


@sneilan1 1 hour

Replying to @dklend122 🎙

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

Reply


@darksaints 2 hours

Replying to @dklend122 🎙

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.

Reply


@gfodor 2 hours

Replying to @dklend122 🎙

Congrats Julia team!

Reply


About Us

site design / logo © 2021 Box Piper