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

211–220 of 246 posts

Re: Julia Computing raises $24M Series A

#211

Post by freemint »

leephillips wrote: post #164
systemvoltage wrote: post #157

Earlier quoted context omitted.

I’m a tortured soul, my opinions might be biased and I hope things improve with Julia. We absolutely cannot upgrade Julia version right now, dozens of repos full of complicated scientific code. Management doesn’t care as far as it barely runs. I don’t think it’s fair to blame Julia for it but it just shows how much more it needs to go. That should be looked at as a positive thing. I have one more complain to Julia co…

Well you’re right about the libraries—Python really does have everything (although sometimes those libraries are not great quality, but at least they mostly work). But Julia makes it easy to use Python libraries with Pycall. And there are big things that just don’t exist yet in the Julia world, such as a web framework. I recently tried to create a web project using Genie.jl, which advertises itself as a ready-for-pri…

Have you made the Genie maintenainers aware of your problems?

Re: Julia Computing raises $24M Series A

#212

Post by freemint »

east2west wrote: post #167
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 don't miss OOP in Julia but I do feel there need to be more ways to abstract things than multiple dispatch and structs. One thing I do miss is interfaces, which can group functions for a common purpose. I understand it may be not feasible in a dynamic language, but hopefully there will be something above functions as an abstraction mechanism.

Interfaces are not currently defined in the language but socially if you are lucky the package whose abstract type you subtype has a generic test you can call with your new implementation but that is not the standard.

Re: Julia Computing raises $24M Series A

#213

Post by freemint »

randomswede wrote: post #209
awaythrowact wrote: post #175

Earlier quoted context omitted.

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

None of these require macros. If (and only if, I have not looked at our hypothetical model and fit GF, but for the sake of argument, I will assume that it does) "fit" specialises on "model" will a "mode = AnOtherModel" cause "fit(model, x, y)" to be exquivalet to Python's "model.fit(x, y)". If you need to provide a custom "fit" method, you do so by providing a method specialised on AnOtherModel to the "fit" GF. At no…

Your explanation is stop on for Julia.

Re: Julia Computing raises $24M Series A

#214

Post by SatvikBeri »

xiaodai wrote: post #207
SatvikBeri wrote: post #52

Earlier quoted context omitted.

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.

did you end up using package compiler as well?

No, the pipelines are long enough that compilation time isn't a big issue.

Re: Julia Computing raises $24M Series A

#215

Post by awaythrowact »

randomswede wrote: post #209
awaythrowact wrote: post #175

Earlier quoted context omitted.

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

None of these require macros. If (and only if, I have not looked at our hypothetical model and fit GF, but for the sake of argument, I will assume that it does) "fit" specialises on "model" will a "mode = AnOtherModel" cause "fit(model, x, y)" to be exquivalet to Python's "model.fit(x, y)". If you need to provide a custom "fit" method, you do so by providing a method specialised on AnOtherModel to the "fit" GF. At no…

I know nothing about Lisp, so at the risk of talking past eachother....

I never said macros were required. I said implementing this type of code without OOP required more boilerplate, and MLJ uses macros to reduce that boilerplate.

As I understand module imports in Julia: Each module developer exports a list of publicly facing objects. Obviously "fit" and "model" would be among them. If you import two modules that both export a new "nn" subtype of shared parent type "model", and both extend "fit" and "predict" and etc to accept their own subtype "nn", then you have to manually specify which module you are referring to every time you call nn, or fit, or predict, or whatever. Is that wrong? If I just import PyTorch, import TensorFlow, and then call "mymodel = TensorFlow.nn; fit(mymodel, mydata)" then Julia doesn't know that the "fit" I am calling is the TensorFlow implementation and not the PyTorch implementation; what if I had WANTED to use module A's "fit" on module B's model, and they intentionally adopted the same abstract type system to enable this interoperability? So instead I have to write "mymodel = TensorFlow.nn; TensorFlow.fit(mymodel, mydata); TensorFlow.predict(mymodel, mynewdata)". Obviously the extra typing is mildly annoying but the bigger problem is potentially introducing bugs by mismatching modules, and the developer's cognitive overload of having to keep track of modules. Python style OOP is a more elegant solution to the namespace problem and results in more readable, maintainble code, at least in my opinion. Anyways, maybe Julia has a more elegant solution I'm not aware of, if so I'd love to hear it.

Re: Julia Computing raises $24M Series A

#216

Post by cbkeller »

awaythrowact wrote: post #215
randomswede wrote: post #209

Earlier quoted context omitted.

None of these require macros. If (and only if, I have not looked at our hypothetical model and fit GF, but for the sake of argument, I will assume that it does) "fit" specialises on "model" will a "mode = AnOtherModel" cause "fit(model, x, y)" to be exquivalet to Python's "model.fit(x, y)". If you need to provide a custom "fit" method, you do so by providing a method specialised on AnOtherModel to the "fit" GF. At no…

I know nothing about Lisp, so at the risk of talking past eachother.... I never said macros were required. I said implementing this type of code without OOP required more boilerplate, and MLJ uses macros to reduce that boilerplate. As I understand module imports in Julia: Each module developer exports a list of publicly facing objects. Obviously "fit" and "model" would be among them. If you import two modules that bo…

In Julia it will just dispatch to the correct function.

In other words, one package would define `fit(mymodel::TensorFlowModel)` and the other would define `fit(mymodel:PyTorchModel)`, and then when you call `fit` it'll just dispatch to the appropriate one depending on the type of `mymodel`.

This dispatch-oriented style also allows a shocking degree of composability, e.g. [1], where a lot of packages will just work together, such that you could for example just use the equivalent of PyTorch or TensorFlow on the equivalent of (e.g.) NumPy arrays without having to convert anything.

If you mean "what about the case where both packages just call their model type `Model`", while I've never run into that, the worst case scenario is just that you have to fall back to the Python style explicit Module.function usage (which was always allowed anyways...). And if you if you don't like names being exported, you can always just `import` a package instead of `using` it:

  help?> import
  search: import

  import

  import Foo will load the module or package Foo. Names from the imported Foo module can
  be accessed with dot syntax (e.g. Foo.foo to access the name foo). See the manual
  section about modules for details.
[1] https://www.youtube.com/watch?v=kc9HwsxE1OY

Re: Julia Computing raises $24M Series A

#217

Post by [deleted] »

awaythrowact wrote: post #215
randomswede wrote: post #209

Earlier quoted context omitted.

None of these require macros. If (and only if, I have not looked at our hypothetical model and fit GF, but for the sake of argument, I will assume that it does) "fit" specialises on "model" will a "mode = AnOtherModel" cause "fit(model, x, y)" to be exquivalet to Python's "model.fit(x, y)". If you need to provide a custom "fit" method, you do so by providing a method specialised on AnOtherModel to the "fit" GF. At no…

I know nothing about Lisp, so at the risk of talking past eachother.... I never said macros were required. I said implementing this type of code without OOP required more boilerplate, and MLJ uses macros to reduce that boilerplate. As I understand module imports in Julia: Each module developer exports a list of publicly facing objects. Obviously "fit" and "model" would be among them. If you import two modules that bo…

[deleted]

Re: Julia Computing raises $24M Series A

#218

Post by [deleted] »

cbkeller wrote: post #216
awaythrowact wrote: post #215

Earlier quoted context omitted.

I know nothing about Lisp, so at the risk of talking past eachother.... I never said macros were required. I said implementing this type of code without OOP required more boilerplate, and MLJ uses macros to reduce that boilerplate. As I understand module imports in Julia: Each module developer exports a list of publicly facing objects. Obviously "fit" and "model" would be among them. If you import two modules that bo…

In Julia it will just dispatch to the correct function. In other words, one package would define `fit(mymodel::TensorFlowModel)` and the other would define `fit(mymodel:PyTorchModel)`, and then when you call `fit` it'll just dispatch to the appropriate one depending on the type of `mymodel`. This dispatch-oriented style also allows a shocking degree of composability, e.g. [1], where a lot of packages will just work t…

[deleted]

Re: Julia Computing raises $24M Series A

#219

Post by aazaa »

mbauman wrote: post #189
aazaa wrote: post #183

Earlier quoted context omitted.

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.

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.

Where do I find payment rates/plans information? On the "Pricing" page:

https://juliahub.com/lp/pricing

I see Free, Pay as You Go, and Contact Sales.

Clicking the middle option, I see that I must be logged in to view anything.

What you want to do with this information is up to you, but it doesn't look good from the customer side. And from the perspective of someone trying to figure out if Julia Computing has a future as a money-making enterprise, it looks iffy at best.

Re: Julia Computing raises $24M Series A

#220

Post by awaythrowact »

cbkeller wrote: post #216
awaythrowact wrote: post #215

Earlier quoted context omitted.

I know nothing about Lisp, so at the risk of talking past eachother.... I never said macros were required. I said implementing this type of code without OOP required more boilerplate, and MLJ uses macros to reduce that boilerplate. As I understand module imports in Julia: Each module developer exports a list of publicly facing objects. Obviously "fit" and "model" would be among them. If you import two modules that bo…

In Julia it will just dispatch to the correct function. In other words, one package would define `fit(mymodel::TensorFlowModel)` and the other would define `fit(mymodel:PyTorchModel)`, and then when you call `fit` it'll just dispatch to the appropriate one depending on the type of `mymodel`. This dispatch-oriented style also allows a shocking degree of composability, e.g. [1], where a lot of packages will just work t…

I very frequently run into namespace collisions like that. I think they are quite common in large codebases.

I am aware of the ability to do eg "import TensorFlow; model = TensorFlow.model; TensorFlow.fit(model,data)"

As I mentioned previously, I find Python's OOP "model.fit" syntax to be better, for a variety of reasons.

Thank you for your engagement. Have a nice day.

Post reply on HN