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 Rustling exercises, read Zero to Production in Rust and did the project there, and still it's not clicking - 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.
So I'm not in a rush to rewrite anything written in Python just yet.
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.
> 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.
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.
Tauri is indeed very cool, and also very small (the installation package is typically under 5MB). I used it to build a wrapper application for the ChatGPT official website, extending the site with many interesting features through script injection. However, the compatibility of the system webview across different platforms is a frustrating matter. https://github.com/lencx/ChatGPT
So if you take a Python program and you add the mental effort of having to deal with static types, lifetimes, the borrow checker and performance considerations, and this added mental effort actually allows you to write the program faster?
That is incredible. It's like being able to carve- and install a door from a slab of wood faster than installing a prefabricated door.
Ongoing maintenance and feature development on top of an existing code base is easily 10x the amount of time and effort of starting a new project greenfield. Even modest improvements in long-term readability and maintainability have disproportionately beneficial effects, even if the initial cost is somewhat high.
In my personal experience, once you're proficient in Rust, the initial cost is not somewhat high because those improvements in your ability to reason about your code base start snowballing quickly. And the long-term effects are enormous. I have literally picked up a project I hadn't worked on in years, made sweeping changes to the internals, and had every test pass in a pretty comprehensive suite the very first time it compiled.
This line of reasoning is utterly alien to me. If your types add mental overhead, you’re doing something wrong. You should be able to rely on the typechecker to check invariants for you, decreasing mental overhead. You have to think about types anyway, especially in an untyped language, where you can’t rely on the typechecker.
Having types lets you get better editor completion and such; I'd say Rust pushes you into bottom-up design, which I find significantly more productive than top-down too; doing bottom-up design is much trickier in a dynamic language, though, because changes to one of your "bottom layers" break upper layers in a way that the compiler/interpreter can't see
I code faster in types languages. I find typed code easier to read and understand. A lot of writing new code is just reading and understanding existing code.
So the claim doesn’t sound so crazy to me. For me at least, types remove mental overhead, they don’t add to it. I can’t count the times I’ve been reading through untyped (or inaccurately typed) python code and have had to jump a dozen levels deep just trying to figure out if a function can or cannot return null.
I'd like to make the jump to FT Rust myself, just don't have enough hands on... and as I get older, motivation to work on more stuff on the side, as well as time, becomes more limited.
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.
> 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.
My experience is that python is a mess in production. Even with a full CI, tests, mypy for static typing, pinned dependencies recursively, bazel with custom rules to build those dependencies (because many python dep have undeclared deps). And of course abysmal performances. And I wouldn't dare letting juniors touch python.
Rust is far from perfect. But in my opinion formed by experience, Rust is the best imperative language available right now.
Note that I have both written software in Python and built a whole devxp stack that includes Python. I wrote the first version of Docker in Python for what is worth, and at my last job; over many years; I built and maintained the polyglot dev experience for 150 devs.
> Rust is far from perfect. But in my opinion formed by experience, Rust is the best imperative language available right now.
But what about along with the ecosystem/libraries. Would you say in total Java might be better (assuming webdev)? Especially with the Loom project where you don't have to do "async" syntax.
I understand "ecosystem/libraries" as code available for free. That a quick search online would convince most of us that it is trustworthy enough. That we hope won't require us to ever have to read, modify, and re-design the code. And if we are lucky has a state of the art abstraction for the domain it solves. So that we can get going with our task at hand as quickly and efficiently as possible.
Under this light, Rust has now quite a large ecosystem of pretty good quality I would say.
I have only written small thread safe system level libraries in Java. But I sure noticed that javac did not have a borrow checker ;)
For webdev I had no problem with Rust async or not. But my definition of webdev is reduced to a web server that calls out to a database or another service.
Saying "any programming language can be a pain in production environments" is technically true but irrelevant and misleading.
It implies that all programming languages are equally painful in production, but that obviously isn't the case.
Python is definitely among the worst. Easily the worst among popular languages. It's closely followed by C++. Go and Rust are faaar nicer. Totally different league.
Django would frankly be an excellent choice for most web apps and if you're into microservice architecture then frameworks like pantherpy are almost as great as Java's Quarkus. That being said, we do try to limit our Python use to be exclusively for the BI/AI/ML part of our business and that's solely because that's the language those people work with in my area of the world.
This is mainly for pragmatic reasons. We use Typescript for most things because it's nice to have a language that's shared between the front and backend of things when you work in the small teams that are non-tech Enterprise. Then when we need efficiency we use C (and Rust more and more because it protects us from ourselves), when we do embedded it's C and when we need something like Odata or whatever .NET(y) it's C#.
I think Go is nice to write and terrible to work with. Not so much because of the language but because you're going to be writing basically all your libraries from scratch, or alternatively, putting massive maintenance efforts into the ones you consume. Which to be fair, isn't that different from using Typescript, but as long as the frontend of enterprise apps is as it is you're going to be working with Typescript whether you like it or not.
> 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.
Could you describe what you mean, as in what that tooling is? Having done some funky deployments in Python before, I've never been very impressed by the ecosystem and tooling.
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.
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.
You’re right, I misread static builds as typing. Python’s dependency management system sure does suck, although I think the problem could be solved without static builds. Overall they are a nice feature, though.
I think the memory management element is a little dubious, though. Torch’s memory management, for example, is fairly safe, and it internally has its own allocator. A Rust version (I think) that implemented the same would have to rely on unsafe blocks, and would likely have many of the same potential pitfalls as Torch. Time spent satisfying Rust’s borrow checker is likely lost productivity compared to just relying on Python’s reference counting and garbage collection. That productivity could be better spent on making the product better with new features and fixes of algorithmic mistakes.
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.
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.
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.
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.
> 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".
> But it is an incredible pain in the ass in production environments.
"I find it hard to maintain Python in production environments", but worded adversarially.
> 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.
This is literally just a misconfigured set of tools then.
> 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.
This is true of all languages and frameworks. There are people _in this comment section_ insisting those that have had negative Rust experiences must simply be doing it wrong. This is more a comment on our industry than any individual technology.
> For a language which states "There should be one -- and preferably only one -- obvious way to do it"
Yes, this has always been a bold faced lie from the Python community. Marketing speak is marketing speak.
> 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".
It's as much a pain in the ass as literally every piece of technology, as the above statement is true for every technology and framework that exists.
I acknowledge that you don't like it. That's great! But again, language flamewars suck, and suggesting that something is bad because you've individually had a bad experience is pretty silly. Lots of people successfully deploy and maintain python applications of various sizes without referring to the process as "a pain in the ass".
>we had an upgrade of Black forced on us in order to satisfy Poetry which then reformatted all of our Python code.
Unlikely. If you are using pre-commit to run black then the version being used lives outside your venv and hence not subject to dependencies you are using. Poetry should also be outside your venv.
It's not "unlikely"; it's something that happened.
And, again, if something that was configured wrong this goes back to how managing Python is a pain in the ass. I should be able to dedicate my brain power to the problems I need to solve, not what things need to be in my venv and what things need to be outside of it.
I agree that managing python development environments is a pain in the ass. I'm completely with you there.
But I'm curious what the nature of a black upgrade being forced on you. Like a manager or stakeholder had an edict stating everyone must upgrade to 23.x?
> There's always someone saying "you're using it wrong"
I feel like your reply is demonstrating this comment perfectly. You could be perfectly correct, but their point still stands that _they_ had a horrible experience that shouldn't have been so difficult. If there's a _right_ way to do things then it should be blindingly obvious and these kinds of experiences would dry up.
A person had a bad experience. There's a decent chance that bad experience is more that person's fault than it is any technology's. But also:
> If there's a _right_ way to do things then it should be blindingly obvious and these kinds of experiences would dry up.
This has never happened for any technology ever. People misconfigure things all the time. Even hardened technologies get used incorrectly very frequently. It's just the reality of our industry. Which is why I say, all of this is just a proxy for "I didn't like my experience with Python", which is fine! But also in no way condemning of the technology.
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.
> 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
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.
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.
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.
I've been exposed to Python through work, but I was never a fan. Backwhen I was faced with learning Ruby or Python, I picked Ruby; just felt more ergonomic. I even prefer more recent versions of TypeScript to Python too. I never really felt productive in Python, since the language is very finnicky (I would say more so than JS).
Rust might be verbose in parts of the language (but I don't find it as verbose as C or C++), but you get a lot of goodies the the price of a bit of verbosity. So, I don't mind it
> Rust might be verbose in parts of the language (but I don't find it as verbose as C or C++), but you get a lot of goodies the the price of a bit of verbosity. So, I don't mind it
I think it's worse than C. That being said, I'm probably also biased in a way where I'm more forgiving to C++ than to Rust because C++ is old and Rust is new. What I found when I was working with Rust was that I wished you'd write it like you write Go. As for Go I quite quickly wished it worked like Rust. So I guess you can't win with me?
These days we mainly use Typescript because it's useful to mainly use a single language in small teams since it allows the one frontend guy to go on vacations without a laptop. We still do some C#, some C and some Rust + the Python which runs our ML/AI/BI parts since that's what those people work with in my area of the world.
I agree that Rust makes it easier to program... But I'm not sure "you just have to force yourself to use it" is the best advert for Rust!
It's likely that they just haven't got to the point in their programming where they understand the need for the things Rust solves. Like if you only ever write 100 line Python scripts you probably haven't run into the performance issues or difficulties that come with working on large dynamically typed codebases.
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.
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.
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)
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.
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.
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.
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.
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. 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.
But I hope to get a suggestion for switching to the ext language in the real life. Like I’m quite proficient with swift language, I’m making money with it for years, so I consider my proficient comes not just from general computer science knowledge, but it comes from the getting o know the environment as well. Like I known the sdt lib, I know common caveats with the project, I have a pretty much experience it’s it after all.
And so I’ve tried rust. I mean it’s fantastic, it have awesome tooling, concise syntax and well crafted design, but I barely could write script with it. And I’m seeing clearly that this will lasts for a year or something, and even then I’ll suck at it towards an average senior dev focused on it a way beefier me.
So I really can’t crack it myself, like how do you folks switching to a new lang to get paid for it?
I've been using Rust for about five years, but I've never been paid for it and I'm not sure I ever will be. I just like it!
Personally I don't think it's worth trying to predict which technologies will be the most valuable and learning them based on that, unless you're struggling to make money right now. It sounds like Swift is working great as a money-maker for you right now, so I recommend just following your interests outside of that! Maybe they'll lead to another money-maker, maybe they won't and that's okay
I don't see Rust eating any domains outside of low-level systems development anytime soon, so I wouldn't worry that you're going to get left behind or something. It's not going to make Swift, or JavaScript, or Python, or Java, or Go, or many other things obsolete
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++.
Yep, exactly. The implementation - and more importantly, the contract - are much more dependable. For better and worse Rust is a language that leans all-in on abstraction, going to great lengths to make those as safe and scalable as possible, and if you aren't using them you're going to have a harder time than you need to
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)
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.
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.
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.
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!
This would infect the language ecosystem. People that use Rust are usually using it because they don't want the performance sacrifice that gc or reference counting would bring. I am convinced that one of the reasons D did not catch on is because it had gc, an anti feature for the target demographic. You could disable it but it split the community and some of the standard libraries weren't compatible. Moreover, just about every mainstream language has automatic memory management. There are plenty of choices for those that want that, Rust is really the only mainstream choice for its niche so it's for the best to not try to turn it into something else.
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.
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.
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.
> 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.
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.
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.
> 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).
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 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), I imagine something similar could be done to create refined types for matrices so you don't do matrix multiplication matrices of invalid sizes
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
>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.
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.
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.
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.
> 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.
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 Rustling exercises, read Zero to Production in Rust and did the project there, and still it's not clicking - 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.
So I'm not in a rush to rewrite anything written in Python just yet.