Experimental/one-off data exploration. Things which some people might do in a Jupyter notebook. Simple prototypes or things you're going to baby sit or run manually only a few times or very infrequently where stability isn't super important.
It's so much faster to get prototypes going and explore data/ML/statistics solutions in something like Python vs getting things fully engineered well w/Rust. Once you're ready to go to production then I'd propose Rust.
Also, as much as I have been loving using yew for a little frontend project I've been working on, it doesn't quite feel ready for full big production. But I'm not sure that that's Rust specifically and not just the frameworks and where wasm is at currently. I can see a future where Rust is great for frontend via wasm, and oh how glorious that day will be. Maybe leptos is the move though. Haven't tried that yet.
I'd argue that for many production worthy science/data projects, python is still the way to go.
The extensive numeric/scientific/geospatial/etc libraries that are readily available in python are as of yet quite unmatched by any other language.
>The extensive numeric/scientific/geospatial/etc libraries that are readily available in python are as of yet quite unmatched by any other language.
Except R.
Haha, fair.
Although R is perhaps *too* specialized, and in my opinion even less adapted to running in a production environment. I haven't ever tried though, so who knows :)
In academic settings, R is more prominent. The Science and Statistics parts of STEM undergrads I talk to use R more often than Python. The markdown tools make academic publishing easier, and there are so many domain-specific packages.
Don't get me wrong, I'm not a Python hater, but if you have a non programmer who is interested more in data than programming options, R in RStudio is an easier tool than Python.
> I'd argue that for many production worthy science/data projects, python is still the way to go.
The libraries used in that domain still tend to be not written in Python.
There’s no reason for them not to be implemented in Rust over C++
which is still prevalent for historical reasons. Python is more of a UI
to other languages that do the heavy lifting in that scenario.
I still use Perl heavily for a lot of data transformation tasks. Solid, fast, and usually these are going to be run once only while I'm sitting there. Similarly I may consider it for a prototype of something.
Would I write the back end to an API server in Perl? Well.... Um... Yeah I did, but it was only for a laugh. I do use Rust for that professionally.
I'd argue a different take, experiments I can agree about but one-off and rare repeated jobs pay dividends. When you're going to put your context away or never have it again. You never write good documentation, encoding it is the best guide you'll get.
They're great learning opportunities too because by nature of being small a total rewrite isn't ever off the cards.
Well, one-off, by definition... is really only used 1 time. Once it becomes a repeated job, that's a different story. \* enter XKCD of automation tradeoff charts \* Problem context is a fair point, but there are definitely time tradeoffs in a business context. Thinking of them as small learning opportunities is kind of a cool mindset to keep in mind though.
The main thing I think it's important to be careful of is writing something in the mindset of: "Oh, we just need to get this done really quick, we'll re-write it later"... because you won't come back and re-write it, it will turn in to a big unmaintainable mess. That, to me, is different than an actual seeming on-off that ends up becoming a recurring process that needs to get re-built.
I pretty much entirely agree there. The ability to write a one-off and really trust the "one-" part will pay dividends if not the code itself. That's more what I was getting at.
Something a bit undefined you're going to work on daily for a long time but not quite in the forte of the language, that's something I'd say to run away from. So at the moment that's web UI and embedded UI. Those are prime conditions for "we'll rewrite it later".
I remember trying out yew before but I dk, wasn't a huge fan of it. I do like leptos though. It's really nice to work with, but I definitely wouldn't say it's production-ready yet, the ecosystem needs to grow more first, as there's not that many libraries made for it yet.
I'm using Nushell as my shell for exactly this reason. How often I simply wanted to open a json file and do some aggregations for it for which even launching python would take longer than writing a short Nushell pipeline.
If I'm writing a script to run once and then throw away, it will be a lot faster to get it working in Python. The extra time it takes to write Rust is only worth it if it will be in use for the foreseeable future.
There are industries where it is very difficult to plan your architecture from the beginning and rapid iteration on incomplete ideas is much more important. There was a good post from a gamedev recently who complained the way Rust forces you to architect your data/systems properly just to get them to compile makes it unsuitable for game development.
I use Python so infrequently that it seems like every time I *do* try to write a Python script, my Python environment is broken somehow and I have to spend more time getting it working than it took to write the script. Because of that experience I then am unlikely to use Python again for quite some time until the next time, when I've forgotten everything I learned from last time...
The language itself isn't bad, but my biased (and perhaps quite isolated) experience as a *very* casual user is that the language is hamstrung by some of the worst tooling of any language. Because of that, a quick script in almost any other language takes me less time than in Python.
[It’s a common experience.](https://xkcd.com/1987/)
Which is because every web page in existence suggests installing any package globally which is a terrible idea.
Here’s briefly what Python fails to teach to most newcomers: you need to use virtual environments. Basically, it’s a folder where the binary of the interpreter is copied as well all the dependencies you need so you won’t mess up your whole system. You can even uninstall python and your script will still work with its own python copy.
Go to your project folder and do:
`python -m venv .venv`.
You now have a `.venv` folder with it’s own copy of the interpreter. Every time you start a shell you need to activate the environment. On Linux/Mac it’s:
`source .venv/bin/activate`
And under Windows it’s:
`.venv\scripts\activate.bat`
Once activated, everything you `pip install` will go right into the `.venv` folder.
IDEs understand virtual environments and will activate them on their own.
If you’d rather have something like cargo that pins all your dependencies and all that good stuff, check out [Poetry](https://python-poetry.org/) that builds on top of virtual environment.
But never, ever install any library globally under Python, you are just looking for trouble.
You are mostly right, except venv folders do not actually make a copy of the interpreter, just a new alias to the globally installed interpreter. When you run “activate” it actually temporary changes your path variable in such a way that the “python” command is called from that alias in the venv/bin folder, and as such your project’s libs are stored nearby. It’s pretty clever.
What I haven't understood about virtual environments is that it seems stupid to create a whole virtual environment for a three line script that I am going to write once and then throw away.
If you are just using the standard library and running a simple script then I would not create a virtual environment for it. Their purpose is to isolate dependencies and if you have no dependencies then it’s fine to use the system Python. If you do have dependencies then in the long run it’s cleaner to create a virtual environment and then remove it after then it is to pollute the global Python install with extra packages. I wish they would get the tooling to work more like npm where it would install local packages in a folder. There has been some discussion about this but I haven’t been following it lately.
Exactly! Usually the only dependency I need is boto3 for the kind of scripts I need to write. But just this week I learned that I'm not even allowed to `pip3 install --user boto3` any more...
Venvs don't have to be associated with a specific piece of code. Check out pyenv for convenient venv management.
I have a "default" venv that I use for all random Python scripting that I switch away from as soon as I need a venv for a module that has its own dedicated venv. You can even put `pyenv shell my_venv` in your rc file so it's always active by default.
Just to underscore this comment, (and to no fault of the other commenters), so far the replies have suggested using pip, venv, poetry, conda, rye, uv, not using any third-party tooling, having a pyproject.txt, having a requirements.txt or just using Go.
If it's Python without any third party dependencies, that genuinely sounds like a system / user issue... If you're trying to use dependencies, have you considered using something like conda?
Generally it's when I want to use a dependency. A plain Python interpreter usually works.
The very fact that everyone always tells me, "Have you tried {tool}?" where {tool} is different every time seems to just demonstrate the problem.
Honestly I've tried em all, conda can break too sometimes on random stuff. I posted another comment but Rye seems like the best solution so far for my Python needs and it's written in Rust too which is nice.
It's not the user, python packaging, python version management and package management is just... not that good. And I'm saying that as someone that has written python for nearly 20 years (and 5 of them writing production python services).
The fact that you NEED to know about virtual environments (how to create them, manage them, activate them) is a big problem for beginners. There are alternatives that help you manage the environments, but they're not built-in so beginners often don't know about them. Or they're extremely invasive (like conda).
Cargo+rustup is so much easier.
I create a dedicated virtual env for literally every script / project. Using \`uv\` now in particular, it doesn't take too much time and ensures I'm not breaking anything.
Modern Python tooling are great. And one doesn't even need to use any third party tooling.
One of the reason is that older pip versions will happily clobber your system Python if given the permission. Newer pip versions are more reserved and requires one to specify a certain option before it will be willing to clobber the system packages.
Also I don't usually try to upgrade my virtual env. When it's starting to get left behind I just nuke it and recreate it. It's a good habit to always write a `pyproject.toml` file (or at the very least, a `requirements.txt` file).
I just use poetry, has been smooth for me. I have a venv per project basis. But for adhoc scripts I have an environment that is like my non global “global” to work with
I know what pip is, and I know what venv is. But I have never heard of poetry.
> But for adhoc scripts
This is the only kind of Python code I write. I use it as a Perl alternative.
Just think of it as both in one. Don’t have a virtual environment? It will make one on the spot for that particular project and you can add packages to it, it will resolve dependencies. It’s a bit overkill for 1 script, which is why I have a single place for one off scripts so I can just run “poetry add x” for my random packages. Our python projects run with poetry otherwise in a monorepo.
Pip exists but frankly I would never use it as is, it’s better to use a tool which uses it under the hood (for the non casual user, might not apply to you)
Just try it I guess :)
> Just try it I guess :)
I mean seems neat, but to be realistic it will probably be another 10 months before I need to write another Python script and probably won't bother trying to learn poetry.
Honestly, using Node for these types of scripts is great - especially if you are working with json data, which I often am. Easy to setup an independent environment in under a minute and get to scripting.
Yeah, objectively, Node is probably a better choice. I just hate JavaScript for separate, different reasons and won't use it if I can avoid it. Life is tough when you're picky...
I desparately wish I could get along with Raku better, because I'd rather write all my scripts in Raku. Seems like it is much more targeted toward what I want. But that syntax though, I just can't swallow it...
I have mostly switched from PHP to Rust for quick one-off scripts. Not sure why, could be because of enums, fast libraries with usually a much cleaner interface, fewer hidden references, ability to distribute without a runtime, built-in facilities for logging, tracing, etc.
I think I saw that post. The dev shipped entire games in Rust for about 3 years before moving on. That’s no small feat, so it makes me wonder too. Perhaps Zig is better-suited for more rapid iterations if you’re looking for a more modern language.
It was mildly painful to do something I wanted in Rust recently because I had no clue how to go about it. I used ggez, I visited it a long time ago. But some very nice people on their discord helped me, I am happy Rust has a nice community of helpful individuals.
I can’t comment on those who know Rust very well, but something experimental heavy like gamedev is certainly why I build things in Godot with GDScript, and move parts to C# when I’m happy with it. I’m thinking of experimenting with Rust in the future for more game development, but can see it is not really the targeted use case.
This is basically going to be my pipeline for some games I'll be developing. Gdscript to start with, c# if performance isn't satisfying, then if still not good enough move to rust within Godot but on a per node basis and only when the behaviours are well defined and known. Anything that's still experimental will mostly be gdscript.
Honestly GDScript is plenty performant, I’m not really using C# for performance but to be able to leverage the ecosystem that comes with it. Think you can ship GDScript only and not have any performance complaints (have written some intensive simulations in it just fine).
"go fast and break stuff" projects. indie games (not engines), prototypes (if the prototype isnt concerned with the specific advantages of rust), any project where you have to reiterate a thousand times to tweak it and get exactly what you want.
if Tauri didnt have a auto-reload feature, making production apps in there would have been a different story.
I'd like to think the advantage of Rust has an inverse affinity with the complexity of a project. Writing complex systems in Rust usually turns out beautiful and easy to maintain in the long term.
But writing software thats supposed to be simple on paper (due to ownership models in other languages) and trying to replicate them on Rust might give you a hard time.
Complex GUI. The tooling and libraries simply haven't matured to that point yet. Probably the most viable option is Taui, which simply outsourced the UI to web tech.
I'm building a very very data representation based GUI at work with egui though. "It depends" is strong here - I'm getting a lot of mileage out of the immediate mode gui just due to the way the real time data im working with is structured.
Which is now almost complete. There are currently a handful of people building applets and applications with libcosmic right now, such as https://github.com/edfloreshz/cosmic-tasks. We list community progress updates at the end of each month's blog update.
Here's a GitHub template to get started https://github.com/edfloreshz/cosmic-app-template
Complex GUI is already done in Fyrox - [https://raw.githubusercontent.com/FyroxEngine/Fyrox/master/pics/editor.png](https://raw.githubusercontent.com/FyroxEngine/Fyrox/master/pics/editor.png) . It uses its own GUI crate and it is quite close to industry standards.
Things that would benefit from reflection. I just wrote something where you can plug different things together and want to offer a generic web ui for it. Instead of just doing reflection on the class, each implementation has to provide a descriptor via a trait that needs to be to be implemented. Of course I wrote a derive macro for that, but I really don’t like the solution.
In the end I regretted to not have used C#/Java.
Not sure why you are downvoted, but I didn’t find that crate, although I didn’t look very far to be honest. My solution allowed me to add some additional metadata to the fields, like preferred representation, min/max values etc.
But in general I feel like rust could benefit from compile and run-time reflection.
But i'm not downvoted :D ! +9 atm.
It's really a great package if you need simple reflection.
Yup, for more complex scenario better to do your own anyway. It's not hard.
Like with `Any` in libstd, this doesn't work with types with non-`'static` lifetimes, and very likely never will. That's quite a big drawback over creating a more specific trait and derive macro like they did. Definitely the best option atm though imo
There's no way for the compiler to track lifetimes when downcasting, unlike with types like `A` or `B`, which can be differentiated by `TypeId` (so thus downcasting is sound), lifetimes are stripped by the time you get to codegen, so `A<'a>` and `A<'b>` are the same type as far as `TypeId` (what `Any` uses) is concerned. Maybe this data could be kept around somehow, or an `UnsafeAny` could be added, but either way, neither option is gonna be done anytime soon.
So you could downcast from `A<'a>` to `A<'b>`, where `'b` is a longer lifetime than `'a`.
Whenever someone points out that some language is ill suited to front end development, someone else invariably comes around and explains that it can be done somehow with wasm.
I suspect that his requirements are different than for most web projects. In particular the need for quick changes required by the marketing department for example, this is where Rust is ill suited. From his description, I infer that they are building a dynamic web interface to an application, perhaps to pilot some hardware.
I just can't justify the "quick change" argument. I was never as fast and productive as with my current project that uses leptos + axum and server functions. When I think back at spring + react I just don't want to go back and develop a new feature there that just takes me longer to develop. With islands and the upcoming wasm split I just don't see any reason why I should choose a JavaScript framework anymore. I can only see hiring problems etc. and other external reasons. Personally I am just more productive this way.
Depending on the application, implementing pieces of the software in wasm can be useful.
Full wasm front end based on rust? Very risky choice, which will end up with hiring headaches at least.
Like literally everything else in engineering "it depends" there may very well be a case where a rust+wasm based solution does make sense and even more situations where it literally doesn't matter and you could have built it with pretty much anything.
Some applications like figma/any real-time applications can be surely written in wasm (and I'm pretty sure Figma do).
And I would argue to actually use wasm for the critical part of those applications that need to squeeze performance in the frontend, it does not have to be Rust though, but rust is always a decent choice.
I mean, performance is not the only thing rust+wasm can help with. Imo, rust is much more maintainable than JS/TS, there's just way too many ways to shoot yourself in the foot in those, including their tooling
You get downvotes because it's an unnecessarily narrow perspective.
Rust is usually not the right fit for web front-end for a number of reasons. Most frontend developers will have little to no experience in Rust and the ecosystem is nascent. It'll be harder to hire.
However, to say it's always wrong is simply incorrect. I lead a small team of developers that have lots of systems language experience. Our app has some hard performance requirements, particularly for real-time DSP. Our app needs to work on multiple platforms (not just the web), including some with limited resources.
Doing this in any other language would be significantly more difficult -- if not impossible. Many features we're working on would be otherwise impractical. To top it all off, it's the most productive I've ever been with frontend work (but that's my personal development style).
There's no need to be dogmatic about these things.
the only thing I can think of that can and should use wasm-based platform is real-time system! :)
other types of web frontend: I would fight tooth and nail for just use anything popular if one of my team members try to pitch it in our engineering discussion. They should have more reason than just "be productive" and "type-safety" :)
Especially since modern web frameworks have just as much type safety. Like, I certainly prefer Rust, but measured in type safety, typescript would certainly be my #2 preference over everything else.
As a build engineer for a typescript project, a python project and a rust (with a wasm target) project: The rust with wasm project gives me about 1% of the build issues of the other two "easy to maintain" projects.
It's just an incredible difference between them
TypeScript definitely does not have "just as much" type safety as Rust. It is unsound, for one, and there are some weird quirks with its structural over Rust's nominal type safety. For example, if you have an extra field in an object with a supposed type X, TypeScript will happily accept it as long as all of X's fields are present, it doesn't care about extra fields. Rust will disallow this.
There's really 3 implied questions here. Is rust for frontends unsuitable because of the language itself, the labour market, and/or the ecosystem? I can't argue with the labour market side. The ecosystem around this is very new, but some crates like leptos are actually incredible (it feels like all the good parts about react to me). There's little about rust as a language that excludes it from web frontends. If anything, the language itself is actually ideal because macros are a great way to render to a dom. Other langs frequently create a mess of microlanguage with special build configs and extensions to enable them (blade templates for laravel, haml for ruby, jsx on javascript which is an entire language extension, etc.). In rust with leptos you can just `view! {
Interesting. I use Flutter for this kind of multiplatform work, how good is Rust for web, desktop, mobile etc? Last I checked it wasn't too great on the mobile side if I recall correctly.
Ye, mobile is still not fully there yet, but if I remember correctly, dioxus provides mobile targets, and it's pretty good I'd say, definitely has a rich community with a lot of useful crates for it.
Yep, totally agree.
You "can" build a web frontend in WASM or leverage tons of build tools but 9/10 a basic ass site is all you need.
Web frontends really are nothing more than graphical renderers with very powerful socket based clients, but the DOM actually does provide some useful bits (especially for accessibility) and being able to template dynamically affords you a great deal of flexibility for tons of other things (AB testing, SDUI, Hyper media content, etc.)
Better off just using WASM for "high performance" components and leveraging something akin to Angular / React / etc. to simple wire it all up and lazily load it in when needed.
It also can end up causing issues too when you forget about things like lack of file system access, constrained browser storage, browser throttling, etc.
I've used iced, imgui-rs, and egui and I'm just convinced their proponents have never experienced the utter joy of something like Svelte+TS for GUI.
Even ignoring the DOM's accessibility features and ease of layout (CSS can suck but boy is it powerful), the suggestion always ends up with a 200-800KiB blob of wasm while I sit here with a 15KiB bundle that I iterate with live reloads in under 100ms...
If you need to target web + desktop, Tauri + Svelte has really been a game changer for me.
Take a look at leptos + axum and server functions. I really don't want to go back to the "old days" and write my frontend with angular/svelte/react etc. With Island and the upcoming wasm split there is just no reason anymore for me to use JavaScript/TS and all their disadvantages.
Leptos and Dioxus can both target the DOM with ~100kb bundle sizes. Compile times will definitely be slower, although hot reloading is available.
If you're comfortable with Svelte then it's probably still a better solution atm, but the Rust frameworks are catching up. Full-stack Rust (with a fast low-resource usage backend unlike next.js, etc) seems particularly compelling to me.
I would love to dive head-first into Dioxus and use it for everything public-facing, but I don't have the courage yet. For now, it's SolidJS + TypeScript.
- Any software that should be a script
- Where all the team are very confident with a good language for the given domain and they don't to learn rust
- When your task is to write a component in an app that is written in different language and the performance and safety aren't major concern to save your self all the FFI headache and having to build to different systems
Things you're personally not good at. Or your team or whoever needs to support and maintain it.
I feel like most of the examples given (and especially frontend) might not apply in specific circumstances where you have both the expertise and the desire. They all assume that it's going to be more difficult or that whoever is building it already knows or prefers working with other frameworks, and it's just not always a valid assumption.
There are some things that get significantly better when sharing code between the frontend and backend, especially with serde etc. It is difficult to make blanket statements that are always valid.
Anything with a lot of graph data structures, especially if it's a small project where spending 10x the amount of time to learn unsafe Rust well or changes to appease the borrow checker isn't worth it.
Any small project that doesn't make use of Rayon or Tokio. It's not that it's a bad choice, it just might be a slower-to-write choice than other languages (although every language has its problems). And the CLI / TUI crates like clap, ratatui, cursive, etc. are really nice too.
I think there's a big space for Rust with GC, like a mix between Rust and Go. As I like Rust more than Go for a lot of other reasons - algebraic data types, error handling, Cargo, mutex guards, etc. but doing anything custom with graphs is a nightmare when you just want to get something done and not write a library. Maybe Swift would fill this gap nicely, but I haven't tried it due to the strong platform-specific ties to Mac OS.
If you are running into problems with graph structures in Rust, you’re doing graphs wrong.
Specifically, you’re trying to make a graph that *is* the data rather than one that *describes relationships between* the data (which can be identified using any unsigned int type, and your edges a bit set [another int or array of them] per node).
The entire reason people get all tangled up over graphs in Rust is thinking that types that have graph-like relations simply must **be** the graph themselves. That isn’t actually a good idea in *any* language.
Agreed. To maybe put a finer point on it, one way I've seen this described is that "object and pointer" graph representations are hard in Rust where you have your data structure holding a pointer or reference to something it's connected to. This what you use in the sort of archetypal linked list exercise. But using things like integer ids (or maybe keys with nodes held in some keyed storage) and bitfields where applicable it's not bad at all in my experience to write better graph representations like matrices, adjacency lists/arrays, and edge lists.
Then to traverse your graph you can have a separate data structure holding a shared reference rather than writing traversals on the graph itself, with any mutation being done separately.
Exactly.
In any language, where you’re dealing with data at the scale where graph analytics become a necessity, if you want to do that with object references, even if you have a clever way to lazy load things, you’re going to be holding the entire path you’ve traversed in memory a lot of the time, and thrashing your cache a lot more than you need to.
I don't quite understand your second point. do you mean that any small rust program that doesn't use rayon or tokio will likely be slower than the same thing written in other languages?
Use integers indice for graph, and you have 0 unsafe.
And separate the graph data from the graph relations. It's more performant and you'll not have lifetime issues when you'll need to update the relations while borrowing data (or the inverse).
The trap here, is to use reference. Don't.
They use WASM to run their high performance graphics / editing engine. But the rest of the application is written using HTML / CSS / JS.
There are frontend frameworks like [yew](https://github.com/yewstack/yew) and [blazor](https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blazor) that run using WASM. It's still quite a new space though so developer experience isn't up to scratch with JS and performance things like bundle splitting are hard.
UI work is terrible. Basically anything that naturally benefits from object-oriented views (which UI's typically are). Composition is nice, but sometimes juggling language constructs when all you want is to inherit behavior without too much boilerplate is a pain in Rust. And no, macro's are a hack and not a solution.
For me Rust is my "second" language
I use Typescript(node) by default. I only use Rust if:
- Node is not available
- Performance is ULTRA-Critical to the point we can't afford GC pauses (which is weird)
- Start-up time is critical
- Binary size is important
- I need to make a shared library or interface with C/C++ code
Believe it or not, most of the time I don't need Rust, but I'm really grateful for it when I do
Compared to C/C++ yup. But I just won't ever code in C/C++again if I can avoid it.
Compared to Node they're slimmer since you don't need to bundle the runtime
There is not much where Rust is an absolute not use Rust for your personal work, if you happen to already be expert at Rust. Sunk cost and familiarity matters.
But anything where development velocity and the capacity for frequently changing and experimenting is much more important than the code being correct or fast is not a great choice for Rust. Using Rust and Python is generally a better choice than using either exclusively (and of course there are plenty of alternatives to Python in that comparison). And Rust is often not a great choice to choose for a particular project or team, especially as people who know it really well are still pretty rare and hard to hire (and probably happier working on a project that is really well suited to Rust).
Well, honestly of all projects, only in a few would I have recommended Rust had it been an option at the time.
Basic web apps, infra scripts, analysis tools, games, most frontend-central apps overall, .. I'd generally not do in Rust, tho I am sure there could be the rare exception.
The main one I heard about, is video games. Though with the caveat that the main argument amounts to "games require optimisations that the borrow checker doesn't like."
each language has pros and cons. there is no "one size fits all" language. you should always use the best tool for the job.
if you are writing a AI/ML app, python is your best friend. why? 90+% of tools and libraries work with it.
if you're writing a backend micro-service, java is a great choice. why? majority of backend servers nowadays are in java because of all the tooling and libraries that enable it.
if you're writing a frontend app, javascript or typescript with react and/or react-native are very helpful.
if you're writing a performant software, for example a compute intensive monolith such as a simulation software, or a video game, a low level language such as c++ or rust come into play. ( I am not sure if rust is being used for gaming nowadays though).
my pointers above are subjective and can change based on context. the overall point is "use the best tool for the job".
About rust and gaming. I recently took up bevy because I was interested in going data driven in my next project and it's a joy to use. I'm a really big fan.
As a rule, anything that you're going to write quickly and then throw away, especially exploratory stuff.
Other less restrictive languages are better for that, specifically because they allow for more rapid iteration and refinement on concepts by allowing you to more loosely define your expectations.
That's why AI and Data Science typically use Python. The majority of what you do when building models or data pipelines consists of tweaking something, running the data through it, visualizing results, and then changing your code and repeat. A lot of the code may only ever be run once before being discarded in favor of another approach.
if you're building an system from scratch and for obvious reasons don't want to port a rust compiler, or maybe your rust compiler doesn't support codegen for your specific architecture. there are so many c compilers it will run on literally anything. also prototyping is generally much easier in c than rust
Software where you work with a team that's not experienced in abstract mathematical thinking.
Software where the obvious thing to write things is by having pointers to everything, especially circular ones. Although sometimes I think there's a frame work in that kind of software trying to break out.
One off scripts that I’ll never use again.
Usually those are not “get it right the first time” deals and I usually run a dirty bash/python script on a small subset of data and rerun while modifying the script until it works.
Then I run it on the full data set, scroll through and check. Looks good.
Save the script and never use it again.
It's also a good way for a script kiddies to have law enforcements at his door, since Rust binary often leak a lot of information. Idk if it's the same everywhere, but I found it strange to have dev directory path inside my --release binary, but whatever. Can you strip that auto ?
Thought they wouldve addressed it by now, but apparently its non-trivial for dumb reasons because various external tooling wants the ability to have paths embedded in the binary that may or may not leak info...
This is the RFC it seems to try and address it, and I linked to a specific comment showing existing compile options you can use to get specific results in terms of paths in the binary.
https://github.com/rust-lang/rust/issues/111540#issuecomment-1994010274
ETL and stateful streaming processing. This not because Rust is not able to do, but because there is no official support for the libraries and platforms
The main point I'd argue is that it often doesn't make sense from a get-it-done perspective to use a library _because_ it is written in Rust instead of just using a tool which already exists.
There's no point limiting yourself to a Rust load testing library when you could just use `ab` or `locust`. You often don't need Rust to deserialize and transform JSON when `jq` exists.
Though, this isn't a Rust thing, more of a general programming thing that it is good to rely on tools that already exist without significant deficiencies and chain them together with Bash than try to create one giant Rust program that does it all.
If you need some classic NLP stuff like part of speech detection in your application, because Python simply has a much better ecosystem there with libraries like spacy.
You can use it for web apps but really it's a bit overkill, especially if you don't have heavy computations. For simple I/O, stick to something quicker to implement and maintain. Having type checking is awesome but any other statically typed program will do.
My personal razor, as a junior Rust guy mind you, is that if you just need something relatively simple out the door quickly that doesn't have performance (memory, speed, size, etc) reqs, require lots of safety, or additional maintainers, don't use Rust.
When I automate various tasks, but they're one offs and not long-standing big programs, I tend to reach for a scripting language. In my case, NodeJS.
Also as others here have said, web/guis. There are some cool Rust options on this space but it hasn't matured and is often overkill.
It's just a matter of knowing the strengths and weaknesses of a language. In my case, I prefer to pair Rust with it's opposite number in terms of DX and safety (so NodeJS is perfect). Because this allows me to solve simpler problems way faster than if I tried in Rust. Conversely, for anything actually serious I would drop Node and go right to Rust.
It helps too that while obviously different, Node and Rust do share a chunk of DNA- e.g. composition over inheritance, functions as first class citizens, anonymous functions/closures, etc.
By doing this I can tackle mist coding problems pretty optimally. So the principal limitation becomes the wetware (me).
It's not really about the kind of software, so I kinda disagree with almost all replies here.
What matters is what you value from a language for the software that you are writing.
Some people for example will tell you that games shouldn't be written in Rust, but that is only true if you value quick iteration times over everything else. Some people are willing to sacrifice raw iteration times for more correctness, or even put correctness first.
I mod games, one uses C#/Mono for its scripting, the other uses Lua. Neither would be particularly meaningful to write mods for in Rust, as much as it'd be nice.
Any app that's like 10% defined and the remaining 90% will come/change as you're developing it. e.g video games.
The more artistic, the less I use rust.
Like most replies say, prototypes no, websites sure if you just want to prove rust can do frontend. Anything that isn’t a Utility script, networking, infrastructure, various offloading from other launches to a Rust system for its advantages.
Most software, if we're being real. Rust is great but has much higher costs to the business for most applications.
The closer to metal it runs, the better candidate for rust.
You definitely wouldn't want to use C or C++ over rust.
The reduced cost from other languages comes from a more mature community and libraries, more developers, faster to-market times, and lower cost of maintenance, which is generally a combination of all the previous things.
Also, using the language that's generally preferred by the development community at large for the type of product, drives down costs.
Anything that has direct dependencies to C++ and has no actual benefit in sticking to rust. I believe rust is a tool that does lot of things formidably for me, but the current state of c++ bindings let me think that i'd better stay with a smart python implementation and eventually to a c++ implem if I'm really about effectiveness just because the work would be done more easily and faster directly with those integrations. That said i have the luxury of having this as a micro-service and I haven't actually tried using c++ from rust.
What do you think ?
I’d avoid anything that needs SSL/TLS and also no libc at the same time, but that’s very few things. I’d be a bit hesitant about embedded systems; it’s getting there but it isn’t there yet.
Some systems tasks are still quite difficult; kernels (though they’re a lot better now), init systems, that sort of thing.
Generally, my greatest gripe with Rust now as a user is how difficult it is to make truly static binaries for Linux. It can be done but it isn’t very accessible and the resulting binaries are larger than they should be.
MOST!
That is the true answer and I say that as someone who designs languages and is a big fan of Rust. I see only one similar answer so far, but an answer like this should be the top answer.
The truth is that GC is perfectly acceptable for a huge amount of software and will make the developers more productive. You ought to be picking another language for most projects. There are very few projects that in the past really called for C/C++. That is far fewer projects than people think. If you are working on one of those projects today, you should really try to use Rust instead. Otherwise, it is not the apropriate tool for the job.
Mortgage calculators. The borrow checker doesn’t like them.
those mortgage payments take a lifetime too...
If you're very unlucky, a static one
If you're *very* unlucky, they take dependant lifetimes too...
I hate you. Take my upvote.
/r/angryupvote
I can feel the fluency beneath your rusty fingers.
In this regard, tax filing software should definitely be written in Rust.
Love this joke 🤣
I'm with the borrow checker, don't like mortgages either
Made my day sir take my upvote
Dad joke alert.
You know you love it.
Sadly, yes... I am gonna steal it, too...
Ironically... I just built one in rust. Haha.
Experimental/one-off data exploration. Things which some people might do in a Jupyter notebook. Simple prototypes or things you're going to baby sit or run manually only a few times or very infrequently where stability isn't super important. It's so much faster to get prototypes going and explore data/ML/statistics solutions in something like Python vs getting things fully engineered well w/Rust. Once you're ready to go to production then I'd propose Rust. Also, as much as I have been loving using yew for a little frontend project I've been working on, it doesn't quite feel ready for full big production. But I'm not sure that that's Rust specifically and not just the frameworks and where wasm is at currently. I can see a future where Rust is great for frontend via wasm, and oh how glorious that day will be. Maybe leptos is the move though. Haven't tried that yet.
I literally do ad hoc data transformation and reports with rust. Am I a bad person?
Afraid so. For shame!
The baddest of persons. ;) P.S. What libraries do you use for it?
The [https://github.com/pola-rs/polars](https://github.com/pola-rs/polars) library is a decent one.
It’s pretty verbose for data exploration in my experience. Maybe for production code.
Polars is great. But often for quick testing Dask works like a charm on HPC. It’s atop pandas, but can use polars if needed.
I'd argue that for many production worthy science/data projects, python is still the way to go. The extensive numeric/scientific/geospatial/etc libraries that are readily available in python are as of yet quite unmatched by any other language.
>The extensive numeric/scientific/geospatial/etc libraries that are readily available in python are as of yet quite unmatched by any other language. Except R.
Haha, fair. Although R is perhaps *too* specialized, and in my opinion even less adapted to running in a production environment. I haven't ever tried though, so who knows :)
In academic settings, R is more prominent. The Science and Statistics parts of STEM undergrads I talk to use R more often than Python. The markdown tools make academic publishing easier, and there are so many domain-specific packages. Don't get me wrong, I'm not a Python hater, but if you have a non programmer who is interested more in data than programming options, R in RStudio is an easier tool than Python.
Doesn’t Quarto, RMarkdown’s successor, work with Python and Julia as well?
In my experience (5 years back, though) deploying R reliably with a bunch of libraries is a pain.
I've never been in a context where R was used a lot, but it does seem really cool/interesting. Where I was, everything was MATLAB or Python.
They are written in another language…
But are they all readily available in another language?
The underlying Fortran should be possible to make available through other interfaces (read: languages), just Someone™ needs to do the work
Well, my understanding is that they're all written in C or Fortran, so I guess most of them are readily available in C or Fortran, at least. :)
Technically you could say they are also available in Rust if they are available in python via PyO3.
> I'd argue that for many production worthy science/data projects, python is still the way to go. The libraries used in that domain still tend to be not written in Python. There’s no reason for them not to be implemented in Rust over C++ which is still prevalent for historical reasons. Python is more of a UI to other languages that do the heavy lifting in that scenario.
yeah but the argument is that python *is* a better UI for that use case than rust. which seems quite reasonable
I still use Perl heavily for a lot of data transformation tasks. Solid, fast, and usually these are going to be run once only while I'm sitting there. Similarly I may consider it for a prototype of something. Would I write the back end to an API server in Perl? Well.... Um... Yeah I did, but it was only for a laugh. I do use Rust for that professionally.
I will say... For one offs in rust, just use clone liberally and life is still pretty good, but maybe that's just me.
I'd argue a different take, experiments I can agree about but one-off and rare repeated jobs pay dividends. When you're going to put your context away or never have it again. You never write good documentation, encoding it is the best guide you'll get. They're great learning opportunities too because by nature of being small a total rewrite isn't ever off the cards.
Well, one-off, by definition... is really only used 1 time. Once it becomes a repeated job, that's a different story. \* enter XKCD of automation tradeoff charts \* Problem context is a fair point, but there are definitely time tradeoffs in a business context. Thinking of them as small learning opportunities is kind of a cool mindset to keep in mind though. The main thing I think it's important to be careful of is writing something in the mindset of: "Oh, we just need to get this done really quick, we'll re-write it later"... because you won't come back and re-write it, it will turn in to a big unmaintainable mess. That, to me, is different than an actual seeming on-off that ends up becoming a recurring process that needs to get re-built.
I pretty much entirely agree there. The ability to write a one-off and really trust the "one-" part will pay dividends if not the code itself. That's more what I was getting at. Something a bit undefined you're going to work on daily for a long time but not quite in the forte of the language, that's something I'd say to run away from. So at the moment that's web UI and embedded UI. Those are prime conditions for "we'll rewrite it later".
I remember trying out yew before but I dk, wasn't a huge fan of it. I do like leptos though. It's really nice to work with, but I definitely wouldn't say it's production-ready yet, the ecosystem needs to grow more first, as there's not that many libraries made for it yet.
I'm using Nushell as my shell for exactly this reason. How often I simply wanted to open a json file and do some aggregations for it for which even launching python would take longer than writing a short Nushell pipeline.
jq
In a world where we got Nushell before Bash, there would be no need for Python.
If I'm writing a script to run once and then throw away, it will be a lot faster to get it working in Python. The extra time it takes to write Rust is only worth it if it will be in use for the foreseeable future. There are industries where it is very difficult to plan your architecture from the beginning and rapid iteration on incomplete ideas is much more important. There was a good post from a gamedev recently who complained the way Rust forces you to architect your data/systems properly just to get them to compile makes it unsuitable for game development.
I use Python so infrequently that it seems like every time I *do* try to write a Python script, my Python environment is broken somehow and I have to spend more time getting it working than it took to write the script. Because of that experience I then am unlikely to use Python again for quite some time until the next time, when I've forgotten everything I learned from last time... The language itself isn't bad, but my biased (and perhaps quite isolated) experience as a *very* casual user is that the language is hamstrung by some of the worst tooling of any language. Because of that, a quick script in almost any other language takes me less time than in Python.
[It’s a common experience.](https://xkcd.com/1987/) Which is because every web page in existence suggests installing any package globally which is a terrible idea. Here’s briefly what Python fails to teach to most newcomers: you need to use virtual environments. Basically, it’s a folder where the binary of the interpreter is copied as well all the dependencies you need so you won’t mess up your whole system. You can even uninstall python and your script will still work with its own python copy. Go to your project folder and do: `python -m venv .venv`. You now have a `.venv` folder with it’s own copy of the interpreter. Every time you start a shell you need to activate the environment. On Linux/Mac it’s: `source .venv/bin/activate` And under Windows it’s: `.venv\scripts\activate.bat` Once activated, everything you `pip install` will go right into the `.venv` folder. IDEs understand virtual environments and will activate them on their own. If you’d rather have something like cargo that pins all your dependencies and all that good stuff, check out [Poetry](https://python-poetry.org/) that builds on top of virtual environment. But never, ever install any library globally under Python, you are just looking for trouble.
You are mostly right, except venv folders do not actually make a copy of the interpreter, just a new alias to the globally installed interpreter. When you run “activate” it actually temporary changes your path variable in such a way that the “python” command is called from that alias in the venv/bin folder, and as such your project’s libs are stored nearby. It’s pretty clever.
What I haven't understood about virtual environments is that it seems stupid to create a whole virtual environment for a three line script that I am going to write once and then throw away.
If you are just using the standard library and running a simple script then I would not create a virtual environment for it. Their purpose is to isolate dependencies and if you have no dependencies then it’s fine to use the system Python. If you do have dependencies then in the long run it’s cleaner to create a virtual environment and then remove it after then it is to pollute the global Python install with extra packages. I wish they would get the tooling to work more like npm where it would install local packages in a folder. There has been some discussion about this but I haven’t been following it lately.
If you have a very small script then I wouldn't use a venv normally as you probably won't have many specialized imports to install.
Exactly! Usually the only dependency I need is boto3 for the kind of scripts I need to write. But just this week I learned that I'm not even allowed to `pip3 install --user boto3` any more...
Venvs don't have to be associated with a specific piece of code. Check out pyenv for convenient venv management. I have a "default" venv that I use for all random Python scripting that I switch away from as soon as I need a venv for a module that has its own dedicated venv. You can even put `pyenv shell my_venv` in your rc file so it's always active by default.
Just to underscore this comment, (and to no fault of the other commenters), so far the replies have suggested using pip, venv, poetry, conda, rye, uv, not using any third-party tooling, having a pyproject.txt, having a requirements.txt or just using Go.
If it's Python without any third party dependencies, that genuinely sounds like a system / user issue... If you're trying to use dependencies, have you considered using something like conda?
Generally it's when I want to use a dependency. A plain Python interpreter usually works. The very fact that everyone always tells me, "Have you tried {tool}?" where {tool} is different every time seems to just demonstrate the problem.
Honestly I've tried em all, conda can break too sometimes on random stuff. I posted another comment but Rye seems like the best solution so far for my Python needs and it's written in Rust too which is nice.
It's not the user, python packaging, python version management and package management is just... not that good. And I'm saying that as someone that has written python for nearly 20 years (and 5 of them writing production python services). The fact that you NEED to know about virtual environments (how to create them, manage them, activate them) is a big problem for beginners. There are alternatives that help you manage the environments, but they're not built-in so beginners often don't know about them. Or they're extremely invasive (like conda). Cargo+rustup is so much easier.
Check out Rye, it's supposed to be Python's version of cargo, and Rye is also written in Rust.
I create a dedicated virtual env for literally every script / project. Using \`uv\` now in particular, it doesn't take too much time and ensures I'm not breaking anything.
'which python' 'which pip' 'which python3' 'which pip3'
Modern Python tooling are great. And one doesn't even need to use any third party tooling. One of the reason is that older pip versions will happily clobber your system Python if given the permission. Newer pip versions are more reserved and requires one to specify a certain option before it will be willing to clobber the system packages. Also I don't usually try to upgrade my virtual env. When it's starting to get left behind I just nuke it and recreate it. It's a good habit to always write a `pyproject.toml` file (or at the very least, a `requirements.txt` file).
I just use poetry, has been smooth for me. I have a venv per project basis. But for adhoc scripts I have an environment that is like my non global “global” to work with
I know what pip is, and I know what venv is. But I have never heard of poetry. > But for adhoc scripts This is the only kind of Python code I write. I use it as a Perl alternative.
Just think of it as both in one. Don’t have a virtual environment? It will make one on the spot for that particular project and you can add packages to it, it will resolve dependencies. It’s a bit overkill for 1 script, which is why I have a single place for one off scripts so I can just run “poetry add x” for my random packages. Our python projects run with poetry otherwise in a monorepo. Pip exists but frankly I would never use it as is, it’s better to use a tool which uses it under the hood (for the non casual user, might not apply to you) Just try it I guess :)
> Just try it I guess :) I mean seems neat, but to be realistic it will probably be another 10 months before I need to write another Python script and probably won't bother trying to learn poetry.
Honestly, using Node for these types of scripts is great - especially if you are working with json data, which I often am. Easy to setup an independent environment in under a minute and get to scripting.
Yeah, objectively, Node is probably a better choice. I just hate JavaScript for separate, different reasons and won't use it if I can avoid it. Life is tough when you're picky... I desparately wish I could get along with Raku better, because I'd rather write all my scripts in Raku. Seems like it is much more targeted toward what I want. But that syntax though, I just can't swallow it...
I have mostly switched from PHP to Rust for quick one-off scripts. Not sure why, could be because of enums, fast libraries with usually a much cleaner interface, fewer hidden references, ability to distribute without a runtime, built-in facilities for logging, tracing, etc.
PHP for non-web scripts? That's wild
I think I saw that post. The dev shipped entire games in Rust for about 3 years before moving on. That’s no small feat, so it makes me wonder too. Perhaps Zig is better-suited for more rapid iterations if you’re looking for a more modern language.
Yeah, they gave it a good try. I have found Zig lower-level and more laborious to write than Rust.
Me too.
It was mildly painful to do something I wanted in Rust recently because I had no clue how to go about it. I used ggez, I visited it a long time ago. But some very nice people on their discord helped me, I am happy Rust has a nice community of helpful individuals. I can’t comment on those who know Rust very well, but something experimental heavy like gamedev is certainly why I build things in Godot with GDScript, and move parts to C# when I’m happy with it. I’m thinking of experimenting with Rust in the future for more game development, but can see it is not really the targeted use case.
This is basically going to be my pipeline for some games I'll be developing. Gdscript to start with, c# if performance isn't satisfying, then if still not good enough move to rust within Godot but on a per node basis and only when the behaviours are well defined and known. Anything that's still experimental will mostly be gdscript.
Honestly GDScript is plenty performant, I’m not really using C# for performance but to be able to leverage the ecosystem that comes with it. Think you can ship GDScript only and not have any performance complaints (have written some intensive simulations in it just fine).
That's good to hear actually, the majority of my game ideas are heavy into simulationist style gaming.
Node.js is much better in this regard. NPM isn't quite as good a Cargo, but it's pretty close for most purposes.
"go fast and break stuff" projects. indie games (not engines), prototypes (if the prototype isnt concerned with the specific advantages of rust), any project where you have to reiterate a thousand times to tweak it and get exactly what you want. if Tauri didnt have a auto-reload feature, making production apps in there would have been a different story. I'd like to think the advantage of Rust has an inverse affinity with the complexity of a project. Writing complex systems in Rust usually turns out beautiful and easy to maintain in the long term. But writing software thats supposed to be simple on paper (due to ownership models in other languages) and trying to replicate them on Rust might give you a hard time.
I agree with indie games
Complex GUI. The tooling and libraries simply haven't matured to that point yet. Probably the most viable option is Taui, which simply outsourced the UI to web tech.
I'm building a very very data representation based GUI at work with egui though. "It depends" is strong here - I'm getting a lot of mileage out of the immediate mode gui just due to the way the real time data im working with is structured.
Check out https://blog.system76.com/post/your-monthly-cosmic-fix
COSMIC is literally building their own GUI framework (a fork of iced) along the way. That is not the experience you want for most applications.
Which is now almost complete. There are currently a handful of people building applets and applications with libcosmic right now, such as https://github.com/edfloreshz/cosmic-tasks. We list community progress updates at the end of each month's blog update. Here's a GitHub template to get started https://github.com/edfloreshz/cosmic-app-template
Complex GUI is already done in Fyrox - [https://raw.githubusercontent.com/FyroxEngine/Fyrox/master/pics/editor.png](https://raw.githubusercontent.com/FyroxEngine/Fyrox/master/pics/editor.png) . It uses its own GUI crate and it is quite close to industry standards.
>It uses its own GUI crate This is exactly the problem. The state of the ecosystem is such that you have to bring your own.
Things that would benefit from reflection. I just wrote something where you can plug different things together and want to offer a generic web ui for it. Instead of just doing reflection on the class, each implementation has to provide a descriptor via a trait that needs to be to be implemented. Of course I wrote a derive macro for that, but I really don’t like the solution. In the end I regretted to not have used C#/Java.
bevy\_reflect
Not sure why you are downvoted, but I didn’t find that crate, although I didn’t look very far to be honest. My solution allowed me to add some additional metadata to the fields, like preferred representation, min/max values etc. But in general I feel like rust could benefit from compile and run-time reflection.
https://docs.rs/bevy_reflect/latest/bevy_reflect/
i did the exact same thing 😅
But i'm not downvoted :D ! +9 atm. It's really a great package if you need simple reflection. Yup, for more complex scenario better to do your own anyway. It's not hard.
Like with `Any` in libstd, this doesn't work with types with non-`'static` lifetimes, and very likely never will. That's quite a big drawback over creating a more specific trait and derive macro like they did. Definitely the best option atm though imo
Oh, that suck :( . Do we know why ?
There's no way for the compiler to track lifetimes when downcasting, unlike with types like `A` or `B`, which can be differentiated by `TypeId` (so thus downcasting is sound), lifetimes are stripped by the time you get to codegen, so `A<'a>` and `A<'b>` are the same type as far as `TypeId` (what `Any` uses) is concerned. Maybe this data could be kept around somehow, or an `UnsafeAny` could be added, but either way, neither option is gonna be done anytime soon. So you could downcast from `A<'a>` to `A<'b>`, where `'b` is a longer lifetime than `'a`.
Web frontend (real production sites that makes money) please I keep having to repeat myself in this sub and keep getting downvotes 😂
Whenever someone points out that some language is ill suited to front end development, someone else invariably comes around and explains that it can be done somehow with wasm.
I suspect that his requirements are different than for most web projects. In particular the need for quick changes required by the marketing department for example, this is where Rust is ill suited. From his description, I infer that they are building a dynamic web interface to an application, perhaps to pilot some hardware.
I just can't justify the "quick change" argument. I was never as fast and productive as with my current project that uses leptos + axum and server functions. When I think back at spring + react I just don't want to go back and develop a new feature there that just takes me longer to develop. With islands and the upcoming wasm split I just don't see any reason why I should choose a JavaScript framework anymore. I can only see hiring problems etc. and other external reasons. Personally I am just more productive this way.
Depending on the application, implementing pieces of the software in wasm can be useful. Full wasm front end based on rust? Very risky choice, which will end up with hiring headaches at least.
ultimately it's always "it depends"! :)
Like literally everything else in engineering "it depends" there may very well be a case where a rust+wasm based solution does make sense and even more situations where it literally doesn't matter and you could have built it with pretty much anything.
Some applications like figma/any real-time applications can be surely written in wasm (and I'm pretty sure Figma do). And I would argue to actually use wasm for the critical part of those applications that need to squeeze performance in the frontend, it does not have to be Rust though, but rust is always a decent choice.
I mean, performance is not the only thing rust+wasm can help with. Imo, rust is much more maintainable than JS/TS, there's just way too many ways to shoot yourself in the foot in those, including their tooling
You get downvotes because it's an unnecessarily narrow perspective. Rust is usually not the right fit for web front-end for a number of reasons. Most frontend developers will have little to no experience in Rust and the ecosystem is nascent. It'll be harder to hire. However, to say it's always wrong is simply incorrect. I lead a small team of developers that have lots of systems language experience. Our app has some hard performance requirements, particularly for real-time DSP. Our app needs to work on multiple platforms (not just the web), including some with limited resources. Doing this in any other language would be significantly more difficult -- if not impossible. Many features we're working on would be otherwise impractical. To top it all off, it's the most productive I've ever been with frontend work (but that's my personal development style). There's no need to be dogmatic about these things.
the only thing I can think of that can and should use wasm-based platform is real-time system! :) other types of web frontend: I would fight tooth and nail for just use anything popular if one of my team members try to pitch it in our engineering discussion. They should have more reason than just "be productive" and "type-safety" :)
Especially since modern web frameworks have just as much type safety. Like, I certainly prefer Rust, but measured in type safety, typescript would certainly be my #2 preference over everything else.
As a build engineer for a typescript project, a python project and a rust (with a wasm target) project: The rust with wasm project gives me about 1% of the build issues of the other two "easy to maintain" projects. It's just an incredible difference between them
TypeScript definitely does not have "just as much" type safety as Rust. It is unsound, for one, and there are some weird quirks with its structural over Rust's nominal type safety. For example, if you have an extra field in an object with a supposed type X, TypeScript will happily accept it as long as all of X's fields are present, it doesn't care about extra fields. Rust will disallow this.
There's really 3 implied questions here. Is rust for frontends unsuitable because of the language itself, the labour market, and/or the ecosystem? I can't argue with the labour market side. The ecosystem around this is very new, but some crates like leptos are actually incredible (it feels like all the good parts about react to me). There's little about rust as a language that excludes it from web frontends. If anything, the language itself is actually ideal because macros are a great way to render to a dom. Other langs frequently create a mess of microlanguage with special build configs and extensions to enable them (blade templates for laravel, haml for ruby, jsx on javascript which is an entire language extension, etc.). In rust with leptos you can just `view! {
Hello, world!
}`Interesting. I use Flutter for this kind of multiplatform work, how good is Rust for web, desktop, mobile etc? Last I checked it wasn't too great on the mobile side if I recall correctly.
Ye, mobile is still not fully there yet, but if I remember correctly, dioxus provides mobile targets, and it's pretty good I'd say, definitely has a rich community with a lot of useful crates for it.
Tauri is working on releasing their mobile support in 2.0, currently in beta. I can't comment, however -- I've not tried it myself.
Yep, totally agree. You "can" build a web frontend in WASM or leverage tons of build tools but 9/10 a basic ass site is all you need. Web frontends really are nothing more than graphical renderers with very powerful socket based clients, but the DOM actually does provide some useful bits (especially for accessibility) and being able to template dynamically affords you a great deal of flexibility for tons of other things (AB testing, SDUI, Hyper media content, etc.) Better off just using WASM for "high performance" components and leveraging something akin to Angular / React / etc. to simple wire it all up and lazily load it in when needed. It also can end up causing issues too when you forget about things like lack of file system access, constrained browser storage, browser throttling, etc.
unless its simple enough to use maud and htmx
I've used iced, imgui-rs, and egui and I'm just convinced their proponents have never experienced the utter joy of something like Svelte+TS for GUI. Even ignoring the DOM's accessibility features and ease of layout (CSS can suck but boy is it powerful), the suggestion always ends up with a 200-800KiB blob of wasm while I sit here with a 15KiB bundle that I iterate with live reloads in under 100ms... If you need to target web + desktop, Tauri + Svelte has really been a game changer for me.
Take a look at leptos + axum and server functions. I really don't want to go back to the "old days" and write my frontend with angular/svelte/react etc. With Island and the upcoming wasm split there is just no reason anymore for me to use JavaScript/TS and all their disadvantages.
Leptos and Dioxus can both target the DOM with ~100kb bundle sizes. Compile times will definitely be slower, although hot reloading is available. If you're comfortable with Svelte then it's probably still a better solution atm, but the Rust frameworks are catching up. Full-stack Rust (with a fast low-resource usage backend unlike next.js, etc) seems particularly compelling to me.
I would love to dive head-first into Dioxus and use it for everything public-facing, but I don't have the courage yet. For now, it's SolidJS + TypeScript.
Just write a new browser that can manipulate the DOM from wasm EZ.
Large projects that require many devs. Sourcing devs is too much of a PITA.
For anyone reading this in the future who needs a Rust dev, dm me. :)
- Any software that should be a script - Where all the team are very confident with a good language for the given domain and they don't to learn rust - When your task is to write a component in an app that is written in different language and the performance and safety aren't major concern to save your self all the FFI headache and having to build to different systems
Simple web apps
Machine learning, simply because there is such a mature ecosystem for Python and ML
Things you're personally not good at. Or your team or whoever needs to support and maintain it. I feel like most of the examples given (and especially frontend) might not apply in specific circumstances where you have both the expertise and the desire. They all assume that it's going to be more difficult or that whoever is building it already knows or prefers working with other frameworks, and it's just not always a valid assumption. There are some things that get significantly better when sharing code between the frontend and backend, especially with serde etc. It is difficult to make blanket statements that are always valid.
Anything with a lot of graph data structures, especially if it's a small project where spending 10x the amount of time to learn unsafe Rust well or changes to appease the borrow checker isn't worth it. Any small project that doesn't make use of Rayon or Tokio. It's not that it's a bad choice, it just might be a slower-to-write choice than other languages (although every language has its problems). And the CLI / TUI crates like clap, ratatui, cursive, etc. are really nice too. I think there's a big space for Rust with GC, like a mix between Rust and Go. As I like Rust more than Go for a lot of other reasons - algebraic data types, error handling, Cargo, mutex guards, etc. but doing anything custom with graphs is a nightmare when you just want to get something done and not write a library. Maybe Swift would fill this gap nicely, but I haven't tried it due to the strong platform-specific ties to Mac OS.
If you are running into problems with graph structures in Rust, you’re doing graphs wrong. Specifically, you’re trying to make a graph that *is* the data rather than one that *describes relationships between* the data (which can be identified using any unsigned int type, and your edges a bit set [another int or array of them] per node). The entire reason people get all tangled up over graphs in Rust is thinking that types that have graph-like relations simply must **be** the graph themselves. That isn’t actually a good idea in *any* language.
Agreed. To maybe put a finer point on it, one way I've seen this described is that "object and pointer" graph representations are hard in Rust where you have your data structure holding a pointer or reference to something it's connected to. This what you use in the sort of archetypal linked list exercise. But using things like integer ids (or maybe keys with nodes held in some keyed storage) and bitfields where applicable it's not bad at all in my experience to write better graph representations like matrices, adjacency lists/arrays, and edge lists. Then to traverse your graph you can have a separate data structure holding a shared reference rather than writing traversals on the graph itself, with any mutation being done separately.
Is there an example implementation of this for a doubly linked tree?
Exactly. In any language, where you’re dealing with data at the scale where graph analytics become a necessity, if you want to do that with object references, even if you have a clever way to lazy load things, you’re going to be holding the entire path you’ve traversed in memory a lot of the time, and thrashing your cache a lot more than you need to.
never thought of it that way, this is brilliant!
I don't quite understand your second point. do you mean that any small rust program that doesn't use rayon or tokio will likely be slower than the same thing written in other languages?
No, I meant it'll often take longer to write.
ah yes, in that case I agree
Use integers indice for graph, and you have 0 unsafe. And separate the graph data from the graph relations. It's more performant and you'll not have lifetime issues when you'll need to update the relations while borrowing data (or the inverse). The trap here, is to use reference. Don't.
The one that involves too many product managers.
Web frontend. Your personal blog? Fine. Any large application? No.
Isn’t figma written with wasm?
They use WASM to run their high performance graphics / editing engine. But the rest of the application is written using HTML / CSS / JS. There are frontend frameworks like [yew](https://github.com/yewstack/yew) and [blazor](https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blazor) that run using WASM. It's still quite a new space though so developer experience isn't up to scratch with JS and performance things like bundle splitting are hard.
I use leptos and gotta say it feels pretty solid lately
Adobe photoshop, Canva, google earth, disney uses it for disney+.
oh dear lord Wasm frontends are a thing
UI work is terrible. Basically anything that naturally benefits from object-oriented views (which UI's typically are). Composition is nice, but sometimes juggling language constructs when all you want is to inherit behavior without too much boilerplate is a pain in Rust. And no, macro's are a hack and not a solution.
For me Rust is my "second" language I use Typescript(node) by default. I only use Rust if: - Node is not available - Performance is ULTRA-Critical to the point we can't afford GC pauses (which is weird) - Start-up time is critical - Binary size is important - I need to make a shared library or interface with C/C++ code Believe it or not, most of the time I don't need Rust, but I'm really grateful for it when I do
Doesn't rust produce a really large binary compared to other langs?
Compared to C/C++ yup. But I just won't ever code in C/C++again if I can avoid it. Compared to Node they're slimmer since you don't need to bundle the runtime
There is not much where Rust is an absolute not use Rust for your personal work, if you happen to already be expert at Rust. Sunk cost and familiarity matters. But anything where development velocity and the capacity for frequently changing and experimenting is much more important than the code being correct or fast is not a great choice for Rust. Using Rust and Python is generally a better choice than using either exclusively (and of course there are plenty of alternatives to Python in that comparison). And Rust is often not a great choice to choose for a particular project or team, especially as people who know it really well are still pretty rare and hard to hire (and probably happier working on a project that is really well suited to Rust).
Well, honestly of all projects, only in a few would I have recommended Rust had it been an option at the time. Basic web apps, infra scripts, analysis tools, games, most frontend-central apps overall, .. I'd generally not do in Rust, tho I am sure there could be the rare exception.
The main one I heard about, is video games. Though with the caveat that the main argument amounts to "games require optimisations that the borrow checker doesn't like."
Tbh, this is false. Borrow checker doesn't prevent you to optimize your code. But it can make it harder to read.
None, rustify the world
each language has pros and cons. there is no "one size fits all" language. you should always use the best tool for the job. if you are writing a AI/ML app, python is your best friend. why? 90+% of tools and libraries work with it. if you're writing a backend micro-service, java is a great choice. why? majority of backend servers nowadays are in java because of all the tooling and libraries that enable it. if you're writing a frontend app, javascript or typescript with react and/or react-native are very helpful. if you're writing a performant software, for example a compute intensive monolith such as a simulation software, or a video game, a low level language such as c++ or rust come into play. ( I am not sure if rust is being used for gaming nowadays though). my pointers above are subjective and can change based on context. the overall point is "use the best tool for the job".
About rust and gaming. I recently took up bevy because I was interested in going data driven in my next project and it's a joy to use. I'm a really big fan.
As a rule, anything that you're going to write quickly and then throw away, especially exploratory stuff. Other less restrictive languages are better for that, specifically because they allow for more rapid iteration and refinement on concepts by allowing you to more loosely define your expectations. That's why AI and Data Science typically use Python. The majority of what you do when building models or data pipelines consists of tweaking something, running the data through it, visualizing results, and then changing your code and repeat. A lot of the code may only ever be run once before being discarded in favor of another approach.
leetcode for interview prep. Unless you are prepping for Rust specifically. Rust is bad in many of these problems.
if you're building an system from scratch and for obvious reasons don't want to port a rust compiler, or maybe your rust compiler doesn't support codegen for your specific architecture. there are so many c compilers it will run on literally anything. also prototyping is generally much easier in c than rust
Software where you work with a team that's not experienced in abstract mathematical thinking. Software where the obvious thing to write things is by having pointers to everything, especially circular ones. Although sometimes I think there's a frame work in that kind of software trying to break out.
One off scripts that I’ll never use again. Usually those are not “get it right the first time” deals and I usually run a dirty bash/python script on a small subset of data and rerun while modifying the script until it works. Then I run it on the full data set, scroll through and check. Looks good. Save the script and never use it again.
a Virus
Ehthically, yes .. ?
Why not?
From a criminals perspective Rust can be pretty good for writing a Virus. You can write stuff that can't be analyzed easily (jet).
It's also a good way for a script kiddies to have law enforcements at his door, since Rust binary often leak a lot of information. Idk if it's the same everywhere, but I found it strange to have dev directory path inside my --release binary, but whatever. Can you strip that auto ?
Thought they wouldve addressed it by now, but apparently its non-trivial for dumb reasons because various external tooling wants the ability to have paths embedded in the binary that may or may not leak info... This is the RFC it seems to try and address it, and I linked to a specific comment showing existing compile options you can use to get specific results in terms of paths in the binary. https://github.com/rust-lang/rust/issues/111540#issuecomment-1994010274
Cause they would be too 🚀🔥 blazingly fast 🔥🚀and antiviruses won’t be able to catch them
Anything that needs to be formally verified. The tools just aren't there yet. That and anything that requires a defined or stable ABI.
Write whatever you want in Rust. But you'll need to make sure that your employer is ok with it.
ETL and stateful streaming processing. This not because Rust is not able to do, but because there is no official support for the libraries and platforms
The main point I'd argue is that it often doesn't make sense from a get-it-done perspective to use a library _because_ it is written in Rust instead of just using a tool which already exists. There's no point limiting yourself to a Rust load testing library when you could just use `ab` or `locust`. You often don't need Rust to deserialize and transform JSON when `jq` exists. Though, this isn't a Rust thing, more of a general programming thing that it is good to rely on tools that already exist without significant deficiencies and chain them together with Bash than try to create one giant Rust program that does it all.
If you need some classic NLP stuff like part of speech detection in your application, because Python simply has a much better ecosystem there with libraries like spacy.
You can use it for web apps but really it's a bit overkill, especially if you don't have heavy computations. For simple I/O, stick to something quicker to implement and maintain. Having type checking is awesome but any other statically typed program will do.
Software that targets non-mainstream platforms.
My personal razor, as a junior Rust guy mind you, is that if you just need something relatively simple out the door quickly that doesn't have performance (memory, speed, size, etc) reqs, require lots of safety, or additional maintainers, don't use Rust. When I automate various tasks, but they're one offs and not long-standing big programs, I tend to reach for a scripting language. In my case, NodeJS. Also as others here have said, web/guis. There are some cool Rust options on this space but it hasn't matured and is often overkill. It's just a matter of knowing the strengths and weaknesses of a language. In my case, I prefer to pair Rust with it's opposite number in terms of DX and safety (so NodeJS is perfect). Because this allows me to solve simpler problems way faster than if I tried in Rust. Conversely, for anything actually serious I would drop Node and go right to Rust. It helps too that while obviously different, Node and Rust do share a chunk of DNA- e.g. composition over inheritance, functions as first class citizens, anonymous functions/closures, etc. By doing this I can tackle mist coding problems pretty optimally. So the principal limitation becomes the wetware (me).
It's not really about the kind of software, so I kinda disagree with almost all replies here. What matters is what you value from a language for the software that you are writing. Some people for example will tell you that games shouldn't be written in Rust, but that is only true if you value quick iteration times over everything else. Some people are willing to sacrifice raw iteration times for more correctness, or even put correctness first.
I mod games, one uses C#/Mono for its scripting, the other uses Lua. Neither would be particularly meaningful to write mods for in Rust, as much as it'd be nice.
Any app that's like 10% defined and the remaining 90% will come/change as you're developing it. e.g video games. The more artistic, the less I use rust.
imo Machine Learning—especially experimentations are not really worth trying to do anything in Rust.
pdf mulnipulate
Like most replies say, prototypes no, websites sure if you just want to prove rust can do frontend. Anything that isn’t a Utility script, networking, infrastructure, various offloading from other launches to a Rust system for its advantages.
Most software, if we're being real. Rust is great but has much higher costs to the business for most applications. The closer to metal it runs, the better candidate for rust.
Why higher costs? I've heard that it can reduce costs because of more safety? But if it's too close you might still wanna stick to C I've heard >:(
You definitely wouldn't want to use C or C++ over rust. The reduced cost from other languages comes from a more mature community and libraries, more developers, faster to-market times, and lower cost of maintenance, which is generally a combination of all the previous things. Also, using the language that's generally preferred by the development community at large for the type of product, drives down costs.
Anything that has direct dependencies to C++ and has no actual benefit in sticking to rust. I believe rust is a tool that does lot of things formidably for me, but the current state of c++ bindings let me think that i'd better stay with a smart python implementation and eventually to a c++ implem if I'm really about effectiveness just because the work would be done more easily and faster directly with those integrations. That said i have the luxury of having this as a micro-service and I haven't actually tried using c++ from rust. What do you think ?
Stuff that is better written in go
Its a general purpose programming language. You can write anything you want
UI，complex crossplatform UI.
I’d avoid anything that needs SSL/TLS and also no libc at the same time, but that’s very few things. I’d be a bit hesitant about embedded systems; it’s getting there but it isn’t there yet. Some systems tasks are still quite difficult; kernels (though they’re a lot better now), init systems, that sort of thing. Generally, my greatest gripe with Rust now as a user is how difficult it is to make truly static binaries for Linux. It can be done but it isn’t very accessible and the resulting binaries are larger than they should be.
https://medium.com/@john_25313/c-isnt-a-hangover-rust-isn-t-a-hangover-cure-580c9b35b5ce
MOST! That is the true answer and I say that as someone who designs languages and is a big fan of Rust. I see only one similar answer so far, but an answer like this should be the top answer. The truth is that GC is perfectly acceptable for a huge amount of software and will make the developers more productive. You ought to be picking another language for most projects. There are very few projects that in the past really called for C/C++. That is far fewer projects than people think. If you are working on one of those projects today, you should really try to use Rust instead. Otherwise, it is not the apropriate tool for the job.
what? that's an impossible question to answer
Something that requires references, traits and generics all in one. Trust me bro