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

Candle: Torch Replacement in Rust

github.com

Post reply on HN
Print view View original

81–90 of 192 posts

Re: Candle: Torch Replacement in Rust

#81

Post by liuliu »

GaggiX wrote: post #75
liuliu wrote: post #63

Earlier quoted context omitted.

After a few years, I am coming to an opposite opinion on this. Yeah, shape checking is nice and all and you should be able to run them before-hand (might be a linter pass). But inside type-system while most people have LSP running in the background and bark at you on any type mismatch? It is not going to be a pleasant development experience.

I cannot really see how it can be a worse experience than waiting for the model to run, fix the error found, wait a second time, fix another error; when you can just check instantly if the model architecture is sound.

Because that's not my workflow looks like?

* Fire up Jupyter notebook, create some PyTorch nn.Module, validate the output is expected.

* Built out the model, validate the output is expected.

* Check the data shape, do a eval() run with the data.

* Move out of Jupyter notebook (or not), to actually run the trainer.

Each of the "build out model" phase, shape inference at compile time would be kind of annoying especially if you have a LSP constantly running compilation.

Re: Candle: Torch Replacement in Rust

#82

Post by Qworg »

tikhonj wrote: post #64
dkarl wrote: post #56

Earlier quoted context omitted.

Rust needs a prototyping/scripting/application language on top of it, with 80% of the speed and 99% of the safety, with automatic memory management (reference counting or GC) and at least one idiomatic way of doing concurrency that disallows sharing mutable state. A language that is tailor-made for building applications quickly on top of the Rust ecosystem, with a build tool that gracefully handles mixed projects if…

I've worked on a Haskell + Rust project that followed roughly the dynamic you're describing and was pretty happy with it. I wrote some simple tooling that let us share algebraic types between the two to manage our interfaces and it worked pretty well. In our case we needed to serialize/deserialize data between our components so the interfaces were at a bit of a distance, but, in principle, it would have been totally…

I made the call between Haskell and Rust for my fintech startup. I chose Rust when I realized how few Haskell programmers there were available to hire - at 20 engineers, we'd be one of the largest shops on the West Coast of the US AFAIK.

That said, we were one of the largest Rust shops outside of the FAANGs, but Rust was straightforward to teach to C/C++ folks.

Re: Candle: Torch Replacement in Rust

#83

Post by tracker1 »

synergy20 wrote: post #46
jstx1 wrote: post #29

It's cool that this is coming from huggingface and it isn't just someone's hobby project. Rust is in a weird place where people are trying to push it in a bunch of places where it doesn't belong naturally (web dev, data science) but then when you complain that it's difficult to use you get told that you're using the wrong language for your use case... I really want to like Rust - I've read the Rust book, done the Rus…

A similar situation here for me. Rust might be a modern Ada for a particular use case(system programming), I was puzzled why stackoverflow ranked it as 'the most loved' language for years. For each language related post at HN, you will always see rust lover's posts there saying "I wish it's in rust", or "there is a rust version", or "rust is even better". The reality does not match up with the enthusiasm for me thoug…

Those who are enthusiastic are very much so. I would say it's less contentious compared to when Node.js started to become popular. It's still one of my favorite tools/languages, though I'd prefer to use Deno more these days.

As to falling back to any given language, that's not uncommon. Learning a new language is difficult, especially if the paradigms don't align well to what we already know, or have experience in. This may come down to experience, or it may come down to how you now think through problems. That said, I don't think that C++ is inherently more productive than Rust, I think saying your experience makes you more productive in C++ is a far more likely truth.

Re: Candle: Torch Replacement in Rust

#84

Post by switchbak »

jstx1 wrote: post #29

It's cool that this is coming from huggingface and it isn't just someone's hobby project. Rust is in a weird place where people are trying to push it in a bunch of places where it doesn't belong naturally (web dev, data science) but then when you complain that it's difficult to use you get told that you're using the wrong language for your use case... I really want to like Rust - I've read the Rust book, done the Rus…

I'm wondering as Mojo matures if it'll naturally take over these roles. That's what it's core mission is, and it's being developed by the very best in the biz.

I like Rust, but Mojo seems like it ought to be a much easier sell for projects that are very invested on the Python side.

Re: Candle: Torch Replacement in Rust

#85

Post by boredumb »

jahewson wrote: post #66
unshavedyak wrote: post #42

Earlier quoted context omitted.

It may just be for different people, not sure. I'm a Rust fanatic, i use it for everything, including web dev. We even have a shop full of similar Rust folks. Personally it's my most productive language, and this is after years in Python, NodeJS, and ~5 years Go. Which isn't to attempt to invalidate your experience. But i do think: > writing Rust is a slog where you have to jump through hoops and spend a lot more tim…

Rust for web dev instead of Go? I want to believe. What’s the killer app?

I use Tide with great success

Re: Candle: Torch Replacement in Rust

#86

Post by iknowstuff »

dkarl wrote: post #56
jstx1 wrote: post #29

It's cool that this is coming from huggingface and it isn't just someone's hobby project. Rust is in a weird place where people are trying to push it in a bunch of places where it doesn't belong naturally (web dev, data science) but then when you complain that it's difficult to use you get told that you're using the wrong language for your use case... I really want to like Rust - I've read the Rust book, done the Rus…

Rust needs a prototyping/scripting/application language on top of it, with 80% of the speed and 99% of the safety, with automatic memory management (reference counting or GC) and at least one idiomatic way of doing concurrency that disallows sharing mutable state. A language that is tailor-made for building applications quickly on top of the Rust ecosystem, with a build tool that gracefully handles mixed projects if…

I think you’re describing Swift

Re: Candle: Torch Replacement in Rust

#87

Post by alphanullmeric »

jstx1 wrote: post #29

It's cool that this is coming from huggingface and it isn't just someone's hobby project. Rust is in a weird place where people are trying to push it in a bunch of places where it doesn't belong naturally (web dev, data science) but then when you complain that it's difficult to use you get told that you're using the wrong language for your use case... I really want to like Rust - I've read the Rust book, done the Rus…

here comes the slew of rust people claiming you’re using it wrong and that anything another language does easier or more concisely is an antipattern

Re: Candle: Torch Replacement in Rust

#88

Post by alex_lav »

wokwokwok wrote: post #41
jstx1 wrote: post #29

It's cool that this is coming from huggingface and it isn't just someone's hobby project. Rust is in a weird place where people are trying to push it in a bunch of places where it doesn't belong naturally (web dev, data science) but then when you complain that it's difficult to use you get told that you're using the wrong language for your use case... I really want to like Rust - I've read the Rust book, done the Rus…

Yeah, but the goal of this isn’t “use this instead of Python to hack up a model” …it’s: > And simply removing Python from production workloads. Python can really add overhead in more complex workflows and the GIL is a notorious source of headaches. You know, those hugging face guys kindaaaaa do know what they’re talking about. Like, really. Python is a pain in the ass in production environments.

This comment seems abnormally toxic for what's being discussed.

> Yeah, but the goal of this isn’t “use this instead of Python to hack up a model”

This was never said.

> You know, those hugging face guys kindaaaaa do know what they’re talking about.

This was never challenged.

> Python is a pain in the ass in production environments.

This is "I don't like python", but phrased adversarially.

Language flamewars suck. Some people don't like certain languages in certain contexts. I see Rust's syntax (having written a small to medium amount of Rust) and feel pretty confident I wouldn't task my data science team with writing or maintaining Rust codebases. We can squabble over "But eventually you'll get it", but ultimately that's more of a priorities comment than a language feature.

Post reply on HN