9 ms·

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 bunc

• lionkor 3y ago
  This has been my experience, too. Somewhere in Rust, there is a beautiful, functional(ish), pragmatic and simple language, hiding in between all the crappy things. So it's just like C++ ;) except it has pattern matching and const by default.
  • taminka 3y ago
    what being a kitchen sink language does to a mf
• wokwokwok 3y ago
  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.
  • ravenstine 3y ago
    > You know, those hugging face guys kindaaaaa do know what they’re talking about. > Like, really. Trust me, bro?
  • fooblaster 3y ago
    Pytorch has multiple production paths for deployment models without the python interpreter already, like torchscript and libtorch, or more annoying paths like onnx export and onnx runtime. So there is no need to have rust to solve this problem.
    • malcolmgreaves 3y ago
      Those are great technologies for making the model inference independent of Python. However, there's always a good deal of pre and post processing, or other business logic, that needs to go around model inference. This sort of thing needs to be done in a general programming language. It's in these situations where Python is often used (because the supporting model code is often written by the same person, and that code is probably going to be Python because your model training and eval code is most likely going to be Python too). This is where having a non-Python PL, such as Rust, can make a huge difference for both ease of production deployment/maintenance as well as having truely efficient production inference.
      • fooblaster 3y ago
        I've found that there is usually very little code to be shared within training and inference when most of the pre and post processing is pulled into the model itself with custom operations. Relatively few people are aware that you can write training code in C++ today with torch to share a common language with inference and training, but very few take advantage of this in practice.
  • devjab 3y ago
    > Python is a pain in the ass in production environments. I really dislike blanket statements like that one. Because any programming language can be a pain in production environments. One of the disadvantages of Python is also one of it's advantages. Because it's much easier to end up with a terrible production environment when you use "chaos" languages like Python or JavaScript, the tooling to avoid the pain points is so mature. With those in place Python becomes great in production. Yes it'll require your organization to take some serious CI culture decisions and also enforce them. The thing is, however, while you can get a long way without doing that with some programming languages, you're frankly always going to want them by the time you reach enterprise size. So it's just so much easier if you get it done right away, and you will, if you're serious about using Python. I'd argue that if it's a pain to work in your production environments then the issue is not the technology but the process.
    • coldtea 3y ago
      >Because any programming language can be a pain in production environments. Except one with memory safety and static builds. Like Rust can offer.
      • oivey 3y ago
        I wish my bugs were mostly preventable via static typing and memory safety checks. For most ML and data work algorithm design and logic errors are the primary source of bugs. Type errors are usually the trivial things you fix in minutes.
        • coldtea 3y ago
          The topic wasn't bugs though - and nobody mentioned static typing. The grandparent said "Python is a pain in the ass in production environments". And the parent said: "any programming language can be a pain in production environments". My point was how Rust is better for backend services for fewer problems in production, as it wont have memory bugs (which have long plagued backend services and have resulted in many exploits), and it also offers static builds (so deployment can be dead easy, and wont be having the kind of environment issues some languages have). I understood the grandparent to mean something about how Python has issues with dependencies, and isolation, and paths, and updates, and so on. And the parent to mean that you can have deployment issues with any language. And to obviously neither to refer to design and logic errors, since the former wouldn't be singling out Python, and the latter would be saying a tautology. And neither would make sense to talk about those being an issue in production specifically.
  • alex_lav 3y ago
    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.
    • nmstoker 3y ago
      I'm not getting a sense of toxicity from this discussion. Sure, people are disagreeing and have distinct positions but the manner of discussion seems constructive. >> This was never said. Quotes don't have to used solely to indicate somebody explicitly said something.
    • maximilianburke 3y ago
      > This is "I don't like python", but phrased adversarially. But it is an incredible pain in the ass in production environments. Environment drift is something that _always_ seems to happen, no matter how diligent people are about using venvs or dependency managers or w/e. One of favorites was when we did a dependency upgrade (something that required a change to Click) we had an upgrade of Black forced on us in order to satisfy Poetry which then reformatted all of our Python code. Recently we had mypy stop checking one of our internal packages because of a Dockerfile refactoring. The package could still be found at runtime but the type information just wasn't found by mypy. We didn't notice it until we started getting errors at runtime, which made the fix a lot more difficult to diagnose. There's always someone saying "you're using it wrong" or "you're doing something worng", even if you follow the guides and howtos to get started. For a language which states "There should be one -- and preferably only one -- obvious way to do it" as part of its guiding principles, that there is no single one way to use it right in production -- let alone an obvious one -- that makes it, simply, a "pain in the ass".
• unshavedyak 3y ago
  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 time thinking about programming language abstractions than thinking about the problem you're solving. Is quite a leap. A language you describe not speaking natively is, unsurprisingly, difficult for you. Which is a far cry to say it's always that way. You of course shouldn't be in a rush to rewrite anything unless you see the value in it. I make no claims of that value, either. Rewrite It In Rust (RIIR) is a meme, imo a destructive meme. But i do take issue with labeling any language broadly. Most languages are pretty good when you're very fluent in them, and while they do have tradeoffs, i don't think Rust's tradeoffs are as you put them.
  • jahewson 3y ago
    Rust for web dev instead of Go? I want to believe. What’s the killer app?
    • unshavedyak 3y ago
      > Rust for web dev instead of Go? I want to believe. What’s the killer app? No killer app here. We just prefer Rust itself. Go is very capable and a great choice. For me personally i found Go to spread logic out far too much. Some features of Rust, Iterators for example, massively simplified how i think about data flow. That was my #1 issue with Go. This has side root-causes in Go of course, like no generics to allow for Iterators, etc - but these days Go has generics so it's likely improving. Features around Enums are also huge for me. I left Go ages ago and it's improved a lot sense then. I still prefer Rust, though. As i said no judgement on any lang, including Go. This is merely my experience and preferences.
    • tracker1 3y ago
      I would say for me, the killer app would be just about anything you might reach for Electron with, but want a much smaller install footprint. Tauri in and of itself is pretty cool, kind of a lighter alternative to electron using native platform browser engine. In general, I would probably reach for Rust if I needed to do anything wither Web-Assembly (wasm) as the path to working is much nicer than other languages imo. Along those lines, Yew is pretty nice as a rust-like framework. I've also played with Rocket, and found it very nice and effective for api driven web-apps. Haven't done any templating engines in/with Rocket, however.
• synergy20 3y ago
  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 though, what am I missing? After each try with Rust, I ended up going back to c++ myself, it's just more productive in practice.
  • synergy20 3y ago
    Talking about my personal experience, getting downvoted heavily which was expected and not a surprise, in fact the insanity is another big reason I will not use rust, no other language has such patterns as far as I can tell.
  • tracker1 3y ago
    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.
  • mkehrt 3y ago
    I write rust professionally and I really, really enjoy it. It’s lots of fun, and has found a good (and novel!) point in the space of safety vs. speed. That said, I think in the 80-90% case, a language with a garbage collector is probably more appropriate for the task at hand.
  • geertj 3y ago
    > After each try with Rust, I ended up going back to c++ myself, it's just more productive in practice. That has been my experience as well. Rust and the borrow checker get too much in my way. If I want a high level language I will use Python but if I want control all the way down to the hardware C++ is where I go. Plus, it /feels/ that ISO C++ has significantly picked up on momentum and is seeing more investments than Rust.
• say_it_as_it_is 3y ago
  Python stands on the shoulders of giants writing C libraries. Those people think a lot of about problems you haven't had to deal with.
• spoiler 3y ago
  > writing Rust is a slog where you have to jump through hoops and spend a lot more time thinking about programming language abstractions than thinking about the problem you're solving. Have you tried "sticking" with it for a while? Try forcing yoursel to use it[1]. I find that's the best way to learn it (and try reading more code from open source project in Rust you like). I have an opposite experience writing Rust: it allows me to focus on the problem more easily, especially when the problem domain is complex and the codebase grows. [1] a trick often used while learning human languages
  • devjab 3y ago
    Have you written a lot of things in Python? I remember coming "back" to Typescript and C# from Python and how much of a slog it felt. Last year I did quite a lot of work in Rust and I personally found it to be one of the worst languages I've ever worked with in terms of actually writing it. I even like Rust, a lot. I really love things like how you actively need to make things mutable. I wish that was a standard feature in any language I work with. But it's just so verbose.
    • brigadier132 3y ago
      > Have you written a lot of things in Python? Not the person you responded to but yes. I have written a lot of production software in Python. I remember developing APIs with Python and the day we switched to using Typescript all these bugs we used to have just disappeared. Going from Typescript to Rust was not as big a change but well designed statically typed languages are a productivity booster not killer. We can agree to disagree but I've personally experienced a large Python codebase at a Unicorn tech startup and I'd like to never experience it again.
      • devjab 3y ago
        I don't think we necessarily disagree. I really enjoy using Typescript these days, but I do remember getting into it and being annoyed I had to write {}'s again. These days I'm annoyed when I can't export functions without putting them into a class though, so maybe people shouldn't listen too much to me.
• dkarl 3y ago
  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 you need to build part of your application in Rust, and support for writing small shebang scripts. Also, I'd like a pony, a jetpack, and VIP passes to the premiere of Dune: Part 2.
  • tikhonj 3y ago
    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 doable to extend the same kind of tooling to provide a legitimately easy-to-use FFI layer between the two languages. Haskell is a bit of a tricky language organizationally for mostly social/political reasons, but if I end up starting my own company in the future, Haskell + Rust is definitely the tech stack I'd lean towards.
    • Qworg 3y ago
      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.
      • tikhonj 3y ago
        We actually had the opposite experience in hiring for our Haskell team: it was substantially easier to find legitimately strong engineers for Haskell than for other teams using Python and Scala. I figure it comes down to two things: 1. A lot more people want to do Haskell than there are Haskell jobs 2. Haskell is an easy way to signal (show not tell) that our team is willing to do things differently—especially important because our team was at Target, which did not have much of a reputation as a tech employer! We didn't try hiring Rust programmers because the existing Haskell folks were more than happy to pick it up. So making hiring easier is one of the reasons I'd want to use Haskell, counterintuitively!
• Fiahil 3y ago
  Prototype in Python, but scale in Rust. I do a lot of AI Engineering in Python, but production Data Engineering, and Feature Engineering workloads are done in parallel with Rust. Simple and Fast. You can even make custom-made python modules with a Rust core when Numpy matrices are not enough to crack your graph-traversing problem efficiently ! (Thanks PyO3 and Maturin)
  • echelon 3y ago
    > Prototype in Python, but scale in Rust. Not even. Some people start building big systems with Java or Go. It's entirely appropriate to start in Rust too once you're more proficient in it.
    • Fiahil 3y ago
      a bit difficult and controversial in Data Science, but okay. I’ve taught data scientists to use docker, I might be able to teach some Rust ! For anything that is not related to DS/ML/Opt, yes, start with Rust. I had tremendous success with distributed Rust microservices using ZeroMQ for backbone communication.
  • brigadier132 3y ago
    Since you mentioned Python / Rust interop I wouldn't be surprised to see this have a Python binding made for it and code will likely be easily translated over when it needs to be productionized.
    • jononor 3y ago
      I would be surprised if it does not happen. If it is not provided officially then very likey someone else will make it. Python is the lingua franca of the ML domain, after all.
• zackoverflow 3y ago
  I don't do anything related to data science, but I feel like doing it in Rust would be nice. You get operator overloading, so you can have ergonomic matrix operations that are typed also. Processing data on the CPU is fast, and crates like https://github.com/EmbarkStudios/rust-gpu https://github.com/EmbarkStudios/rust-gpu make it very ergonomic to leverage the GPU. I like this library for creating typed coordinate spaces for graphics programming (https://github.com/servo/euclid https://github.com/servo/euclid), I imagine something similar could be done to create refined types for matrices so you don't do matrix multiplication matrices of invalid sizes
• echelon 3y ago
  > writing Rust is a slog where you have to jump through hoops and spend a lot more time thinking about programming language abstractions than thinking about the problem you're solving. It's like this until it isn't. Eventually this falls completely away - I promise. It's a lot like being a 100% backend engineer trying to develop in React for the first time. You just have to get used to it. Rust is not difficult, it just takes some soaking in.
• switchbak 3y ago
  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.
• alphanullmeric 3y ago
  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
• yieldcrv 3y ago
  Best I can see is that it helps incremental time that adds up over time Like if your build server is backed up maybe the rust version of your language's compiler and interpreter will make your build server not be backed up because it does everything faster But for everyone else its not that useful to be using the rust version of everything Its just another one of those things where you see lucrative job offers requiring rust, so you make up reasons to have impactful-ish experiences in rust
• brundolf 3y ago
  It'll never not have a trade-off! But there are some things that can make it easier in many cases: - Copy structs- ownership issues vanish when things can be bitwise-copied - .clone()- don't be afraid to clone outside of hot loops! If allocations are a problem, look at using Rc instead of Box where applicable - Pure functions/methods- you don't need mutable references if you aren't mutating things - Macros- reduce boilerplate - Purpose-built traits- you can hang methods off of different structs, including std or builtin structs, that can make certain flows really ergonomic In general: Rust asks you to care about all the little details at a language level, but it also empowers you in different ways to build high-level abstractions on top of those details so that you often don't have to care about them. I'm finding that I have the smoothest time with it when I use traits and macros to make my own little DSL for the problem I'm trying to solve, and then write my business logic in that. And then- many libraries offer you their own abstractions that give you the same sort of benefit. Concurrency normally involves a bunch of ownership and locking headaches, but something like rayon makes it breezy by giving you an abstraction that handles those details for you. Async web route handlers with shared state from scratch would normally be hard, but axum and Rocket give you abstractions that handle the gross stuff for you. One of my favorite crates I recently discovered is just called "memoize", and it just gives you a macro you can slap on any old function to memoize its results! (global mutable state!) https://crates.io/crates/memoize https://crates.io/crates/memoize. This would be a mess to implement yourself, but the abstraction makes it breezy And then personally: the main reason I'd use a Rust library like the OP over a Python library is the tooling/dependency management. Running a Rust project with dependencies Just Works and that's extremely valuable to me. But, it'll always be weighed against the costs of using a lower-level language.
  • bombela 3y ago
    And the implementation behind those abstractions tend to be of really good quality. Thanks to the borrow checker and the scrutiny around the unsafe keyword. In other words I am more willing to trust abstractions over tricky problems in Rust than I would in other languages. Just for a second, try to imagine a generic memoize in C++.
    • 3y ago
• brigadier132 3y ago
  There are two kinds of complexity. Upfront complexity and hidden complexity. Rust with the borrow checker significantly shrinks the space of possible programs that can be written to solve a problem. Some people think this is bad because they can't write software in a way they find natural, I like it because of the possible programs that rust makes impossible to write the vast majority are incorrect and have bugs. I also really like that when I use libraries, I know that all the library authors also subject to these same restrictions and I can trust their code much more than I could in other languages.
• deleted 3y ago
  [deleted]
• pjmlp 3y ago
  Yeah, Rust's sweat spot is systems programming and scenarios where no form of automatic memory management is tolerated, regardless of the reasons, for everything else there are enough AOT compiled languages with some form of automatic memory management, and features for low level coding if really needed.
• ramesh31 3y ago
  >So I'm not in a rush to rewrite anything written in Python just yet. I think it's becoming clear that Python is to ML what JS is to the Web. We got stuck with it through a series of historical coincidences, and no one is super happy about it. But it mostly does the job and has evolved to fit the bill. I'm not a huge fan but it's definitely here to stay. Hopefully Rust can take off but I don't see any other viable replacement.
• zengid 3y ago
  I can attest to this. I really think it depends on your background and what your project is. Rust has a lot of baggage from it's use in systems programming that many folks coming from C++ already know, and a lot of strange functional programming things that ML-family language folks already know, so there's just a lot of new things crammed together. Now add move-by-default semantics, and tight restrictions on pointers, and it can get really hard. They key is getting to the point where you just try to use value semantics as much as possible, and stop trying to write everything perfectly the first time (i.e. use lots of `.clone` and `.unwrap` so you can get your code written down to do the thing you're trying to do). I am hopeful that languages like Mojo and Val are going to find cleaner ways of doing what Rust does best, and that Rust can learn from them.
  • theLiminator 3y ago
    > I am hopeful that languages like Mojo and Val are going to find cleaner ways of doing what Rust does best, and that Rust can learn from them. I suspect they'll be great for a subset of the things that makes Rust great. There's probably a bunch of essential complexity that can't be hand waved around via a "smarter compiler" at least at this point in time (I'm not saying Rust is as simple as it could be, but I suspect there's no order of magnitude improvement while fulfilling the niche that it occupies).
• deleted 3y ago
  [deleted]
• balaji1 3y ago
  I can understand why Rust feels like jumping thru hoops. In a way, working with Rust feels like working with Ruby/RoR. Is there similarities? I understand Rust is just as powerful and way safer and faster than Ruby.
• progrus 3y ago
  I absolutely love the slog of writing Rust… but I would not inflict it on my coworkers for most business-type projects.
• John23832 3y ago
  I never understood why people say that rust isn’t appropriate for web dev. I think Axum is slick. Typically the people I hear saying that are super Spring indoctrinated.
  • riku_iki 3y ago
    to me, rust has extra complexity related to memory management and raw performance, which are irrelevant to typical web dev. I am not an expert in rust, but looking at it as potential choice for my next project.
• zer8k 3y ago
  I was with you until you mentioned Python. The use cases for the two languages are entirely orthogonal. Rust is a fantastic C++ replacement (nothing will replace C). My problem with Rust, now on month 3 of trying to love it, is exactly what you mentioned. It's a slog. Comparing it to other languages you have to know a lot more about systems. Initially, this isn't a problem, but as it turns out it becomes a problem with Rc/Arc/Box/etc. These are really just leaky abstractions in practice with strange behavior in many cases. Sure, you can write Rust without ever needing that. But if you ever need something more specialized than BTreeMap you're going to be chest deep in a kafkaesque nightmare of lifetimes, weird garbage collection, crazy types (Option<Box<Rc<Cell...) etc. It's at this point the helpful compiler becomes a mortal enemy. A sisyphean task made worse by the compiler suggesting the wrong things at the wrong time because you're so deep in lifetime/box/[A]Rc hell that not even God himself can save you. As long as you can mostly use the standard library and mostly avoid ever needing to do something where resources are shared Rust isn't that bad. Once you start sharing resources your life becomes extremely painful extremely fast. In some cases this is good, requiring you to think, but in many cases it's bad due to the leaky abstractions over memory when you need to do something more. In this case, despite it's major flaws, C++ wins in my opinion. I have a problem with the abstractions over pointers in Rust because they require me to STILL know how things underlying those abstractions works. Rust is going through its 15 minutes of fame. Much like Ruby, Elixir, etc you will have fans trying to shoehorn every possible case into it. It's a systems language. It is very good at what it is. It definitely does not belong in Data Science though it could be used to replace the underlying systems-level code found in Tensorflow/Torch/Pandas/etc a little safer. But at what cost? I'm being hard on Rust because I think in 5 years time it'll begin to replace C++ for most new systems level code. I hope they continue to revise the API.
• gtani 3y ago
  I'd invite you to keep up on improvements in tooling like analyzer and auto-fixing clippy warnings (tho understanding internals of linters, borrow and type checkers is a full time job and then some) https://www.infoworld.com/article/3267624/whats-new-in-the-rust-language.html https://www.infoworld.com/article/3267624/whats-new-in-the-r...