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

231–240 of 246 posts

Re: Julia Computing raises $24M Series A

#231

Post by amkkma »

awaythrowact wrote: post #228
cbkeller wrote: post #227

Earlier quoted context omitted.

Oh, I see -- yes, fair enough!

Just to be clear, I like Julia, and think it has advantages over Python. I'm writing all this as someone who is cheering for Julia to break out of its HPC niche. Thanks.

Thanks so much for taking the time to outline your thoughts...I share the same goals and input from industry experience like this very valuable. This has spawned some discussion on the Julia slack about how best to target your usecase.

Can I trouble you to make a post either on discourse or on the slack? I'd really like this to get in front of the broader julia community and core devs, and you're the best person to do that. Maybe there's a solution of which I'm unaware....or there could be some design discussions to come out of this.

https://julialang.org/community/ (slack and discourse link)

Re: Julia Computing raises $24M Series A

#232

Post by awaythrowact »

amkkma wrote: post #231
awaythrowact wrote: post #228

Earlier quoted context omitted.

Just to be clear, I like Julia, and think it has advantages over Python. I'm writing all this as someone who is cheering for Julia to break out of its HPC niche. Thanks.

Thanks so much for taking the time to outline your thoughts...I share the same goals and input from industry experience like this very valuable. This has spawned some discussion on the Julia slack about how best to target your usecase. Can I trouble you to make a post either on discourse or on the slack? I'd really like this to get in front of the broader julia community and core devs, and you're the best person to d…

Always happy to help. Especially the last day or so - I've been waiting on some long training loops so it's been a pleasant diversion.

To be 100% honest with you, there's pretty much 0% chance of me adopting Julia in the next 12 months. I evaluated it before embarking on my current project, but ended up going with Python, and now I have several thousand lines of Python code that work fine, and I'm not going to rewrite it all in the near future. At some point in the medium term, I'll re-evaluate Julia. But until then, I don't want to lead anyone on any wild goose chase. Even if you solved this problem, and all my problems, I'm just not in a position to switch right now. So for that reason I think I'll hold off on issuing a community wide call for help. But I'm cautiously optimistic that at some point in the future I'll be writing Julia professionally.

A lot of this is also probably cultural rather than language features. The first thing they teach any Python data science boot camp initiate is: never "from numpy import *", always "import numpy as np" and yet in Julia "using" appears more common than "import"...

I also wouldn't read too much into my one example. It was initially meant just as an illustrative point, but somehow I was so bad at explaining it that it took tons of comments for me to get my minor point across. I do think the MLJ guys are properly on the right track, and that should work fine for most people who don't mind Macros. Maybe I'm in the minority in hating Macros.

The more commonly cited issues around compile time caching, tooling, etc. are boring to list off yet again, but probably the right areas of focus for the community, in terms of both impact and ease of implementation.

More generally, I really do think you're better off talking to people like @systemvoltage, who have actually given Julia more of a chance than I have. If I worked for Julia Computing I'd be reaching out to him and begging to get his brain dump on all the challenges he faced. In any business, it's always easier to reduce churn and learn from your (unhappy) customers, then it is to convert new prospects, whether that business is programming languages or investment banking.

Best of luck. Sincerely.

Re: Julia Computing raises $24M Series A

#233

Post by Royi »

amkkma wrote: post #101
tbenst wrote: post #94

Earlier quoted context omitted.

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

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

Do you have updated comparison with some data of performance and memory vs. PyTorch / TF?

Re: Julia Computing raises $24M Series A

#234

Post by fishmaster »

DreamScatter wrote: post #223

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

Impressive FUD.

Re: Julia Computing raises $24M Series A

#235

Post by StefanKarpinski »

jpeloquin wrote: post #196
oscardssmith wrote: post #166

Earlier quoted context omitted.

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…

> 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). Thanks for writing this. I think it is an important concept for getting started with Julia. When I tried Julia, I was initially confused and concerned…

This is an important point: abstractions like generic functions are only as good as how much people respect them, and enforcement of that is largely cultural. You can add technological levels of enforcement, but those are limited at best because people are brilliantly devious and can find ways to break any technological enforcement if they set their minds to it; the key to preventing that is convincing them to set their minds to respecting abstractions instead.

For a negative example of this, C++ introduced function overloading — which is a static and therefore broken version of multiple dispatch (that calls the wrong “methods” based only on static type information). They then immediately decided to abuse the bitshift operators for I/O — in the standard library, no less. (There are other abuses of overloading but this is the most famous one.) So that didn’t exactly create a culture where people respect the semantic meaning of overloaded functions. As a result, C++ has given function overloading a really horrible reputation. Partly because it is likely to be not actually so what you want because it’s static rather than based on the actual types of arguments, but even more so because there’s no culture of semantic consistency in C++, starting from the standard library itself — you cannot trust anyone to respect the meaning of anything, not even the language authors.

In Julia, on the other hand, we’ve always been very strict about this: don’t add a method to a function unless it means the same thing. We would never dream of using bitshift operators to do I/O. Since meaning is the level where human thinking operates, this makes it reasonable to write generic code that works the way you meant it to: you can call `+` on two things and just trust that whoever has implemented `+` for those objects didn’t decide to make it append a value to an array or something wonky like that. Not that people haven’t proposed that kind of thing, but because of the culture, it gets shot down in the standard library and elsewhere in the ecosystem.

But yeah, it’s hard to see how this would happen because there is nothing technical preventing the same kinds of abuses that are rampant in C++, it’s just the invisible but extremely force of culture.

Re: Julia Computing raises $24M Series A

#236

Post by amkkma »

Royi wrote: post #233
amkkma wrote: post #101

Earlier quoted context omitted.

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

Do you have updated comparison with some data of performance and memory vs. PyTorch / TF?

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

Re: Julia Computing raises $24M Series A

#237

Post by enriquto »

StefanKarpinski wrote: post #235
jpeloquin wrote: post #196

Earlier quoted context omitted.

> 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). Thanks for writing this. I think it is an important concept for getting started with Julia. When I tried Julia, I was initially confused and concerned…

This is an important point: abstractions like generic functions are only as good as how much people respect them, and enforcement of that is largely cultural. You can add technological levels of enforcement, but those are limited at best because people are brilliantly devious and can find ways to break any technological enforcement if they set their minds to it; the key to preventing that is convincing them to set th…

> We would never dream of using bitshift operators to do I/O

Or the sum operator for string concatenation, which is the epitome of non-commutative operation.

I like your point of view, but still I'm skeptical of function and especially operator overloading. Shouldn't these semantic constraints that you mention be enforced by the language? For example, the language does not let you overload + for a non-commutative operation, and so on.

Re: Julia Computing raises $24M Series A

#238

Post by dmytro__p »

enriquto wrote: post #237
StefanKarpinski wrote: post #235

Earlier quoted context omitted.

This is an important point: abstractions like generic functions are only as good as how much people respect them, and enforcement of that is largely cultural. You can add technological levels of enforcement, but those are limited at best because people are brilliantly devious and can find ways to break any technological enforcement if they set their minds to it; the key to preventing that is convincing them to set th…

> We would never dream of using bitshift operators to do I/O Or the sum operator for string concatenation, which is the epitome of non-commutative operation. I like your point of view, but still I'm skeptical of function and especially operator overloading. Shouldn't these semantic constraints that you mention be enforced by the language? For example, the language does not let you overload + for a non-commutative ope…

I was curious what Julia decided to use for string concatenation (+ method would be the least surprising option for me since it's common for the most of source code in use, even while the string concatenation is non commutative).

I was surprised to find Julia uses the multiplication method for string concatenation. For me it feels as wrong as using bitshift operators for I/O but maybe I'm missing something.

Re: Julia Computing raises $24M Series A

#239

Post by enriquto »

dmytro__p wrote: post #238
enriquto wrote: post #237

Earlier quoted context omitted.

> We would never dream of using bitshift operators to do I/O Or the sum operator for string concatenation, which is the epitome of non-commutative operation. I like your point of view, but still I'm skeptical of function and especially operator overloading. Shouldn't these semantic constraints that you mention be enforced by the language? For example, the language does not let you overload + for a non-commutative ope…

I was curious what Julia decided to use for string concatenation (+ method would be the least surprising option for me since it's common for the most of source code in use, even while the string concatenation is non commutative). I was surprised to find Julia uses the multiplication method for string concatenation. For me it feels as wrong as using bitshift operators for I/O but maybe I'm missing something.

+ is terribly wrong for string concatenation and people who used it first were illiterate freaks. If I had to chose among my many reasons to avoid python this by far is the strongest one. I'm forced to use formatting operators and string interpolation just to avoid the stupid +

Multiplication for concatenation makes perfect sense: it is commutative, associative, and consistent with mathematical notation. A space would be even better. And the empty string would be great, but maybe difficult to implement if you want to allow multiple-letter variable names, as julia seems to do.

Re: Julia Computing raises $24M Series A

#240

Post by dmytro__p »

enriquto wrote: post #239
dmytro__p wrote: post #238

Earlier quoted context omitted.

I was curious what Julia decided to use for string concatenation (+ method would be the least surprising option for me since it's common for the most of source code in use, even while the string concatenation is non commutative). I was surprised to find Julia uses the multiplication method for string concatenation. For me it feels as wrong as using bitshift operators for I/O but maybe I'm missing something.

+ is terribly wrong for string concatenation and people who used it first were illiterate freaks. If I had to chose among my many reasons to avoid python this by far is the strongest one. I'm forced to use formatting operators and string interpolation just to avoid the stupid + Multiplication for concatenation makes perfect sense: it is commutative, associative, and consistent with mathematical notation. A space woul…

Interesting, is multiplication method used for arrays concatenation as well?

Even if using multiplication to join strings may be consistent with some properties of mathematical notation, it's less consistent with the usual meaning of the words (I checked the cosine similarity using GloVe 6B words embeddings, the similarity between "add" and "join" is 0.4 while between "multiply" and "join" is only 0.03), so it's probably the balance between being the general purpose and math oriented language.

Post reply on HN