Hacker News Reader

Comment by semiinfinitely | Hacker News Reader

PyTorch is the javascript of ML. sadly "worse is better" software has better survival characteristics even when there is consensus that technology X is theoretically better

View on HN

I don't think the comparison is fair. Imo PyTorch has the cleanest abstractions, which is the reason it is so popular. People can do quick prototyping without having to spend too much time figuring out the engineering details that make their hardware run it.

How is Jax theoretically better than PyTorch? The author is ignorant of torch.compile and biased as other commenters have pointed out.

Curious to know how the OP is biased when they have no conflict of interest, and they explicitly mention the `torch.compile` stack like... a few dozen times in the blog?

Nothing is even theoretically better than Javascript for its intended use cases, web frontends and backends. Mainly because it went all-in on event loop parallelism early-on, which isn't just for usability but also performance. And didn't go all-in on OOP unlike Java, and has easy imports/packages unlike Python. It has some quirks like the "0 trinity," but that doesn't really matter. No matter how good you are with something else, it still takes more dev time ($$$) than JS.

Now it's been forever since I used PyTorch or TF, but I only remember TF 1.x being more like "why TF isn't this working." At some point I didn't blame myself, I blamed the tooling, which TF2 later admitted. It seemed like no matter how skilled I got with TF1, it'd always take much longer than developing with PyTorch, so I switched early.

You don't think its possible to (even theoretically) improve on javascript for its intended use case? What a terrific lack of imagination.

Typescript and Elm would like a word

No, I said there's nothing that exists right now that's theoretically better. Typescript isn't. It'd be great if TS's type inference were smart enough that it basically takes no additional dev input vs JS, but until then, it's expensive to use. It's also bolted on awkwardly, but that's changing soon. Could also imagine JS getting some nice Py features like list comp.

Also, generally when people complain that JS won the web, it's not because they prefer TS, it's cause they wanted to use something else and can't.

Never used Elm, but... no variables, kinda like Erlang, which I've used. That has its appeal, but you're not going to find a consensus that this is better for web.

I see this a lot, and I want to find the right words for it: I don't want the types automatically determined for what I write, because I write mistakes.

I want to write the type, and for that to reveal the mistake.

If you explicitly mark types at lower levels, or just use typed libs, it's not very easy to pass the wrong type somewhere and have it still accidentally work. The most automatic type inference I can think of today is in Rust, which is all about safety, or maybe C++ templates count too.

I actually write a fair bit of Rust, and there I'll still explicitly add types. Not always (in particular where I have an IDE that'll show me the inferred type & it's trivial), but in particular if any more complicated inference is happening I'll constrain it.

TS has type inference on function return types while Rust forces you to type the whole function signature (for a good reason, TS's return type inference is a footgun).

Other than that, I haven't noticed their inference capabilities being any different.

So I don't get your point.

Can you give a single example where Rust has more automatic type inference compared with TS? (honest question, maybe I'm missing something)

> No, I said there's nothing that exists right now that's theoretically better.

That might be what you meant, but its not what you said. Thanks for clarifying.

Reply on news.ycombinator.com