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

PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

dev-discuss.pytorch.org

Post reply on HN
Print view View original

231–240 of 291 posts

Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

#231

Post by streamofdigits »

It feels a risky proposition at this juncture to go short python. The arguments against/for have been rehashed a million times, the redeeming features of julia have been articulated very cogently...

What has not been accounted for is that the huge community / network effect of the python ecosystem is very far from exhausting itself. If anything, it is just starting as the exponential growth has mostly been the last few years (tautology, he he)

A major investment to eliminate python technical debt would make more sense if things were stagnant and the re-engineering would open up entirely new domains.

Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

#232

Post by tfehring »

cookieater wrote: post #203

I've used Julia for quite a few years now. It's biggest flaws in my opinion are basically cultural and not technological. It's been adopted mostly by serious domain experts rather then typical software engineers and more 'normal' people. I don't know say junior or senior scientists. This has lead to amazing results but also has it's own detriments. Some portions of the ecosystem are rock solid, especially the parts w…

This is a great comment, I've had exactly the same experience. For a simple, concrete example of the fragmentation issue, the canonical JSON parser seems to be JSON3.jl, but there's also JSON.jl, which is slower and has other subtly different behavior. Neither mentions the other in its documentation, neither is deprecated, but if you search for "json julia" only JSON.jl comes up on the first page of results, but if you ask a question about JSON.jl in Discourse or Slack they'll probably tell you to use JSON3.jl instead.

(To be fair, Postgres has an extremely similar issue with JSON data types and it's doing fine.)

The state of tabular data formats is similar but instead of 2 libraries there are 20, and some of them are effectively deprecated, but they're not marked as deprecated so the only way to find out that you shouldn't be using them is, again, to ask a question about them in Discourse or Slack. You can check the commit history, but sometimes they'll have had minor commits recently, plus (to Julia's immense credit) there are some libraries that are actively maintained and work fine but haven't had any commits for 3 years because they don't need them. I assume this will get worse before gets better as the community tries to decide between wrapping Polars and sticking to DataFrames.jl, hopefully without chopping the baby in half.

I feel like the "not invented here" mindset contributes a lot to that fragmentation. It's easy to write your own methods for types from other Julia libraries because of multiple dispatch, which seems to have resulted in a community expectation that if you want some functionality that a core package doesn't have, you should implement it yourself and release your own package if you want to. So we have packages like DataFramesMeta.jl and SplitApplyCombine.jl, not to mention at least 3 different, independent packages that try (unsuccessfully IMO) to make piping data frames through functions as ergonomic as it is in R's dplyr.

Despite all of this, I still like the language a lot and enjoy using it, and I'm bullish on its future. Maybe the biggest takeaway is how impactful Guido was in steering Python away from many of these issues. (The people at the helm of Julia development are probably every bit as capable, but by design they're far less, um, dictatorial.)

Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

#233

Post by cookieater »

amelius wrote: post #78
edgyquant wrote: post #44

Earlier quoted context omitted.

I like what Julia is doing but I just dislike the syntax. It seems to resemble ruby, whose syntax I also think is ugly, which to me resembles a modern form of basic.

I know what you mean. I especially dislike the use of an "end" keyword everywhere without a corresponding "begin" keyword.

Does it really matter though? I mean, whether it's a closing bracket or a whitespace demarcated control flow - does it really effect anything you do in the language? Julia solves a lot of problems, like real problems - quibbling over begin/end vs {/} or white space seems kinda silly.

Meanwhile I have actually seen real world lost productivity due to white space in python. Curly brackets not so much. Never seen lost productivity over begin/end but I'm sure it's happened. It seems silly to me either way - it doesn't really effect anything.

Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

#234

Post by cookieater »

ChrisRackauckas wrote: post #227
nothrowaways wrote: post #202

Why not go? Go beats Julia in parts where python is not good at. Is it because fb vs Google?

>Go beats Julia in parts where python is not good at. I have not seen good results from differential equation solvers in Go.

I don't think you ever will unless Go >2.0 is a completely different language.

Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

#235

Post by Vetch »

StefanKarpinski wrote: post #215
adgjlsfhk1 wrote: post #149

Earlier quoted context omitted.

the fact that they couldn't make primitive vs object invisible is just incredibly dumb though. it's one of the many ways c# is purely superior.

C# is certainly more flexible in this regard but I wouldn’t say they made the distinction between primitive and object invisible, they just allowed user-defined “primitives” in the sense that users can define C-style structs that have value semantics. The type system is still bifurcated between value types and reference types. That’s ugly but livable in a static language where you can just disallow mixing the two kin…

> C++ templates and just allow whatever by textual substitution

The Julia approach is indeed elegant. An in-between position taken by F# is statistically resolved type parameters, where type safety is maintained and semantics largely preserved by constraints on members. It's a pain to write but trivial to consume though errors can be obstruse. More type level flexibility on the CLR (which seems to be planned) will further improve things when it comes to generic programming.

Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

#236

Post by bjourne »

elcritch wrote: post #174
bjourne wrote: post #173

Earlier quoted context omitted.

But is it real kernel threading or the same kind of cooperative threading that Python also supports?

It's real kernel threads. Julia also supports cluster computing too.

According to this discussion thread, Julia requires the number of kernel threads to be specified at startup: https://discourse.julialang.org/t/does-multithreading-requir... This seem to be more like pyprocessing and much more limited than the pthreads interface.

Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

#237

Post by cookieater »

tfehring wrote: post #232
cookieater wrote: post #203

I've used Julia for quite a few years now. It's biggest flaws in my opinion are basically cultural and not technological. It's been adopted mostly by serious domain experts rather then typical software engineers and more 'normal' people. I don't know say junior or senior scientists. This has lead to amazing results but also has it's own detriments. Some portions of the ecosystem are rock solid, especially the parts w…

This is a great comment, I've had exactly the same experience. For a simple, concrete example of the fragmentation issue, the canonical JSON parser seems to be JSON3.jl, but there's also JSON.jl, which is slower and has other subtly different behavior. Neither mentions the other in its documentation, neither is deprecated, but if you search for "json julia" only JSON.jl comes up on the first page of results, but if y…

Kindred spirits it seems. Yea I think there is a serious future for Julia. It's my R&D and prototype workhorse by preference :).

Again, completely agree with the sometimes confusing state of the ecosystem. Sometimes I wish a bit of democracy existed, but people are people. I proposed some solutions to that problem a while ago but that's a story for another year.

Academia does create a very different kind of reward system that is often counter to community progress. IE: get there first, publish, obfuscate to thwart competition, abandon for new funding. Tends to reward people the highest for not giving credit, or sharing progress.

Meanwhile, people relying on alternatives to julia are more like: load in trusty xyz, use it in trusty way, I'll upgrade when it makes sense, and check the docs not the code when I am unsure of something.

Not to say industry is much better(I keep saying `academia`), but industry projects do tend to appreciate/honor free labor a little more kindly. That or they close the OSS gate and you get what you get.

Novelty is a driving force, but too much entropy and not playing well with each other can destroy a meaningful future quickly. It'll work itself out, one way or another but only because the technology is good :D.

Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

#238

Post by fault1 »

tfehring wrote: post #222
chaxor wrote: post #158

Earlier quoted context omitted.

The way I see Julia now is how I saw python ~12 years ago

I agree, but it's probably closer to 20 years IMO, which makes sense given that Python has been around for 21 years longer. By 2009 Python was already in widespread use at Google/YouTube and (I think) Mozilla, plus startups like Reddit and Dropbox. Hell, Steve Huffman wrote "Lots of people have written web applications in Python, and there's plenty of code from which to learn" as one justification for Reddit's Python…

I agree, personally I think it's a problem with Julia's initial "product" placement, which was probably a overfocus on the "technical computing" aspect.

Personally, the first version of python I used was 1.5.2 (in 1999). I learned it initially instead of the current 'scripting language' hegemon, which was perl. Since CGI was in extensive use at that time, this was the start of the python web backend ecosystem.

In the late 2000s, I was able to sneak in Python rewrites of MATLAB or Fortran code written by scientists, even in situations where Python was not officially sanctioned for that type of work (I was mainly a C++ developer, but would also write python bindings). I feel like it really was the strength of python's strength as a universal ducktape that caused the ecosystem growth of both the scientific _and_ web stacks.

Nowadays, I've really come to appreciate Julia from a novelty standpoint, and I'm intrigued at what it can do, especially in terms of probabilistic programming and other emerging fields, but in order to justify using Julia in more general 'professional programmer' settings, it needs to focus on what's made modern Python so successful. Otherwise, I could see it's fate as "merely" replacing a more niche language like MATLAB (which Python has /already/ managed to do for the most part).

Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

#239

Post by fault1 »

anothernewdude wrote: post #185
pilooch wrote: post #182

Loving pytorch but the reasoning remains strange to my ears: Python at all cost, not Julia, because of the ecosystem, well OK. But all bullet points are about things that are easily done right now with libtorch (pytorch underlying C++ core code), and the hassle is... Python. Well rational conclusion would be, just do everything in C++, and bind to Python. Make C++ first citizen here, since in all cases it'll be neede…

If Julia had wanted to be taken seriously then it shouldn't have dropped the ball at the very first hurdle by having 1-based array indexing.

Julia (and Fortran) have a concept called offset arrays where you can basically start on any sort of index: https://github.com/JuliaArrays/OffsetArrays.jl

IMHO, one of the biggest advantages of Julia _is_ arrays.

Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

#240

Post by jonniedie »

ChrisRackauckas wrote: post #200
goerz wrote: post #194

Earlier quoted context omitted.

Right. Zero based indexing makes zero sense, unless you explain the underlying technical reason, that it’s an offset relative to a memory pointer (spend a week teaching pointers first!). It makes sense in certain context (and in languages like C that have a low-level mental model). For scientific computing at a higher level of abstraction where the mental model of a multidimensional array is a tensor, and not a memor…

> Zero based indexing makes zero sense The sensibility of the index choice is equal to the starting value of the index.

StarWars indexing makes 4 sense.
Post reply on HN