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

Julia Computing raises $24M Series A

hpcwire.com

Post reply on HN
Print view View original

171–180 of 246 posts

Re: Julia Computing raises $24M Series A

#171

Post by gbrown »

awaythrowact wrote: post #165
amkkma wrote: post #154

Earlier quoted context omitted.

How is "model.fit(X,Y)" better than "fit!(model,X,Y)"? Julia is object oriented in a broad sense, it just uses multiple dispatch which is strictly more expressive than single dispatch, so doesn't make sense to have dot notation for calling methods because types don't own methods. For giving up some facility in function discover, you get speed, composability, generic code...and a net gain in usability because you can…

I'll give you my two cents, recognizing that I very well might just be ignorant about Julia and multiple dispatch, and if so please continue to educate me. Consider if we want to run many different types of models. Logistic regression, gradient boosting, NNs, etc. We want the ability to easily plug in any type of model into our existing code base. That's why model.fit(X,Y) is attractive. I just need to change "model…

Have you checked out MLJ? I think their interface does a pretty good job of what you're discussing.

Re: Julia Computing raises $24M Series A

#172

Post by ChrisRackauckas »

grumblenum wrote: post #96
hawk_ wrote: post #41

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

Uber for numpy, perhaps. The best case scenario would be like Oracle and JavaSE. I lack the imagination to speculate on the worst case, so I am quite surprised that anyone expects to make more than $24M in profit from yet another programming language . Particularly one which caters to the narrow intersection of one-off scripts/rapid iteration, efficient machine code generation, but without limitations on memory usage…

The product is not the programming language. As addressed in there and on this board, there's a healthy set of products around pharmaceutical modeling and simulation (Pumas-AI, adopted by groups like Moderna), a cloud compute service JuliaHub, multi-physics simulation tools (JuliaSim), and upcoming verticals like JuliaSPICE for circuit simulation. Each of these themselves are entrants into billion dollar industries with tools that are, in some cases, already outperforming the current market leaders in computational speed and are quickly getting modern reactive GUIs. The Julia part is simply that it was founded by the creators of the Julia programming language and this stack is then (of course) built in Julia, leveraging all of its tools to reach these speeds. But the product is not the language itself.

Re: Julia Computing raises $24M Series A

#173

Post by aazaa »

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

Re: Julia Computing raises $24M Series A

#174

Post by spenczar5 »

leephillips wrote: post #74
spenczar5 wrote: post #54

Earlier quoted context omitted.

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

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

> Note that no combination of any of the faster implementations of Python + Numpy libraries has ever been used at the most demanding level of scientific computation. That has always been Fortran, with some C and C++, and now Julia.

This still seems like an overstatement, but maybe it depends on what you mean by "most demanding level." I work on systems for the Rubin Observatory, which is going to be the largest astronomical survey by a lot. There's a bunch of C++ certainly, but heaps of Python. For example, catalog simulation (https://www.lsst.org/scientists/simulations/catsim) is pretty much entirely in Python.

Take a look at `lsst/imsim`, for example, from the Dark Energy collaboration at LSST: https://github.com/LSSTDESC/imSim.

Maybe this isn't the "most demanding" but I don't really know why.

> But if A and B are numpy arrays, then A + B will calculate the elementwise sum on a single core only, correct? It will vectorize, but not parallelize.

That's correct, but numba will parallelize the computation for you (https://numba.pydata.org/numba-doc/latest/user/parallel.html). It's pretty common to use numba's parallelization when relevant.

Re: Julia Computing raises $24M Series A

#175

Post by awaythrowact »

amkkma wrote: post #169
awaythrowact wrote: post #165

Earlier quoted context omitted.

I'll give you my two cents, recognizing that I very well might just be ignorant about Julia and multiple dispatch, and if so please continue to educate me. Consider if we want to run many different types of models. Logistic regression, gradient boosting, NNs, etc. We want the ability to easily plug in any type of model into our existing code base. That's why model.fit(X,Y) is attractive. I just need to change "model…

Thanks, I see where you are coming from. >It should be the responsibility of the developer of "model" to select the "fit" algorithm appropriate for "model." (They don't have to implement it, but they do have to import the right one.) The developer of "fit" should not be responsible for handling every possible "model" type. You could have the developer of "model" override / extend the definition of "fit" but that open…

I agree you can achieve same benefits with Macros. Indeed, I see that MLJ, Julia's attempt at a SciKit type project, makes extensive use of Macros. But I personally think macros are an antipattern. In large projects, they can introduce subtle bugs. Especially if you're using multiple modules that are each editing your code before compile time and that don't know about each other. I know others in Julia community agree that Macros are dangerous.

I think abstract types are a brittle solution. The "can of worms" I alluded to is something like this: Library TensorFlow implements model "nn" and Library PyTorch also implements model "nn" and they both want to override "fit" to handle the new type "nn"... Good luck combining them in the same codebase. This problem is less pronounced in OOP where each development team controls their own method. Julia devs can solve this by having every developer of every "fit" function and every developer of every "model" struct agree beforehand on a common abstraction, but that's an expensive, brittle solution that hurts innovation velocity.

I think the closest I can do in Julia via pure structs is for the developer to define and expose their preferred fit function as a variable in the struct, something like "fit = model['fit_function']; fit(model,X,Y)" but that introduces a boilerplate tax with every method I want to call (fit, predict, score, cross validate, hyperpameter search, etc). (EDIT: indeed, I think this is pretty much what MLJ is doing, having each model developer expose a struct with a "fit" and "predict" function, and using the @load macro to automate the above boilerplate to put the right version of "fit" into global state when you @load each model... but as described above, I don't like macro magic like this.)

Re: Julia Computing raises $24M Series A

#176

Post by spenczar5 »

maxnoe wrote: post #69
spenczar5 wrote: post #54

Earlier quoted context omitted.

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

Numba essentially does the same as julia, compile to llvm bytecode, in julia, that's a language design decision, in python it is a library. You can get very far with these approaches I python, but having these at the language level just has more potential for optimization and less friction. The debugability of numba code is very limited and code coverage does ot work at all. Having a high level language that has scie…

I agree that numba's JITted code needs debuggability improvements. I've been working on getting it to work with Linux's perf(1) for that reason.

The Julia-for-astronomy community is just microscopic right now, so it's hard to find useful libraries. Nothing comes close to, say, Astropy[0].

I'm not a huge fan of the current numpy stack for scientific code. I just don't think anyone should get too carried away and claim that Julia is taking the entire scientific world by storm. I don't know anyone in my department who has even looked at it seriously.

[0] https://www.astropy.org/

Re: Julia Computing raises $24M Series A

#177

Post by helmholtz »

mint2 wrote: post #158
spywaregorilla wrote: post #123

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.

Matlab, the SAS of academia and certain engineering fields.

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.

Re: Julia Computing raises $24M Series A

#178

Post by wickedsickeune »

mint2 wrote: post #158
spywaregorilla wrote: post #123

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.

Matlab, the SAS of academia and certain engineering fields.

I guess you mean SAP?

Re: Julia Computing raises $24M Series A

#179

Post by swordsmith »

helmholtz wrote: post #177
mint2 wrote: post #158

Earlier quoted context omitted.

Matlab, the SAS of academia and certain engineering fields.

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 ma…

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

Re: Julia Computing raises $24M Series A

#180

Post by mbauman »

aazaa wrote: post #173

> 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 list…

> 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

2. https://news.ycombinator.com/item?id=27887122

Post reply on HN