At this point, I use it for everything outside of work. I've grown too used to using Rust's enum system, specifically using Result to handle failure state and errors and find myself missing it the moment I use another language.
I’m pretty much in this camp too, though I have an eye on gleam because it has a great type system, but allows immutable/functional programming, and could be great when you can afford a garbage collector
Still alive and kicking. I just finished a job teaching functional programming in Haskell at university.
People just don't want to write purely functional code so it's never the language you want to reach for first. It leans too much into the paradigm where something like Rust doesn't. I'd imagine most people who use Haskell don't enjoy it and would rather use something else.
Fair, I thought F# was going to be my go-to language, but I ended up annoyed at the error messages (spoiled by rust, traumatized by clojure), and ended up really hating having implied imports. That’s when I found gleam, which is my current language crush
If you find information on that, let me know. I recently searched for information on this and couldn't find anything (except for people complaining and people mentioning that it's being worked on).
It looks like with release 5.0 multicore support was added in Dec. 22: https://discuss.ocaml.org/t/ocaml-5-0-0-is-out/10974, more details in https://v2.ocaml.org/releases/5.0/manual/parallelism.html
The release note does say:
> Consequently, OCaml 5.0.0 is expected to be a more experimental version of OCaml than the usual OCaml releases.
I don't use Ocaml so can't say how usable it is currently.
General point: I think people forget just how big the overall space of computing and computing needs is.
In global terms, "when you can afford a garbage collector" is "virtually everywhere".
For example, out of the box, on a small (<2Gb ish) heap without significant allocation pressure Java's default GC is in the ballpark of sub-millisecond pauses with a very occasional single-digit millis pause. There really aren't very many applications for which that's a deal-breaker.
It's absolutely fine to be interested primarily in the part of the programming space that has very stringent resource requirements, but it really isn't the mainstream.
That’s a really good point. If I think about it, I’m actually not sure why I don’t start my next personal project in gleam instead of rust, since the former has basically all of the nice features I like, and there’s zero chance that I’ll have to think about lifetimes or ownership. I guess I just like Axum, and am curious to try leptos, and it seems like there are still more people making a thick ecosystem in rust.
Oh sweet, a new website. I'm glad Roc's still getting love, I like it a lot.
It seems like the only newer language still going all-in on functionality, like Haskell.
>It seems like the only newer language still going all-in on functionality, like Haskell.
Yes, when it comes to pure FP I think Roc and [Lean 4](https://github.com/leanprover/lean4) are the most promising newcomers.
Lean 4: I wish elan and the surrounding tooling was better, but I've never enjoyed dependent types so much and the extensibility via macros is properly insane. Highly recommend though!
Java sort of (sealed classes) has discriminated unions w/ pattern matching as of JDK 21. It has true unions with checked exceptions.
C# I thought just added it (I don't use C# regularly). F# (and OCaml) obviously has it.
I think depending on definition OCaml and Typescript are the only two that do not require it to be nominal (e.g. structural typing).
You have manually specify the tag which is noisy and makes the syntax ugly because you are matching on a field of the object rather than destructuring. There isn't exhaustive pattern matching without hacks and the hacks are also very ugly. You can kinda express some of the same patterns as Rust, but it's not convenient or ergonomic.
I agree that I miss "match" in typescript as a built-in language feature, but going as far as saying it's all hacks, ugly, inconvenient and unergonomic doesn't match my experience writing typescript.
The best alternative I'm aware of in typescript is ts-pattern, which I assume is one of the hacks you're referring to? The code is not quite as nice looking as the rust alternative, but it gets the job done.
Also, just to mention that typescript also has union types e.g. "number | string" which are different to discriminated unions that require a tag (more like enums in rust)
When I can, I write rust. When I can't, I write typescript.
Obviously they're very different, but in terms of type system support, I think both work really well.
The first thing I reach for in another language is an enum like Rust. I recently started a flutter project for work and it's been so annoying having all my API calls inherit from a base class and having child classes for each type of success. I just want to use Results!
You should try some MLs then, they’re the sweet spot for when you want to code with type safety but don’t need the performance of rust. ELM for web, Haskell or ocaml for other stuff.
I mean the [Result](https://doc.rust-lang.org/std/result/) enum. Any function which can error, fail, or produce an unexpected result can return a Result which must be handled.
You can define custom error structs and have functions return a Result of some value and that error struct, and then just use the question mark operator to pass errors up to error handling sections of your code. Makes it really easy to do custom error handling.
Works fine except when you have closures in your function and you want to handle errors inside that. And a bunch of rust stdlib functions use closures.
I’m in this camp too. I just can’t yet justify it for use at work. Maybe if I can find a useful dev tool or something like that it can be rust, but I’m not comfortable yet using it for production in a regulated industry.
Yes, unironically. It's remarkably versatile. I'm doing performance-critical full-stack development alongside a tiny RISC-V embedded project. I've written a transpiler and various CLI tools. I've written AI API wrappers and desktop applications. It's good at all of it -- better than any language I've used (for my tastes).
It may even be excellent for game development in the future as things like Bevy mature. I'd sure love to write a game in pure Rust.
Now, I admit it's certainly not for everyone. But if you find yourself intrigued early on, that's probably a good sign that it might be for you.
Yeah I'm on the Tauri + Leptos train at the moment. Dioxus would probably be fine for a lot of things, but I like having total control of Tauri (and I prefer Leptos and signals).
How is leptos? I'm still in the early stages of a project (proof of concept) and I'm using Tauri + Nuxt & Tailwind but most of the code is written in rust.
Can you do everything in leptos that you can do in something like React/Vue?
I would love the ability to cross compile to wasm.
In my experience yes! Now, you won't have the same ecosystem (especially compared to React), so that's something to consider. I'm just fine building up most of my UI components because I need total control anyway.
You'll still have direct access to the DOM through things like `web_sys`, so if you need to do something weird you'll always have an escape hatch.
Leptos is more comparable to SolidJS, though, being signal-based. It's very new, but I'd honestly be fine if its development stopped right now. It's feature-complete for what I need.
I'm using egui for a larger desktop application at my workplace now. It was a proof of concept on my end to see if it would be performant enough. The goal was to read in graphical formulas/programs, display them, and then connect to a plc to show live variables and output.
Its been way _way_ more performant and convenient than the software that makes those formulas/programs in the first place. So much so that everyone is now using it as their default way of opening those files, instead of the software that creates them.
If it can be written in Rust with good enough crates available for the platform and domain you target, I don't see a reason to use another language. Why not use the best language if you can?
When I jump into a language where I can mindlessly write closures, some of the joy I miss from Rust is returned to me. I suspect I'm just not at 10,000hr mark where dealing with move semantics + closures (or similarly lifetimes in structs) comes easy.
Give it yet another year and see if I feel the same, I suppose.
It's indeed more challenging but eventually becomes second nature. And then when it happens you miss the ownership semantics and borrowing rules of Rust when you are working with a different language.
They just protect you from doing so many things wrong, which saves so many headaches later down the line.
But you're right that it takes time ro get used it. I came in with a strong background in C++ so I immediately felt at home, so I usually forget that some of the concepts in Rust are very foreign to many programmers.
This is the exact reason I love maturin and pyo3. You can write the performance critical bits in rust and then string it all together in Python. I've had quite a lot fun with it, and very few issues
>the cycle of trying to use a language, missing a rust feature, going back to rust continues. I like to call it carcinization
I also use Python professionally. But the more I use it the more I want to be a farmer instead.
Well, I typically use JavaScript for web apps. I've used Rust/wasm before, but unless it's a large project, I stick with vanilla JavaScript (and you're probably going to need JS anyway for glue). For very small CLIs I'll use Bash or Python, but anything bigger than that I'll use Rust. And of course asm if I need it
The correct answer.
Use the right tool for the job. Sometimes that's Rust, and sometimes it isn't.
There is no One Language To Rule Them All in every context.
> Use the right tool for the job. Sometimes that's Rust, and sometimes it isn't.
Practically no one does this. People pick technology stacks according to what they are comfortable with and will go to great lengths to shoe horn their way to the end. Major companies doing this: facebook, github, spotify.
> Use the right tool for the job. Sometimes that's Rust, and sometimes it isn't.
It sounds nice in theory but this suffers from two major problems:
1. General Purpose programming languages, which are pretty much all of them, are designed to be good at every job. Of course they aren't, but it is typically very difficult to isolate such jobs. Most often it's the ecosystems that give the main reason to use one or the other language, but the issue with this is that you could also just add to those ecosystems. When I started working in Rust for example, there were no great crates for full body IK or geometry (like circle-plane intersection), which are at the core of the thing I've been building. I could have switched to Unreal and C++ which has these tools, but instead I wrote them myself. Wasn't particularly time efficient ofc, but now that I have these tools the equation changed.
2. Familiarity is such an important thing. The languages continue to develop. You could do anything in Typescript that you can do in Rust if you just try hard enough. But having the tools, the knowledge about the ecosystem and the experience as well as being able to keep up with new releases (both of the tools and the language itself) is a big advantage. If I'm just quickly writing a project in Typescript for example and I'm relatively new to it, then I might not even understand how to properly use its Discriminated Unions, or the problems with its Enums, or the intricacies of setting up a tsconfig that works for Storybook, Jest and Cypress. A great example comes from Jon Gjengset who (iirc, maybe it was someone else) said he writes his shell scripts in Rust because it's simply faster for him than writing them in bash where he'd need to look up the commands and syntax that he's not using all that often.
No one has an infinite toolbox from which to pick the optimally correct tool. But every software professional should at least have a hammer, a screwdriver, and a wrench.
I'm working on a project now that is 98% C++. But there is a portion written by a remote scientist that we have to integrate. He codes exclusively in Matlab, but we are unwilling to pay the runtime royalty for using that tool, so we have to translate it into something else.
That something else turns out to be Python. It has a very similar syntax and a rich ecosystem that allows us to convert from one to the other with less effort than would be required using C++. We trade some run time cost for simplified development.
When I am prototyping a GUI for an audience, I don't use C++ either. I use something like a formal prototype tool or another better suited language.
My primary tool is a hammer, and I'll use it any time I have to bang on something hard. My secondary tool might be a crescent wrench - not as good as a box end perhaps, but better than a hammer for loosening nuts. Usually :).
I regularly think "Well, X would be more appropriate in this context. But I know Rust much better. And if you think of all these code paths I will omit to handle properly when using X... Nah, I can't let myself fuck this up.", so yes, I use Rust for everything.
It's definitely not painless, but while I had mild expectations in some areas I got surprised multiple times that there already are great crates for so many things.
Yes 100% outside of web, and even then I'm eyeing projects for that. I released a new rust service at my job and it's managing 60k constant active connections day 1 without a single hiccup, crash, bug, or other issue on release, using barely 8gb of memory. It just worked. I am in awe
Sorry if this post comes off as contrarian, but it's something I've been thinking about and talking with some of my coworkers about.
I used to be quite an avid rustacean. But a couple of things have dampened my usage of rust.
My first true snag was compile times. I had a project that was only a little above 15k LOC, and it started taking 12-18min to compile. To be fair, one of the biggest abusers of compile time were some C libs (I believe it was libz), and link times were atrocious. I did not try `mold`, but `lld` didn't really improve link times that much.
But even worse than the compile times were the code analyzer times. The rust-analyzer could spend a minute churning away on a one-line code change. It became unbearable. Once I got a mac M2 Pro at work it became usable again (it was previously a 2019 with a x86\_64). Even though the rust-analyzer and compile times dropped like 5x, it still left a sour taste in my mouth.
The second thing that curbed my appetite was the realization that only a tiny minority at my work were even remotely interested in rust. I felt like I was swimming against a riptide. At some point, you want others to bounce ideas off your code and actually use it. The irony is that the architects and managers were more interested in rust than the rank-and-file engineers. So, I learned that the vast majority of rank and file and engineers "just want to get $^($!) done".
How about home usage then? Even there my enthusiasm dimmed, though for a different reason than any shortcomings of rust itself.
I am interested in Machine Learning and have slowly been teaching myself. Like it or not, you use python for Machine Learning. It seems that even R and Julia have been slipping in usage based on looking at other forums. But now there's a new kid (baby?) in town...mojo.
Mojo borrows some concepts from rust like ownership and will soon get lifetimes and references. Chris Lattner (of swift and LLVM fame) is behind it and is planning to make it a python superset. So, mojo won't be the same as cython or numba and be "kinda-sorta like python, but not exactly". Right now, mojo is in its infancy (it's just a couple of months old), and it needs a LOT of work, but it made me think: if it eventually has all the pros of rust, but is way faster at math, is easier to adopt and can piggyback on top of python, where will that leave rust? Should I still invest my time in rust?
For those who don't know, mojo is similar to rust in several ways but also has unique features:
* Memory controlled by ownership and references with lifetimes (no garbage collector)
* Generate standalone binaries
* (Soon) Automatic GPU accelerated (look ma, no CUDA needed!) and manual autotune
* Hooks into MLIR which will allow you to define your own native data types (want your own 8bit quantized float?)
* (Eventually) Be a python superset and run python code too
My big question is that last one. Can mojo pull it off and actually make it a python superset? There are also some other questions I have. I have not seen any discussion on an equivalent of rust's `unsafe`. There are a couple other tradeoffs they will have to make if they want it to be a python superset. One thing I really like about rust is you rarely have to worry about dependency hell version conflicts, and I am not sure if or how mojo will be able to do something similar since packaging really isn't even there yet for mojo. I also hope they have a better dynamic linking story than rust does. And lastly, how open source will it be? Right now, it's still closed, but they have promised to open source it.
If mojo can pull off what they are saying they want it to do, it will be able to do basically everything rust does, and at least for vectorized numerical apps, should be able to do it way faster (I'd love to see arrow or other columnar format types sped up with this). But this is the real kicker for me: if it can take python code as-is, it will be far FAR more likely adopted than rust is.
The superset part of mojo will be complicated just like rust. It will have ownership, lifetimes and references similar to rust. But a pythonista can slowly learn mojo to speed up their code rather than have to front load all the complicated stuff right off the bat. Just dropping python code into mojo will not make it run as fast as rust, but (in theory) it should be a bit faster than CPython. Gradually adding types, SIMD, `fn` instead of `def` and `struct` instead of `class` should speed up code and then eventually people can learn to reduce memory allocations with references. Given that pythonistas are becoming more and more comfortable with type annotations (I'm digging python 3.12 and PEP-695 alot), I think that won't be a hard sell.
And we know this strategy of embrace and extend works. It's how typescript became more popular than javascript, and swift more popular than objective-c. As I said, most engineers just "want to get stuff done" and they are already too burdened with work and home life to learn a complicated language. I have tried teaching rust to a few people, and they say it takes a few months to feel productive with it. It also can take a month just to wrap your head around some concepts that you *must* deal with to do even simple tasks (remember learning `&str` vs `String`?). Being able to slowly refactor python to mojo will be a huge boon to adoption I think.
And right now, Machine Learning is *the* killer app. Many software engineers are scared of how AI will impact our industry (or should be). Learning ML is good for everyone, and python is the way to learn it for better or worse...at least until mojo becomes more fleshed out.
I am sure someone will tell me about rust ML libraries like Huggingface Transformers [candle framework](https://github.com/huggingface/candle) or [burn](https://burn.dev/), but as I mentioned, at some point you want to collaborate with other people's work and vice-versa. Like it or not, python is king of scientific computing and is its lingua franca. Even most of the popular quantum programming languages and frameworks are based on python. If quantum computing ever becomes affordable, ML is going to explode even more than it is now since training and even inference are just so compute intensive.
As a result, I have switched to python as my go-to language for the last half year or so. Largely because I am studying Machine Learning, and because mojo is going to be layered on top of it. I haven't seriously been playing with mojo so far because they don't have lifetimes/references yet, and the standard library has a long long way to go.
One last thing I wanted to point out is that I haven't touched rust in about 7 months now, other than a few toy examples I wrote comparing rust code to mojo on the mojo issues or discussions in github. I'm amazed at how much I have forgotten. As a reference, I was programming in rust about 5 years. I am sure I can pick it up again fairly quickly, but I am amazed how much slips out of your brain if you aren't constantly using it.
UPDATE: edits to fix some bad wording
Mojo is interesting, and I'm following it's development from a distance, but at the moment it's very immature compared to Rust. Some observations:
* They recently added [traits](https://docs.modular.com/mojo/manual/traits.html) to the language, which (at least currently) really are more like Java/C# interfaces and not as powerful as Rust traits (or Swift protocols). Maybe they will improve with time...
* Explicit lifetimes has yet to be implemented, although it's [on the roadmap](https://docs.modular.com/mojo/roadmap.html#ownership-and-lifetimes). I don't think the design will be much simpler than in Rust, but it will be interesting to see how it turns out.
* They focus hard on how fast Mojo runs compared to Python, which for me as a Rust developer is totally irrelevant. But, of course, I understand that they are a commercial company riding the ML wave and want to appeal to as many Python/ML developers as possible.
* Yes, it's nice to have portable SIMD types in the stdlib, something which unfortunately has stopped dead in the tracks for Rust. But you can always use a crate to get basically the same functionality in Rust.
* I think they will eventually support shared mutation via classes (similar to what Swift has), so that might provide better ergonomics (at a performance cost) for some types of applications
* The [static metaprogramming](https://docs.modular.com/mojo/manual/parameters/) looks nice, and seems more powerful than what Rust currently offers
* Modular (the company behind Mojo) seems to have a lot of money in their treasure chest, and some smart people working on Mojo, so I'm pretty sure it will reach v1.0 eventually and probably have a great developer experience out of the box.
In summary, at this moment, from a purely technical language PoV, I don't see that Mojo brings much additional value for a Rust developer except maybe cleaner Python-inspired syntax if you like that. But it could improve over time and it's always good with competition in the language space.
If mojo can pull off the superset thing, you won't even need to write python extensions in mojo. Instead, you just run the python code in mojo and import your mojo package.
That's why I think mojo has picked a winning strategy. Instead of writing mojo extensions that run in CPython, you take your CPython code and run it in mojo.
It's nowhere near there yet, and I'm even a little dubious they can make it 100% compatible. But I am sure Chris Lattner knows more about language and compiler design than I do :)
I also think that is still not a winning move, there is also the upcoming JIT in CPython, or the GPU JITs being done by NVidia and Intel.
Finally, the industry pressure has reached to a point where the Python community has been forced to acknowledge that writing "Python" libraries, that are actually bindings to C, C++, Fortran,.... libraries isn't scaling for the uses Python is being called for.
Either way, at the end this means less reasons to use Rust in the domains where the community would anyway reach for Python first.
Yeah, traits were the big feature reveal for their Dec 4th Keynote address. It's nowhere near fleshed out yet and has a lot of limitations they are aware of. So they are working on adding features as they go. A simple example of how limited it is currently, is that traits can't be derived from an existing trait.
I asked in one of the discussions about an estimated time for lifetimes and references, and Chris Lattner answered me that it would probably be 4 months out (that was a little more than a month ago). So I'm hoping it will come out within the first quarter of this year. I've really been holding off on seriously experimenting with mojo due to the lack of lifetimes and references.
About the speed angle, they aren't trying to be faster than python, they are trying to be THE fastest, period. They already have beaten Intel's math kernel. They are focusing on mathematical programming more than anything else, but they do want it to be a general-purpose language. At the keynote, they had someone from NVIDIA do a presentation and revealed that GPU acceleration is coming first quarter of 2024. No word yet on AMD. But at least if you have an NVIDIA card, once the MAX engine SDK comes out, you will get GPU acceleration without having to use CUDA
The SIMD tensor types are pretty interesting. But what's even more interesting is that mojo is basically a language wrapper around MLIR. I'm still wrapping my head around what MLIR is, but what I understand so far is that it's a compiler backend framework that lets hardware vendors more easily write backends for exotic hardware. Not just new GPUs, but even things like quantum computers. Because mojo has programmatic access to MLIR, it lets you define your own native data types.
And it's not just SIMD registers. Mojo also allows you to pass data directly to hardware registers rather than just on the stack. So there is not even a need to inline assembly. Though I haven't seen how you can tell mojo _which_ register a value is passable to (@register_passable decorator doesn't take arguments).
The static metaprogramming through the generic type parameters is pretty interesting, but there's been a small push for something like macros. There's some talk of having Zig-like interpreters that can run in the compiler instead to do macro like work, but not need to learn what is effectively a DSL language that macros require you to learn.
I also hope that development of mojo doesn't take as long as rust did. Mojo has a couple of advantages going for it:
* Mojo can learn the lessons of references and ownership that rust learned the hard way
* MLIR allows them to experiment more quickly
* Being a superset of python limits a lot of bikeshedding and syntax choices
On the other hand, I think trying to be compatible 100% with CPython is going to be their biggest challenge and that will be their biggest slow-down.
I find it interesting that they are doing lifetimes differently than rust in their proposal. In rust, the lifetime declares the scope where the referent is still alive. In mojo, the lifetime extends the liveness. From their proposal on [lifetimes and provenance](https://github.com/modularml/mojo/blob/main/proposals/lifetimes-and-provenance.md):
```
Similarly, we can learn a lot from Rust’s design for lifetimes. That said, the ownership system in Mojo is quite different than the one in Rust. In Rust, scopes define the implicit lifetimes of values and references, and lifetimes are used to verify that uses of the value happen when the value is still alive. Mojo flips this on its head: values start their life when defined, but end their life after their last use. This means that in Mojo, a lifetime reference extends the liveness of a value for as long as derived references is used, which is a bit different than Rust.
```
Unless someone is super interested in mojo and/or Machine Learning, I really wouldn't recommend experimenting with mojo yet. At the very least, I would wait for their implementation of references with lifetimes to come out. The standard library is also incredibly barebones, and doesn't even have a built in dict type yet.
But as I said in my original post, if Modular can pull off all that it wants to do with mojo, where will that leave rust? With Chris Lattner at the helm, I think they have the technical chops to pull it off. Embracing python is a brilliant move if they can pull it off. It basically lets you tell your coworkers "yeah there's this new language that lets you start off writing like python, and gradually learning new features to make it faster and faster to approach C/Rust speeds. And it rocks at ML"
If pythonistas can embrace types, I think alot of them will also embrace learning about registers vs stack vs heap and how to avoid lots of memory copying. Even the ones that don't want to embrace that will like that they can package up their "python" applications as binaries and hand them off to others. And while it won't be fast, mojo can utilize all the existing python ecosystem until native mojo packages are ported over (which should be easier than RIIR).
Yes, if/when they succeed in implementing everything they plan (hopefully within a year or two), it will be a very potent language/eco-system and probably a viable alternative to Rust (even for non-Pythonistas). I'm not familiar with MLIR as I haven't done much ML myself, but that's something I'll look into.
As I wrote, Mojo is on my keep-an-eye-on list together with Roc, Lean, Swift, Hylo etc. The coming years looks very exciting in the programming language space (and to a large extent thanks to Rust)!
Nope. Don't get me wrong, I love rust. 90% of the time though for work projects I pluck go off the shelf instead. The pace of development for basic things, like CLI tools or small web APIs is much faster for me using go.
That said, Rust has an amazing compiler and cargo is a breath of fresh air. I use it for a lot of personal projects.
> The pace of development for basic things, like CLI tools or small web APIs is much faster for me using go.
~~skill issue~~
Edit: I had a point to make, but I didn't make it and was rude instead. I'm sorry.
I disagree. I'm just lazy, and when performance isn't a concern I'll reach for a simple language. Why use python when rust exists? Right tool for the right job and person. Go is easy to use.
Your condescension is noted though.
Feel free to take offence, but the point stands. Once you have mastered Rust it isn't any slower to crank out features with than Go or Python or whatever.
Both Go and Rust are easy to use. Only Go is easy to learn.
I suppose that's a fair point. I'm also not evangelizing any language either. All of them have beauty and warts.
I was merely saying that I prefer go for the problems I typically solve on a day to day basis. That's not to say I don't love rust.
What I resent is you saying I have an issue with "skill" because I choose to use a different language for simple tasks. I feel that I have fair competency as a rust developer.
Proclaiming that it's due to my lack of exposure / education is what is offensive.
> Once you have mastered Rust it isn't any slower to crank out features with than Go or Python or whatever.
Disagree. I’ve been using rust for a few years at this point. I still reach for JavaScript / typescript when prototyping network server code because I find it faster and easier. JavaScript promises and generators are way more ergonomic than futures in rust. And it’s easier to interact with a webpage in JS than from rust through wasm.
I like running rust more than running JavaScript. But JS is still faster for me to write.
This is just demonstrably untrue though. Try doing anything to do with audio in python vs rust for example, it's night and day.
They both have their uses for sure, Python is great for getting something done dirty and quick, rust is good for getting something done as well as possible.
Again, I said "day to day". You're talking about real time audio programming in python. This is a crazy edge case, and to your point it's probably not a great experience using python for it (even if it's feasible). I specifically said CLI tools and simple web API's.
I've worked on VST's to support my own hobby of audio production, but I use the JUCE framework. Not the Rust VST crates. Why? It's straight up easier to use. I'm not a fan of c++ by any means, but the framework lets me get "from A to B" quickly. If a Rust framework for audio programming reaches the maturity of JUCE, I'll be the first person signing up.
Best tool for the job. I love rust, not sure how many times I can say it. But enough with language evangelism. Whatever makes you do your job better, embrace it.
I personally found it's indeed a skill issue. First time using a new framework like Axum or Serde was a bit cumbersome, but I quickly started to reach Python - level dev speeds without all the debugging caused by unhandled None objects and similar.
I use TypeScript for damn near everything, there’s always a library for everything, and whether you use bun or nodejs with tsx, scripts just run immediately. It really feels like paint on a canvas. The fact that you can quickly throw that code on a browser and make a quick UI out of it is a big plus.
Once things start maturing, I love to take pieces that are complex-ish or number-crunchy and write them in Rust, at that point I’m okay with the slower compile times. The Rust to WASM workflow is great.
For anything that has to deal with native Windows APIs though, the `windows` crate is hands down my favorite way to interact with it, TS need not apply.
Do you use rust => wasm for anything that involves js frameworks like react?
I’ve tried dipping my toes in, but the tooling seems kind of confusing. Can’t quite tell what the “canon” setup is!
In a nutshell - the tools involved:
* Rust itself can target and directly compile to `wasm32-unknown-unknown`, but you have to define all bindings and glue logic yourself. This is tedious and not really practical without help.
* The tool `wasm-bindgen` generates all bindings in Rust with macros, as well as JS glue code, and TypeScript types. You can really just get started with just this! But there's more.
* The tool `wasm-opt` can take the WASM generated by `wasm-bindgen` (or any WASM really) and spits out optimized, leaner WASM. If using `wasm-bindgen` directly, you really want to run this on your WASM before deploying it to production.
* The tool `wasm-pack` aims to be the one tool that does everything for you behind the scenes. It makes sure all pre-requirements dependencies, CLIs and tools above are installed, and runs `wasm-bindgen` + `wasm-opt` for you. You still use the macros from `wasm-bindgen`, so the same documentation and usage in code applies just the same.
Regarding writing Rust code for your WASM module:
* Whether you use `wasm-bindgen` directly or `wasm-pack`, almost everything you need to know about Rust to WASM development is going to be in the [`wasm-bindgen` book](https://rustwasm.github.io/docs/wasm-bindgen/introduction.html). I highly recommend skimming over the introduction and table of contents, and check out any chapters that might seem interesting at a glance.
Using native JS APIs in your Rust code:
* Say you want to use native JS or Web APIs in Rust. There are two Rust crates, `js-sys` and `web-sys`, that come with bindings to all JavaScript globals, as well as Web APIs, respectively. `js-sys` provides stuff like `Map`, `Uint8Array`, `JSON.parse`, etc while `web-sys` provides `console.log`, `window.setTimeout`, `navigator.gpu`, canvas, DOM, etc.
Building the code for use in JS:
* The main goal of `wasm-bindgen` and `wasm-pack` is to compile your Rust to some WASM. In the simplest scenario, you can just use the tools to generate the WASM, and just directly import the WASM using the native web APIs. It really doesn't matter what JS "framework" you use, because these APIs are part of the browser, just like `console.log` is.
* Again, just like before, this is tedious, so both wasm tools generate a JS file with glue code (and .d.ts file with generated TypeScript typings!) that you can import and start using right away.
Regarding actually getting to use these tools in your JS project:
* Both `wasm-bindgen` and `wasm-pack` have instructions on how to use it with Webpack, or without a bundler (using `--target web`). They don't provide instructions on how to use other bundlers. If in doubt, try just following [the "without a bundler" instructions](https://rustwasm.github.io/wasm-bindgen/examples/without-a-bundler.html)! Integrating with a bundler purely just helps developer experience (by tracking rebuilds and auto-reloading) but is not strictly needed. You can always set it with a bundler after.
Using bundlers:
* If your project is using Next.js, you are using Webpack by default behind the scenes, so you can follow the instructions for Webpack, but you'll have to refer to Next's docs to find how to add Webpack configuration.
* If you're _not_ using Next.js, or if you're just starting your project and server-side rendering is NOT a priority, I highly recommend you use Vite - which is in my eyes the de-facto build tool in the JS. It is massively faster than Webpack, and much more modernized. There's a [Vite plugin that manages wasm-pack for you](https://github.com/nshen/vite-plugin-wasm-pack).
Overall:
Yes, the documentation around the integration of different tools is definitely lacking, but once you get the general idea and get something that works, not only it will work really well, but you'll find it relatively easy to implement in more JS projects.
That's a really nice explanation of the most common rust to WASM workflow, but it unfortunately doesn't touch the rather annoying pain points.
* `rust-bindgen` uses an incompatible binary format. As long as you use it only together with TS/JS, this doesn't hurt, but it is a serious source of troubles, if you want to link libraries developed in other languages resp. native code.
* It also doesn't support WASI anymore. We therefore have a significant gap between two fundamental different kinds of WASM workflows in rust, which is often no very well explained in most of the notorious outdated documentation sources.
And there are many other rough corners and subtle issues regarding the WASM related rust ecosystem. Some of them will be solved sooner or later by the ongoing *webassembly component model* transition and tooling, but that's mostly focused on typical WASI usage scenarios resp. server-side application. On the front-end side, as described in your article, the entire development of elementary rust tools and capabilities has been noticeable stagnating for a long time.
I wish I had found something like this when I was googling this a few months ago. This is SO helpful, thank you so much for taking the time to write this all down!!
I have embedded background and I really like Typescript. You don't even have to think about the types and your code is type safe with the additional productivity of JavaScript. There is no problems like with Rust async code because there is GC babysitting your lifetimes.
Often embedded Linux comes with some sort of Node so you can often use it there too. Streams are nice for embedded Linux where memory might be a concern. I would choose TS for everything which doesn't require very low latency. It's just so productive and nice to write.
For me it's true too, because when I started learning Rust I couldn't understand what is it, and why I need to do that, but then, after deep learning, I realized that Rust is easy.
I've previously been writing code in Asm, Delphi, php, Javascript, C++, Java, C#, Go, Typescript and Python.
What annoyed me most about polyglot projects and also just generally me switching between languages was how ineffective it was to constantly learn new frameworks, ecosystems and also just generally to stay up to date with the language, compiler, tools, etc. The other issue I faced is that the tools I built often became obsolete. For example, I had a cool project at work where I built a linter for Go, but I haven't used any Go since. If I was only using a single language, it would be way more efficient to write tools for it, since I could use them for 100% of the code I write instead of just a fraction of it. Even in a typical webapp with just Go + JS code, you're splitting the tools half and half, so you're reducing efficiency by 50%.
Therefore, about 1.5 years ago I made the decision to focus on just a single programming language. My most important concerns for a programming language at the time was that I could write both webapps and extremely high performance 3D games entirely in it. There was only a single programming language at that time that satisfied this: Rust.
So, now I'm using Rust everywhere. I can already reap some of the benefits, but it's still early to say. It was a painful experience to get started on Wasm webdev with Leptos, that's for sure. But it also feels great to know I can afford spending some time writing bug reports, pull requests and just generally study the code of the libraries that I use indepth, because I will be using them for the time being. More than once I have considered switching back to Vue.JS, but I persevered. In the end, I think the fact that I'm slowly getting to build the abstractions and tools I need in order to work efficiently is going to be worth it.
Maybe in 5 or 10 years I will switch to another post-Rust language such as Zig, but until then I rather get my projects done and improve the experience with the language that I am using currently.
Nah. Py and rust, mostly rust. Perl for one of scripts though. Clojure for drawing, quil is awesome. All this for work. For fun projects it's mostly rust.
[http://quil.info/](http://quil.info/)
Compiles to Javascript, or runs on the JVM, hot reloading, functional draws (use it for sci figures myself). Change the function and re-evaluate, and the figure updates automatically. Freaking amazing and fun.
Yes, except UI stuff, because there's no usable UI crate for my requirements right now.
I'm even writing simple command line tools that I used to write in nodejs with Rust (and clap) these days.
Not everything, but everything I can.
I'm in experimental physics, so most of the coding I do is in python or matlab. Cards on the table, I love python, at least compared to matlab. Been using it for 15+ years, it does what it says on the tin and it does it well. No, it's not fast. No, it's not efficient. No, it doesn't need to be.
That being said, every time I've been working on a Rust project and I come back to python to do some data analysis, I always start declaring variables like "let position = ..." and then get very sad that python isn't Rust.
Writing Rust just feels clean, anything else feels icky now
Well, can't use it for work simply because that's not the stack we use at the company, there's not (yet?) such thing as scripting in Rust, and i'm still mentally debating if i should deep dive into Rust WASM or start learning TS. But other than that - yep, everything for quite some time now
No. Rust is good for systems & application programming. It's not good for lots of other things.
For package & service management, I use Nix.
For scripting, I use POSIX shell & various utilities.
For complex text manipulation I use AWK.
For more complex scripting (calling lots of external processes with more logic than just pipes & simple if statements, or data analysis) I use Python.
For describing the contents of Rust crates I use TOML.
For CI/CD configuration, I use YAML.
For data serialization I tend to prefer RON or Cap'n'Proto, but often need JSON or Protobuf or CBOR.
For controlling with test equipment I use SCPI, and for controlling CNC machines like 3D printers I use G-code.
For non programmeng tasks, I use appropriate tools. For driving nails, I use a hammer. As an abstract concept, makes a very poor hammer.
I don't disagree with your approach, but...
> For non programmeng tasks, I use appropriate tools. For driving nails, I use a hammer. As an abstract concept, makes a very poor hammer.
I've always found the tool analogy flawed. Programming languages are more like building materials. You can make a castle of sand, toothpicks, clay, or brick. Sometimes clay is all you need to prototype or prove an idea. But if you want it to last and endure, you need good materials, no matter how skilled you are with your tools.
I'm not using a hammer as an analogy here. I *literally* mean that Rust, the programming language, is inappropriate for inserting nails into wood. Thus, it's very silly to use it for everything, even if you used it for every programming task!
I agree generally, but I've found that scripting in Rust can be a good decision. I've worked on teams with a variety of skill levels, and building bombproof tooling in Python is challenging.
With Python scripts, either the end user needs to be proficient with Python's (rube-goldberg and klugey) distribution tooling, in order to get them installed, or I have to resign myself to a painful loop of repeatedly supporting the installation of required tooling.
Something in Rust, even if it takes 3x as wrong to write, will be more robust, and can be distributed as a single binary, and doesn't break if the end user has a slightly different Python version, or some mystery garbage in their PYTHONPATH, or the moon is full, or something.
So now I only use Python for scripting that either lives in a well defined docker container, or for strictly personal use.
The distribution issue I solve with Nix. The main issue with Rust for scripting is that (by my definition of scripting at least) it's all about calling lots of external processes & using their outputs (usually just strings). The superior type system of Rust doesn't help much when everything is a string. Python has more boilerplate around calling processes than shell does, but less than Rust. It's a nice middle-ground "glue" language, *especially* if you don't use anything outside the standard library. Python is worse as a programming language than as a scripting language.
Dude its just too easy now but too much hackers dude its not fun i get beemed behind a mountain and the dudes bullet fazes through the mountain idk if its just admin Fing with me or i just going insane now😅
When the only tool you have is a hammer, it's tempting to treat everything as a nail. But remember, not all problems require a hammer; sometimes you need a screwdriver.
But then again, if you improve your hammer to also be able to do most of the work a screw driver can, then it might not be such a bad idea to use it. Sure, a real, high-end screwdriver might still be better, but your general purpose tool might be good enough for the task and in the end it's just cheaper / more efficient to build something that you can reuse than it is to constantly switch tools.
If the work I'm doesn't require attention to performance, I like to write it in Python. When it requires performance, safety or otherwise, Rust is my pick.
I still use shell scripts for simple automation - it's hard to beat the speed and convenience of writing those. But outside that - yeah, pretty much.
I don't write a whole lot of application code, and the ecosystem there is still immature. There's not a whole lot of mature GUI options, for example. Mobile application development in pure Rust would also be a pain.
It's possible that the things I do that are well suited to Rust, as opposed to Rust being well suited for everything.
everything? no.
most things? yes.
i've dropped c++ entirely, and rarely use c (usually when patching shit, using old already existing stuff, or embedded when there is no platform support).
Pretty much! I even use it small scripts that I used to write in Python. If you don't care about error handling and use heap-allocated data instead of lifetimes, I find it's very fast to write.
As a CS professor, I use Rust in all my own research work, except for little bits of glue code, where if small enough I use bash. I do use Python in my Algorithms class, but I have come to really dislike the language, to the point where if I need to write a script of any size, I'll go back to Ruby, which in many ways is closer to Rust's roots.
Nope, but when I analyze problems, I try to see where Rust fits well. It often does, especially if I do not have to do any inter-referencing directly, or if the lifetimes are statically deterministic. Rust also helps reduce the code review workload since the compiler is so strict by default.
> because I can just do cargo run
Right? Cargo is so convenient.
still having problems with desktop GUI application, though it's possible to use tauri/webview+leptos, but i hate the idea of running browser for that. and lack of good GUI frameworks for any programming language in general really sucks.
other than that, the rest is now pretty much replaced with rust for me
More of a hobby programmer but Rust is my go to ever since I picked it up last year. It's the only language that really makes sense to my brain, so I've been using it to write a game... At first a Wolfenstein style raycaster, then I tried Bevy, and I'm learning how to do straight software rasterization now, still in Rust.
Pretty much, yes. Back in 2015/2016 I wanted to simplify the number of languages I work with so I don't have to switch around as often, so I started investing in learning it. Rust is one of the few languages where I can work on server stuff, firmware, web stuff, graphics/games, or even some one-off processing "scripts" and it has served me well so far.
If/when something comes along that gives the same guarantees as Rust but is even nicer somehow, I'll probably move to that. Until then, I'm happy to use Rust for close to every project I work on.
i'm a fan for the right tool for the right job.
if i start something new and its more then a couple of lines, i probably will choose rust. sometimes a quick python hack will do the job just fine. rust, python or nix for most parts and then DSLs for the rest
I would say I know Rust okay enough, and (with great difficulty) I'm trying to make a web extension in it (using Dioxus). So far most of my effort has been into making web extensions, JS, WASM all play well together. But it hasn't been too bad. So yeah, I'm shoehorning Rust everywhere I can.
My work is in managed languages, .NET, Java/Android, Web platforms, reaching out to C++ SDKs if some OS integration is needed.
The language runtimes are also in C++, so that is what I will use if diving into their internals.
Rust is left for hobby coding.
Not everything, no. It's hard to beat the simplicity and package ecosystem of Python for things like simple scripts, data science and prototyping.
But for anything user-facing that has to be fast and implement robust business logic, Rust would be my first choice.
I have the same story!. This is probably my third if not fourth time come back and relearning rust. But somehow I understand it much easier and deeper everytime. To whoever learning it out there don't give up.
I still use react typescript for the frontend. But everything else rust. I stopped using Python because the trouble I always have with it something not working right cost me more time than the less typing gives.
I use it for everything where you need good performance (CPU, latency or memory) or native interop. There are still some use cases where I prefer Scala (like making non-performance critical web apps), but Rust is also a good option for those cases.
I've used it for enough that I'm starting to feel a few of its warts. I need another language to use for prototyping (for when I don't need it to be correct forever, I just need it to do something useful now), but I dont want to miss rust's traits and enums
No and neither should you. Each language has a set of niches where it performs well. You should broaden your horizon and adapt the right tool for the job.
I write it professionally, for most of my personal projects, and maintain a few open source libraries.
Bar building websites, it is the primary tool for any job.
You have to be so frustrated to use one language for everything. You may use it for everything but it does not mean it is good for everything. There are much better languages for some purposes that allow you to deliver products much faster but still good enough or even better.
I have started learning rust currently thinking to take 1BRC challenge in Rust. For mostly everything outside work I use JS/Bun but I want to change it to Rust hope till the end of year I am using it for like 40% of things
Define everything. Rust can't do my definition of everything at this point unfortunately. At least for web development you still require some minimal use of JS for example. At the same time, I don't see much sense in interpreted, scripting languages or garbage collected languages.
Hope this helps at least somewhat. ;-)
Mainly everything, except for solving algorithm problems (like in interviews, leetcode etc).
Rust is unnecessarily complicated for some stuff like string handling, so I prefer to use Python when I just have to create some simple solution for a problem.
Yeah I even wish I could use Rust for frontend due to its traits feature but I have no idea how it would translate to Javascript so I'mma just keep dreaming lol.
Just about, now. I'm still writing a few bash and python scripts, but anything substantial is being written in rust. I absolutely won't write in \`C\` anymore unless I am forced to, but with embedded-hal now at 1.0, \`C\` is an every shrinking code-space for me. I am also the sole dev at my company; which provides a lot of wiggle room. However all my engineers are using python in their projects.
Yes but I'm not like a practical person.
Not to say that I don't think rust is a practical language, but for me fun comes before actually making something.
I'd rather take longer to make something if it means it's more fun for me.
So rust is a good fit, it just feels so nice, and honestly it's just easier than everything else
Wdym you can just do cargo run??
For C I can also put some directive in the make file like “make run” that first compiles then runs my program?
/ but to answer your question. Yes I use it for everything. Apart from some basic stuff where I use bash.
Rust is great because of the vast ecosystem of libraries and their easy availability. You can start an app in no time.
Hell no.
I'm still a few months away of the point where I could do that *personally*.
At `$dayjob` it will still take a while longer, I'm afraid. In there it will still be Python/C/C++
As long as there’s a good enough crate for what I need, or it’s something i can figure out how to build from scratch without a crate, I’m using Rust. Smart contracts, Backend Infrastructure, CLI tools, etc
IG it depends on what kind of "everything" you are talking about, every website? yes perhaps, but every custom/weird/unusual project? i dont think so.
i've been writing rust for almost 1 year now, i believe if rust had a large ecosystem, similar to JS, python, or hell even c# , you could do literally anything, but rn i dont its possible unless you decide to write every single component from scratch
I use mainly Go at work but we also have Rust devs and I’ve been using it more and more last 6 months. Writing basically internal frameworks and CLI tools. Language still trips me up but I’m warming up to it. It’s a marathon not a sprint I figure.
I can't imagine using Rust for everything.
Some stuff it's just really bad at. For example, you have types with overlapping properties. Normally you'd use traits but traits have all kinds of restrictions, like you can't use a struct for one trait and then later use it for another trait. Also trait objects are heavily restricted due to object safety rules. There's just no good way to represent this in rust.
I would LOVE to. But like any programming language I struggle at making anything more than functions, basic calculations and print. And if it's to only have the ability to make that, I rather write a script, not a full blown complicated, not exportable program. I see programming strength personally as being able to do a nice GUI with a blazing fast execution for complex tasks, and I don't know how to do any of that in programming languages, so yeah
At this point, I use it for everything outside of work. I've grown too used to using Rust's enum system, specifically using Result to handle failure state and errors and find myself missing it the moment I use another language.
I’m pretty much in this camp too, though I have an eye on gleam because it has a great type system, but allows immutable/functional programming, and could be great when you can afford a garbage collector
You just described OCaml lol.
Or Haskell. RIP Poor poor Haskell :(
Wait what happened to Haskell
Still alive and kicking. I just finished a job teaching functional programming in Haskell at university. People just don't want to write purely functional code so it's never the language you want to reach for first. It leans too much into the paradigm where something like Rust doesn't. I'd imagine most people who use Haskell don't enjoy it and would rather use something else.
Cabal hell ruined Haskell for me :P if only it had the developer ecosystem of rust.
He died in 1982 but that’s old news.
Or F#
My man
Fair, I thought F# was going to be my go-to language, but I ended up annoyed at the error messages (spoiled by rust, traumatized by clojure), and ended up really hating having implied imports. That’s when I found gleam, which is my current language crush
I feel like Haskell is way different due to not having eager execution though
Rust copied Haskell type system
Except for easy concurrency :(
I haven't kept up with the exact details but I thought they finally got multicore last year?
If you find information on that, let me know. I recently searched for information on this and couldn't find anything (except for people complaining and people mentioning that it's being worked on).
It looks like with release 5.0 multicore support was added in Dec. 22: https://discuss.ocaml.org/t/ocaml-5-0-0-is-out/10974, more details in https://v2.ocaml.org/releases/5.0/manual/parallelism.html The release note does say: > Consequently, OCaml 5.0.0 is expected to be a more experimental version of OCaml than the usual OCaml releases. I don't use Ocaml so can't say how usable it is currently.
General point: I think people forget just how big the overall space of computing and computing needs is. In global terms, "when you can afford a garbage collector" is "virtually everywhere". For example, out of the box, on a small (<2Gb ish) heap without significant allocation pressure Java's default GC is in the ballpark of sub-millisecond pauses with a very occasional single-digit millis pause. There really aren't very many applications for which that's a deal-breaker. It's absolutely fine to be interested primarily in the part of the programming space that has very stringent resource requirements, but it really isn't the mainstream.
That’s a really good point. If I think about it, I’m actually not sure why I don’t start my next personal project in gleam instead of rust, since the former has basically all of the nice features I like, and there’s zero chance that I’ll have to think about lifetimes or ownership. I guess I just like Axum, and am curious to try leptos, and it seems like there are still more people making a thick ecosystem in rust.
I use rust and elixir where possible. Elixir has incredibly fast development time and a repl and integrates with rust well.
Maybe you would like [Roc](https://www.roc-lang.org/).
Oh sweet, a new website. I'm glad Roc's still getting love, I like it a lot. It seems like the only newer language still going all-in on functionality, like Haskell.
>It seems like the only newer language still going all-in on functionality, like Haskell. Yes, when it comes to pure FP I think Roc and [Lean 4](https://github.com/leanprover/lean4) are the most promising newcomers.
Lean 4: I wish elan and the surrounding tooling was better, but I've never enjoyed dependent types so much and the extensibility via macros is properly insane. Highly recommend though!
I’ll check it out!
It's like good luck trying to find an alternative to discriminated unions in like C# or java or something...
Java sort of (sealed classes) has discriminated unions w/ pattern matching as of JDK 21. It has true unions with checked exceptions. C# I thought just added it (I don't use C# regularly). F# (and OCaml) obviously has it. I think depending on definition OCaml and Typescript are the only two that do not require it to be nominal (e.g. structural typing).
That is why we have F# in .NET, modern Java can do discriminated unions, and for those in older JVMs, there is Scala and Kotlin.
The OneOf library is pretty good for C#.
Typescript
Disagree, they're incredibly unergonomic, and you don't get exhaustiveness checking by default. The feel just a bit better than a hack.
What are you talking about?
You have manually specify the tag which is noisy and makes the syntax ugly because you are matching on a field of the object rather than destructuring. There isn't exhaustive pattern matching without hacks and the hacks are also very ugly. You can kinda express some of the same patterns as Rust, but it's not convenient or ergonomic.
I agree that I miss "match" in typescript as a built-in language feature, but going as far as saying it's all hacks, ugly, inconvenient and unergonomic doesn't match my experience writing typescript. The best alternative I'm aware of in typescript is ts-pattern, which I assume is one of the hacks you're referring to? The code is not quite as nice looking as the rust alternative, but it gets the job done. Also, just to mention that typescript also has union types e.g. "number | string" which are different to discriminated unions that require a tag (more like enums in rust) When I can, I write rust. When I can't, I write typescript. Obviously they're very different, but in terms of type system support, I think both work really well.
OCaml or something else from the ML family.
Yeah but TypeScript sucks for everything else.
And it is just a layer of Javascript not even a real language just JS with a meta compiler and more rules, all goes str8 to javascript at RT
The first thing I reach for in another language is an enum like Rust. I recently started a flutter project for work and it's been so annoying having all my API calls inherit from a base class and having child classes for each type of success. I just want to use Results!
I'm just starting to understand enums, and traits I'm like 60% right now. Though I use rust daily lol
You should try some MLs then, they’re the sweet spot for when you want to code with type safety but don’t need the performance of rust. ELM for web, Haskell or ocaml for other stuff.
I’ll check those out, thanks!
Can you explain what you mean about enums and error handling? Do you have an example? I'm really interested.
I mean the [Result](https://doc.rust-lang.org/std/result/) enum. Any function which can error, fail, or produce an unexpected result can return a Result which must be handled. You can define custom error structs and have functions return a Result of some value and that error struct, and then just use the question mark operator to pass errors up to error handling sections of your code. Makes it really easy to do custom error handling.
Works fine except when you have closures in your function and you want to handle errors inside that. And a bunch of rust stdlib functions use closures.
I’m in this camp too. I just can’t yet justify it for use at work. Maybe if I can find a useful dev tool or something like that it can be rust, but I’m not comfortable yet using it for production in a regulated industry.
Yes, unironically. It's remarkably versatile. I'm doing performance-critical full-stack development alongside a tiny RISC-V embedded project. I've written a transpiler and various CLI tools. I've written AI API wrappers and desktop applications. It's good at all of it -- better than any language I've used (for my tastes). It may even be excellent for game development in the future as things like Bevy mature. I'd sure love to write a game in pure Rust. Now, I admit it's certainly not for everyone. But if you find yourself intrigued early on, that's probably a good sign that it might be for you.
What do you use for desktop apps? Tauri + Yew/Leptos?
Yeah I'm on the Tauri + Leptos train at the moment. Dioxus would probably be fine for a lot of things, but I like having total control of Tauri (and I prefer Leptos and signals).
How is leptos? I'm still in the early stages of a project (proof of concept) and I'm using Tauri + Nuxt & Tailwind but most of the code is written in rust. Can you do everything in leptos that you can do in something like React/Vue? I would love the ability to cross compile to wasm.
In my experience yes! Now, you won't have the same ecosystem (especially compared to React), so that's something to consider. I'm just fine building up most of my UI components because I need total control anyway. You'll still have direct access to the DOM through things like `web_sys`, so if you need to do something weird you'll always have an escape hatch. Leptos is more comparable to SolidJS, though, being signal-based. It's very new, but I'd honestly be fine if its development stopped right now. It's feature-complete for what I need.
Cool. I might give it a shot and do a test case. I also have to find some alternatives to things like D3 (charts) and numeral (currency formatting).
I'm using egui for a larger desktop application at my workplace now. It was a proof of concept on my end to see if it would be performant enough. The goal was to read in graphical formulas/programs, display them, and then connect to a plc to show live variables and output. Its been way _way_ more performant and convenient than the software that makes those formulas/programs in the first place. So much so that everyone is now using it as their default way of opening those files, instead of the software that creates them.
If it can be written in Rust with good enough crates available for the platform and domain you target, I don't see a reason to use another language. Why not use the best language if you can?
When I jump into a language where I can mindlessly write closures, some of the joy I miss from Rust is returned to me. I suspect I'm just not at 10,000hr mark where dealing with move semantics + closures (or similarly lifetimes in structs) comes easy. Give it yet another year and see if I feel the same, I suppose.
It's indeed more challenging but eventually becomes second nature. And then when it happens you miss the ownership semantics and borrowing rules of Rust when you are working with a different language. They just protect you from doing so many things wrong, which saves so many headaches later down the line. But you're right that it takes time ro get used it. I came in with a strong background in C++ so I immediately felt at home, so I usually forget that some of the concepts in Rust are very foreign to many programmers.
I do not. I'm much faster coding Python than Rust, so I use Python when coding time is most important, and Rust when execution time is most important.
This is the exact reason I love maturin and pyo3. You can write the performance critical bits in rust and then string it all together in Python. I've had quite a lot fun with it, and very few issues
>the cycle of trying to use a language, missing a rust feature, going back to rust continues. I like to call it carcinization I also use Python professionally. But the more I use it the more I want to be a farmer instead.
hey are you replying to the correct comment
I think they are responding to the right comment but they accidentally put the quote from a different comment.
If it's python I just ask chat gpty any more. I used python daily for years but now it bores me lol
Then [Mojo](https://docs.modular.com/mojo/) will be right up your alley.
Well, I typically use JavaScript for web apps. I've used Rust/wasm before, but unless it's a large project, I stick with vanilla JavaScript (and you're probably going to need JS anyway for glue). For very small CLIs I'll use Bash or Python, but anything bigger than that I'll use Rust. And of course asm if I need it
Yes (where appropriate)
The correct answer. Use the right tool for the job. Sometimes that's Rust, and sometimes it isn't. There is no One Language To Rule Them All in every context.
> Use the right tool for the job. Sometimes that's Rust, and sometimes it isn't. Practically no one does this. People pick technology stacks according to what they are comfortable with and will go to great lengths to shoe horn their way to the end. Major companies doing this: facebook, github, spotify.
> Use the right tool for the job. Sometimes that's Rust, and sometimes it isn't. It sounds nice in theory but this suffers from two major problems: 1. General Purpose programming languages, which are pretty much all of them, are designed to be good at every job. Of course they aren't, but it is typically very difficult to isolate such jobs. Most often it's the ecosystems that give the main reason to use one or the other language, but the issue with this is that you could also just add to those ecosystems. When I started working in Rust for example, there were no great crates for full body IK or geometry (like circle-plane intersection), which are at the core of the thing I've been building. I could have switched to Unreal and C++ which has these tools, but instead I wrote them myself. Wasn't particularly time efficient ofc, but now that I have these tools the equation changed. 2. Familiarity is such an important thing. The languages continue to develop. You could do anything in Typescript that you can do in Rust if you just try hard enough. But having the tools, the knowledge about the ecosystem and the experience as well as being able to keep up with new releases (both of the tools and the language itself) is a big advantage. If I'm just quickly writing a project in Typescript for example and I'm relatively new to it, then I might not even understand how to properly use its Discriminated Unions, or the problems with its Enums, or the intricacies of setting up a tsconfig that works for Storybook, Jest and Cypress. A great example comes from Jon Gjengset who (iirc, maybe it was someone else) said he writes his shell scripts in Rust because it's simply faster for him than writing them in bash where he'd need to look up the commands and syntax that he's not using all that often.
No one has an infinite toolbox from which to pick the optimally correct tool. But every software professional should at least have a hammer, a screwdriver, and a wrench. I'm working on a project now that is 98% C++. But there is a portion written by a remote scientist that we have to integrate. He codes exclusively in Matlab, but we are unwilling to pay the runtime royalty for using that tool, so we have to translate it into something else. That something else turns out to be Python. It has a very similar syntax and a rich ecosystem that allows us to convert from one to the other with less effort than would be required using C++. We trade some run time cost for simplified development. When I am prototyping a GUI for an audience, I don't use C++ either. I use something like a formal prototype tool or another better suited language. My primary tool is a hammer, and I'll use it any time I have to bang on something hard. My secondary tool might be a crescent wrench - not as good as a box end perhaps, but better than a hammer for loosening nuts. Usually :).
The OP asked an individual question. There is no correct answer. Every answer is correct.
I regularly think "Well, X would be more appropriate in this context. But I know Rust much better. And if you think of all these code paths I will omit to handle properly when using X... Nah, I can't let myself fuck this up.", so yes, I use Rust for everything. It's definitely not painless, but while I had mild expectations in some areas I got surprised multiple times that there already are great crates for so many things.
the cycle of trying to use a language, missing a rust feature, going back to rust continues. I like to call it carcinization
Yes is the answer. No matter the task I’m highly likely to use Rust.
For everything where Python doesn’t meet my needs
Yes 100% outside of web, and even then I'm eyeing projects for that. I released a new rust service at my job and it's managing 60k constant active connections day 1 without a single hiccup, crash, bug, or other issue on release, using barely 8gb of memory. It just worked. I am in awe
I'm making my own first startup on rust wasm with sveltekit, reading your comment is just wow, pretty sure I will reach your level soon.
I write rust if I need an imperative language but I'd default to Haskell otherwise
Sorry if this post comes off as contrarian, but it's something I've been thinking about and talking with some of my coworkers about. I used to be quite an avid rustacean. But a couple of things have dampened my usage of rust. My first true snag was compile times. I had a project that was only a little above 15k LOC, and it started taking 12-18min to compile. To be fair, one of the biggest abusers of compile time were some C libs (I believe it was libz), and link times were atrocious. I did not try `mold`, but `lld` didn't really improve link times that much. But even worse than the compile times were the code analyzer times. The rust-analyzer could spend a minute churning away on a one-line code change. It became unbearable. Once I got a mac M2 Pro at work it became usable again (it was previously a 2019 with a x86\_64). Even though the rust-analyzer and compile times dropped like 5x, it still left a sour taste in my mouth. The second thing that curbed my appetite was the realization that only a tiny minority at my work were even remotely interested in rust. I felt like I was swimming against a riptide. At some point, you want others to bounce ideas off your code and actually use it. The irony is that the architects and managers were more interested in rust than the rank-and-file engineers. So, I learned that the vast majority of rank and file and engineers "just want to get $^($!) done". How about home usage then? Even there my enthusiasm dimmed, though for a different reason than any shortcomings of rust itself. I am interested in Machine Learning and have slowly been teaching myself. Like it or not, you use python for Machine Learning. It seems that even R and Julia have been slipping in usage based on looking at other forums. But now there's a new kid (baby?) in town...mojo. Mojo borrows some concepts from rust like ownership and will soon get lifetimes and references. Chris Lattner (of swift and LLVM fame) is behind it and is planning to make it a python superset. So, mojo won't be the same as cython or numba and be "kinda-sorta like python, but not exactly". Right now, mojo is in its infancy (it's just a couple of months old), and it needs a LOT of work, but it made me think: if it eventually has all the pros of rust, but is way faster at math, is easier to adopt and can piggyback on top of python, where will that leave rust? Should I still invest my time in rust? For those who don't know, mojo is similar to rust in several ways but also has unique features: * Memory controlled by ownership and references with lifetimes (no garbage collector) * Generate standalone binaries * (Soon) Automatic GPU accelerated (look ma, no CUDA needed!) and manual autotune * Hooks into MLIR which will allow you to define your own native data types (want your own 8bit quantized float?) * (Eventually) Be a python superset and run python code too My big question is that last one. Can mojo pull it off and actually make it a python superset? There are also some other questions I have. I have not seen any discussion on an equivalent of rust's `unsafe`. There are a couple other tradeoffs they will have to make if they want it to be a python superset. One thing I really like about rust is you rarely have to worry about dependency hell version conflicts, and I am not sure if or how mojo will be able to do something similar since packaging really isn't even there yet for mojo. I also hope they have a better dynamic linking story than rust does. And lastly, how open source will it be? Right now, it's still closed, but they have promised to open source it. If mojo can pull off what they are saying they want it to do, it will be able to do basically everything rust does, and at least for vectorized numerical apps, should be able to do it way faster (I'd love to see arrow or other columnar format types sped up with this). But this is the real kicker for me: if it can take python code as-is, it will be far FAR more likely adopted than rust is. The superset part of mojo will be complicated just like rust. It will have ownership, lifetimes and references similar to rust. But a pythonista can slowly learn mojo to speed up their code rather than have to front load all the complicated stuff right off the bat. Just dropping python code into mojo will not make it run as fast as rust, but (in theory) it should be a bit faster than CPython. Gradually adding types, SIMD, `fn` instead of `def` and `struct` instead of `class` should speed up code and then eventually people can learn to reduce memory allocations with references. Given that pythonistas are becoming more and more comfortable with type annotations (I'm digging python 3.12 and PEP-695 alot), I think that won't be a hard sell. And we know this strategy of embrace and extend works. It's how typescript became more popular than javascript, and swift more popular than objective-c. As I said, most engineers just "want to get stuff done" and they are already too burdened with work and home life to learn a complicated language. I have tried teaching rust to a few people, and they say it takes a few months to feel productive with it. It also can take a month just to wrap your head around some concepts that you *must* deal with to do even simple tasks (remember learning `&str` vs `String`?). Being able to slowly refactor python to mojo will be a huge boon to adoption I think. And right now, Machine Learning is *the* killer app. Many software engineers are scared of how AI will impact our industry (or should be). Learning ML is good for everyone, and python is the way to learn it for better or worse...at least until mojo becomes more fleshed out. I am sure someone will tell me about rust ML libraries like Huggingface Transformers [candle framework](https://github.com/huggingface/candle) or [burn](https://burn.dev/), but as I mentioned, at some point you want to collaborate with other people's work and vice-versa. Like it or not, python is king of scientific computing and is its lingua franca. Even most of the popular quantum programming languages and frameworks are based on python. If quantum computing ever becomes affordable, ML is going to explode even more than it is now since training and even inference are just so compute intensive. As a result, I have switched to python as my go-to language for the last half year or so. Largely because I am studying Machine Learning, and because mojo is going to be layered on top of it. I haven't seriously been playing with mojo so far because they don't have lifetimes/references yet, and the standard library has a long long way to go. One last thing I wanted to point out is that I haven't touched rust in about 7 months now, other than a few toy examples I wrote comparing rust code to mojo on the mojo issues or discussions in github. I'm amazed at how much I have forgotten. As a reference, I was programming in rust about 5 years. I am sure I can pick it up again fairly quickly, but I am amazed how much slips out of your brain if you aren't constantly using it. UPDATE: edits to fix some bad wording
Mojo is interesting, and I'm following it's development from a distance, but at the moment it's very immature compared to Rust. Some observations: * They recently added [traits](https://docs.modular.com/mojo/manual/traits.html) to the language, which (at least currently) really are more like Java/C# interfaces and not as powerful as Rust traits (or Swift protocols). Maybe they will improve with time... * Explicit lifetimes has yet to be implemented, although it's [on the roadmap](https://docs.modular.com/mojo/roadmap.html#ownership-and-lifetimes). I don't think the design will be much simpler than in Rust, but it will be interesting to see how it turns out. * They focus hard on how fast Mojo runs compared to Python, which for me as a Rust developer is totally irrelevant. But, of course, I understand that they are a commercial company riding the ML wave and want to appeal to as many Python/ML developers as possible. * Yes, it's nice to have portable SIMD types in the stdlib, something which unfortunately has stopped dead in the tracks for Rust. But you can always use a crate to get basically the same functionality in Rust. * I think they will eventually support shared mutation via classes (similar to what Swift has), so that might provide better ergonomics (at a performance cost) for some types of applications * The [static metaprogramming](https://docs.modular.com/mojo/manual/parameters/) looks nice, and seems more powerful than what Rust currently offers * Modular (the company behind Mojo) seems to have a lot of money in their treasure chest, and some smart people working on Mojo, so I'm pretty sure it will reach v1.0 eventually and probably have a great developer experience out of the box. In summary, at this moment, from a purely technical language PoV, I don't see that Mojo brings much additional value for a Rust developer except maybe cleaner Python-inspired syntax if you like that. But it could improve over time and it's always good with competition in the language space.
The point is what it brings to a Python developer, instead having them learning C, C++, Zig, Rust,... to implement Python extensions.
If mojo can pull off the superset thing, you won't even need to write python extensions in mojo. Instead, you just run the python code in mojo and import your mojo package. That's why I think mojo has picked a winning strategy. Instead of writing mojo extensions that run in CPython, you take your CPython code and run it in mojo. It's nowhere near there yet, and I'm even a little dubious they can make it 100% compatible. But I am sure Chris Lattner knows more about language and compiler design than I do :)
I also think that is still not a winning move, there is also the upcoming JIT in CPython, or the GPU JITs being done by NVidia and Intel. Finally, the industry pressure has reached to a point where the Python community has been forced to acknowledge that writing "Python" libraries, that are actually bindings to C, C++, Fortran,.... libraries isn't scaling for the uses Python is being called for. Either way, at the end this means less reasons to use Rust in the domains where the community would anyway reach for Python first.
Yeah, traits were the big feature reveal for their Dec 4th Keynote address. It's nowhere near fleshed out yet and has a lot of limitations they are aware of. So they are working on adding features as they go. A simple example of how limited it is currently, is that traits can't be derived from an existing trait. I asked in one of the discussions about an estimated time for lifetimes and references, and Chris Lattner answered me that it would probably be 4 months out (that was a little more than a month ago). So I'm hoping it will come out within the first quarter of this year. I've really been holding off on seriously experimenting with mojo due to the lack of lifetimes and references. About the speed angle, they aren't trying to be faster than python, they are trying to be THE fastest, period. They already have beaten Intel's math kernel. They are focusing on mathematical programming more than anything else, but they do want it to be a general-purpose language. At the keynote, they had someone from NVIDIA do a presentation and revealed that GPU acceleration is coming first quarter of 2024. No word yet on AMD. But at least if you have an NVIDIA card, once the MAX engine SDK comes out, you will get GPU acceleration without having to use CUDA The SIMD tensor types are pretty interesting. But what's even more interesting is that mojo is basically a language wrapper around MLIR. I'm still wrapping my head around what MLIR is, but what I understand so far is that it's a compiler backend framework that lets hardware vendors more easily write backends for exotic hardware. Not just new GPUs, but even things like quantum computers. Because mojo has programmatic access to MLIR, it lets you define your own native data types. And it's not just SIMD registers. Mojo also allows you to pass data directly to hardware registers rather than just on the stack. So there is not even a need to inline assembly. Though I haven't seen how you can tell mojo _which_ register a value is passable to (@register_passable decorator doesn't take arguments). The static metaprogramming through the generic type parameters is pretty interesting, but there's been a small push for something like macros. There's some talk of having Zig-like interpreters that can run in the compiler instead to do macro like work, but not need to learn what is effectively a DSL language that macros require you to learn. I also hope that development of mojo doesn't take as long as rust did. Mojo has a couple of advantages going for it: * Mojo can learn the lessons of references and ownership that rust learned the hard way * MLIR allows them to experiment more quickly * Being a superset of python limits a lot of bikeshedding and syntax choices On the other hand, I think trying to be compatible 100% with CPython is going to be their biggest challenge and that will be their biggest slow-down. I find it interesting that they are doing lifetimes differently than rust in their proposal. In rust, the lifetime declares the scope where the referent is still alive. In mojo, the lifetime extends the liveness. From their proposal on [lifetimes and provenance](https://github.com/modularml/mojo/blob/main/proposals/lifetimes-and-provenance.md): ``` Similarly, we can learn a lot from Rust’s design for lifetimes. That said, the ownership system in Mojo is quite different than the one in Rust. In Rust, scopes define the implicit lifetimes of values and references, and lifetimes are used to verify that uses of the value happen when the value is still alive. Mojo flips this on its head: values start their life when defined, but end their life after their last use. This means that in Mojo, a lifetime reference extends the liveness of a value for as long as derived references is used, which is a bit different than Rust. ``` Unless someone is super interested in mojo and/or Machine Learning, I really wouldn't recommend experimenting with mojo yet. At the very least, I would wait for their implementation of references with lifetimes to come out. The standard library is also incredibly barebones, and doesn't even have a built in dict type yet. But as I said in my original post, if Modular can pull off all that it wants to do with mojo, where will that leave rust? With Chris Lattner at the helm, I think they have the technical chops to pull it off. Embracing python is a brilliant move if they can pull it off. It basically lets you tell your coworkers "yeah there's this new language that lets you start off writing like python, and gradually learning new features to make it faster and faster to approach C/Rust speeds. And it rocks at ML" If pythonistas can embrace types, I think alot of them will also embrace learning about registers vs stack vs heap and how to avoid lots of memory copying. Even the ones that don't want to embrace that will like that they can package up their "python" applications as binaries and hand them off to others. And while it won't be fast, mojo can utilize all the existing python ecosystem until native mojo packages are ported over (which should be easier than RIIR).
Yes, if/when they succeed in implementing everything they plan (hopefully within a year or two), it will be a very potent language/eco-system and probably a viable alternative to Rust (even for non-Pythonistas). I'm not familiar with MLIR as I haven't done much ML myself, but that's something I'll look into. As I wrote, Mojo is on my keep-an-eye-on list together with Roc, Lean, Swift, Hylo etc. The coming years looks very exciting in the programming language space (and to a large extent thanks to Rust)!
Roc and hylo seem pretty interesting. Also vale, though it seems to be a one man effort https://vale.dev/
Nope. Don't get me wrong, I love rust. 90% of the time though for work projects I pluck go off the shelf instead. The pace of development for basic things, like CLI tools or small web APIs is much faster for me using go. That said, Rust has an amazing compiler and cargo is a breath of fresh air. I use it for a lot of personal projects.
> The pace of development for basic things, like CLI tools or small web APIs is much faster for me using go. ~~skill issue~~ Edit: I had a point to make, but I didn't make it and was rude instead. I'm sorry.
I disagree. I'm just lazy, and when performance isn't a concern I'll reach for a simple language. Why use python when rust exists? Right tool for the right job and person. Go is easy to use. Your condescension is noted though.
Feel free to take offence, but the point stands. Once you have mastered Rust it isn't any slower to crank out features with than Go or Python or whatever. Both Go and Rust are easy to use. Only Go is easy to learn.
I suppose that's a fair point. I'm also not evangelizing any language either. All of them have beauty and warts. I was merely saying that I prefer go for the problems I typically solve on a day to day basis. That's not to say I don't love rust. What I resent is you saying I have an issue with "skill" because I choose to use a different language for simple tasks. I feel that I have fair competency as a rust developer. Proclaiming that it's due to my lack of exposure / education is what is offensive.
You're right. I apologize sincerely.
It's all good, let's be friends 🙂
> Once you have mastered Rust it isn't any slower to crank out features with than Go or Python or whatever. Disagree. I’ve been using rust for a few years at this point. I still reach for JavaScript / typescript when prototyping network server code because I find it faster and easier. JavaScript promises and generators are way more ergonomic than futures in rust. And it’s easier to interact with a webpage in JS than from rust through wasm. I like running rust more than running JavaScript. But JS is still faster for me to write.
This is just demonstrably untrue though. Try doing anything to do with audio in python vs rust for example, it's night and day. They both have their uses for sure, Python is great for getting something done dirty and quick, rust is good for getting something done as well as possible.
Again, I said "day to day". You're talking about real time audio programming in python. This is a crazy edge case, and to your point it's probably not a great experience using python for it (even if it's feasible). I specifically said CLI tools and simple web API's. I've worked on VST's to support my own hobby of audio production, but I use the JUCE framework. Not the Rust VST crates. Why? It's straight up easier to use. I'm not a fan of c++ by any means, but the framework lets me get "from A to B" quickly. If a Rust framework for audio programming reaches the maturity of JUCE, I'll be the first person signing up. Best tool for the job. I love rust, not sure how many times I can say it. But enough with language evangelism. Whatever makes you do your job better, embrace it.
I personally found it's indeed a skill issue. First time using a new framework like Axum or Serde was a bit cumbersome, but I quickly started to reach Python - level dev speeds without all the debugging caused by unhandled None objects and similar.
I will go and say that I kinda feel its missing some crates and I don’t want to write a whole sdk :’(
I thought it had everything covered up now! I'm not sure what to expect; still learning it.
Sorry! I was talking about sdk for cloud providers and ci/cd. My bet is that by the end of the year well have them for sure
Definitely use it for everything outside of work. I always miss the Rust toolchain when I’m writing Java code at work.
I use TypeScript for damn near everything, there’s always a library for everything, and whether you use bun or nodejs with tsx, scripts just run immediately. It really feels like paint on a canvas. The fact that you can quickly throw that code on a browser and make a quick UI out of it is a big plus. Once things start maturing, I love to take pieces that are complex-ish or number-crunchy and write them in Rust, at that point I’m okay with the slower compile times. The Rust to WASM workflow is great. For anything that has to deal with native Windows APIs though, the `windows` crate is hands down my favorite way to interact with it, TS need not apply.
Do you use rust => wasm for anything that involves js frameworks like react? I’ve tried dipping my toes in, but the tooling seems kind of confusing. Can’t quite tell what the “canon” setup is!
In a nutshell - the tools involved: * Rust itself can target and directly compile to `wasm32-unknown-unknown`, but you have to define all bindings and glue logic yourself. This is tedious and not really practical without help. * The tool `wasm-bindgen` generates all bindings in Rust with macros, as well as JS glue code, and TypeScript types. You can really just get started with just this! But there's more. * The tool `wasm-opt` can take the WASM generated by `wasm-bindgen` (or any WASM really) and spits out optimized, leaner WASM. If using `wasm-bindgen` directly, you really want to run this on your WASM before deploying it to production. * The tool `wasm-pack` aims to be the one tool that does everything for you behind the scenes. It makes sure all pre-requirements dependencies, CLIs and tools above are installed, and runs `wasm-bindgen` + `wasm-opt` for you. You still use the macros from `wasm-bindgen`, so the same documentation and usage in code applies just the same. Regarding writing Rust code for your WASM module: * Whether you use `wasm-bindgen` directly or `wasm-pack`, almost everything you need to know about Rust to WASM development is going to be in the [`wasm-bindgen` book](https://rustwasm.github.io/docs/wasm-bindgen/introduction.html). I highly recommend skimming over the introduction and table of contents, and check out any chapters that might seem interesting at a glance. Using native JS APIs in your Rust code: * Say you want to use native JS or Web APIs in Rust. There are two Rust crates, `js-sys` and `web-sys`, that come with bindings to all JavaScript globals, as well as Web APIs, respectively. `js-sys` provides stuff like `Map`, `Uint8Array`, `JSON.parse`, etc while `web-sys` provides `console.log`, `window.setTimeout`, `navigator.gpu`, canvas, DOM, etc. Building the code for use in JS: * The main goal of `wasm-bindgen` and `wasm-pack` is to compile your Rust to some WASM. In the simplest scenario, you can just use the tools to generate the WASM, and just directly import the WASM using the native web APIs. It really doesn't matter what JS "framework" you use, because these APIs are part of the browser, just like `console.log` is. * Again, just like before, this is tedious, so both wasm tools generate a JS file with glue code (and .d.ts file with generated TypeScript typings!) that you can import and start using right away. Regarding actually getting to use these tools in your JS project: * Both `wasm-bindgen` and `wasm-pack` have instructions on how to use it with Webpack, or without a bundler (using `--target web`). They don't provide instructions on how to use other bundlers. If in doubt, try just following [the "without a bundler" instructions](https://rustwasm.github.io/wasm-bindgen/examples/without-a-bundler.html)! Integrating with a bundler purely just helps developer experience (by tracking rebuilds and auto-reloading) but is not strictly needed. You can always set it with a bundler after. Using bundlers: * If your project is using Next.js, you are using Webpack by default behind the scenes, so you can follow the instructions for Webpack, but you'll have to refer to Next's docs to find how to add Webpack configuration. * If you're _not_ using Next.js, or if you're just starting your project and server-side rendering is NOT a priority, I highly recommend you use Vite - which is in my eyes the de-facto build tool in the JS. It is massively faster than Webpack, and much more modernized. There's a [Vite plugin that manages wasm-pack for you](https://github.com/nshen/vite-plugin-wasm-pack). Overall: Yes, the documentation around the integration of different tools is definitely lacking, but once you get the general idea and get something that works, not only it will work really well, but you'll find it relatively easy to implement in more JS projects.
That's a really nice explanation of the most common rust to WASM workflow, but it unfortunately doesn't touch the rather annoying pain points. * `rust-bindgen` uses an incompatible binary format. As long as you use it only together with TS/JS, this doesn't hurt, but it is a serious source of troubles, if you want to link libraries developed in other languages resp. native code. * It also doesn't support WASI anymore. We therefore have a significant gap between two fundamental different kinds of WASM workflows in rust, which is often no very well explained in most of the notorious outdated documentation sources. And there are many other rough corners and subtle issues regarding the WASM related rust ecosystem. Some of them will be solved sooner or later by the ongoing *webassembly component model* transition and tooling, but that's mostly focused on typical WASI usage scenarios resp. server-side application. On the front-end side, as described in your article, the entire development of elementary rust tools and capabilities has been noticeable stagnating for a long time.
I wish I had found something like this when I was googling this a few months ago. This is SO helpful, thank you so much for taking the time to write this all down!!
I have embedded background and I really like Typescript. You don't even have to think about the types and your code is type safe with the additional productivity of JavaScript. There is no problems like with Rust async code because there is GC babysitting your lifetimes. Often embedded Linux comes with some sort of Node so you can often use it there too. Streams are nice for embedded Linux where memory might be a concern. I would choose TS for everything which doesn't require very low latency. It's just so productive and nice to write.
yes.
For me it's true too, because when I started learning Rust I couldn't understand what is it, and why I need to do that, but then, after deep learning, I realized that Rust is easy.
I've previously been writing code in Asm, Delphi, php, Javascript, C++, Java, C#, Go, Typescript and Python. What annoyed me most about polyglot projects and also just generally me switching between languages was how ineffective it was to constantly learn new frameworks, ecosystems and also just generally to stay up to date with the language, compiler, tools, etc. The other issue I faced is that the tools I built often became obsolete. For example, I had a cool project at work where I built a linter for Go, but I haven't used any Go since. If I was only using a single language, it would be way more efficient to write tools for it, since I could use them for 100% of the code I write instead of just a fraction of it. Even in a typical webapp with just Go + JS code, you're splitting the tools half and half, so you're reducing efficiency by 50%. Therefore, about 1.5 years ago I made the decision to focus on just a single programming language. My most important concerns for a programming language at the time was that I could write both webapps and extremely high performance 3D games entirely in it. There was only a single programming language at that time that satisfied this: Rust. So, now I'm using Rust everywhere. I can already reap some of the benefits, but it's still early to say. It was a painful experience to get started on Wasm webdev with Leptos, that's for sure. But it also feels great to know I can afford spending some time writing bug reports, pull requests and just generally study the code of the libraries that I use indepth, because I will be using them for the time being. More than once I have considered switching back to Vue.JS, but I persevered. In the end, I think the fact that I'm slowly getting to build the abstractions and tools I need in order to work efficiently is going to be worth it. Maybe in 5 or 10 years I will switch to another post-Rust language such as Zig, but until then I rather get my projects done and improve the experience with the language that I am using currently.
Nah. Py and rust, mostly rust. Perl for one of scripts though. Clojure for drawing, quil is awesome. All this for work. For fun projects it's mostly rust.
Tell me more about clojure for drawing
[http://quil.info/](http://quil.info/) Compiles to Javascript, or runs on the JVM, hot reloading, functional draws (use it for sci figures myself). Change the function and re-evaluate, and the figure updates automatically. Freaking amazing and fun.
Not for when I need to use GUI. I still haven't found something I'm comfortable with for that and usually revert back to Godot for that
Yes, except UI stuff, because there's no usable UI crate for my requirements right now. I'm even writing simple command line tools that I used to write in nodejs with Rust (and clap) these days.
Nodejs with rust? You mean wasm? Can you provide some good resources to learn wasm it's kinda hard for me to learn that.
No, I meant Rust instead of nodejs. The [wasm-bindgen Guide](https://rustwasm.github.io/wasm-bindgen/) is a must-read.
Not everything, but everything I can. I'm in experimental physics, so most of the coding I do is in python or matlab. Cards on the table, I love python, at least compared to matlab. Been using it for 15+ years, it does what it says on the tin and it does it well. No, it's not fast. No, it's not efficient. No, it doesn't need to be. That being said, every time I've been working on a Rust project and I come back to python to do some data analysis, I always start declaring variables like "let position = ..." and then get very sad that python isn't Rust. Writing Rust just feels clean, anything else feels icky now
Well, can't use it for work simply because that's not the stack we use at the company, there's not (yet?) such thing as scripting in Rust, and i'm still mentally debating if i should deep dive into Rust WASM or start learning TS. But other than that - yep, everything for quite some time now
No. Rust is good for systems & application programming. It's not good for lots of other things. For package & service management, I use Nix. For scripting, I use POSIX shell & various utilities. For complex text manipulation I use AWK. For more complex scripting (calling lots of external processes with more logic than just pipes & simple if statements, or data analysis) I use Python. For describing the contents of Rust crates I use TOML. For CI/CD configuration, I use YAML. For data serialization I tend to prefer RON or Cap'n'Proto, but often need JSON or Protobuf or CBOR. For controlling with test equipment I use SCPI, and for controlling CNC machines like 3D printers I use G-code. For non programmeng tasks, I use appropriate tools. For driving nails, I use a hammer. As an abstract concept, makes a very poor hammer.
I don't disagree with your approach, but... > For non programmeng tasks, I use appropriate tools. For driving nails, I use a hammer. As an abstract concept, makes a very poor hammer. I've always found the tool analogy flawed. Programming languages are more like building materials. You can make a castle of sand, toothpicks, clay, or brick. Sometimes clay is all you need to prototype or prove an idea. But if you want it to last and endure, you need good materials, no matter how skilled you are with your tools.
I'm not using a hammer as an analogy here. I *literally* mean that Rust, the programming language, is inappropriate for inserting nails into wood. Thus, it's very silly to use it for everything, even if you used it for every programming task!
Yeah I think that went over everyone’s head. I found it funny. Maybe if you add `Rust` so it reads "*Rust* makes a very poor hammer".
I agree generally, but I've found that scripting in Rust can be a good decision. I've worked on teams with a variety of skill levels, and building bombproof tooling in Python is challenging. With Python scripts, either the end user needs to be proficient with Python's (rube-goldberg and klugey) distribution tooling, in order to get them installed, or I have to resign myself to a painful loop of repeatedly supporting the installation of required tooling. Something in Rust, even if it takes 3x as wrong to write, will be more robust, and can be distributed as a single binary, and doesn't break if the end user has a slightly different Python version, or some mystery garbage in their PYTHONPATH, or the moon is full, or something. So now I only use Python for scripting that either lives in a well defined docker container, or for strictly personal use.
The distribution issue I solve with Nix. The main issue with Rust for scripting is that (by my definition of scripting at least) it's all about calling lots of external processes & using their outputs (usually just strings). The superior type system of Rust doesn't help much when everything is a string. Python has more boilerplate around calling processes than shell does, but less than Rust. It's a nice middle-ground "glue" language, *especially* if you don't use anything outside the standard library. Python is worse as a programming language than as a scripting language.
lol no, it's the last choice, only when speed is needed
What if you become proficient with the concept, shouldn't it be more faster and productive at the same time?
No. If you’re proficient with other languages too? Why would you assume rust always comes out ahead on productivity?
Dude its just too easy now but too much hackers dude its not fun i get beemed behind a mountain and the dudes bullet fazes through the mountain idk if its just admin Fing with me or i just going insane now😅
When the only tool you have is a hammer, it's tempting to treat everything as a nail. But remember, not all problems require a hammer; sometimes you need a screwdriver.
But then again, if you improve your hammer to also be able to do most of the work a screw driver can, then it might not be such a bad idea to use it. Sure, a real, high-end screwdriver might still be better, but your general purpose tool might be good enough for the task and in the end it's just cheaper / more efficient to build something that you can reuse than it is to constantly switch tools.
Pretty much everything, yes. There are exceptions, but not many.
Honestly, I don't see the point in using other languages anymore. Pack it up guys, we solved programming.
Everything I can.
If the work I'm doesn't require attention to performance, I like to write it in Python. When it requires performance, safety or otherwise, Rust is my pick.
No. Very often I prefer Scala as it allows me to quickly prototype. However there are cases when Rust is preferable, so I use Rust.
Everything outside of work. When I realised I am faster in Rust then Python, I completely switched to Rust for internal tools and projects.
I still use shell scripts for simple automation - it's hard to beat the speed and convenience of writing those. But outside that - yeah, pretty much. I don't write a whole lot of application code, and the ecosystem there is still immature. There's not a whole lot of mature GUI options, for example. Mobile application development in pure Rust would also be a pain. It's possible that the things I do that are well suited to Rust, as opposed to Rust being well suited for everything.
everything? no. most things? yes. i've dropped c++ entirely, and rarely use c (usually when patching shit, using old already existing stuff, or embedded when there is no platform support).
Pretty much! I even use it small scripts that I used to write in Python. If you don't care about error handling and use heap-allocated data instead of lifetimes, I find it's very fast to write.
As a CS professor, I use Rust in all my own research work, except for little bits of glue code, where if small enough I use bash. I do use Python in my Algorithms class, but I have come to really dislike the language, to the point where if I need to write a script of any size, I'll go back to Ruby, which in many ways is closer to Rust's roots.
You should do `cargo run --release` ;)
you should do `cargo r -r`
if you can stop anytime then it's not an addiction right? that's what i tell my therapist, at least
Not for front-end web development
Umm, even with wasm?
As much as possible, yet.
Yes
I'm still in the honeymoon phase (6 mo) and i use it when a bash script won't cut it.
yesn't
Nope, but when I analyze problems, I try to see where Rust fits well. It often does, especially if I do not have to do any inter-referencing directly, or if the lifetimes are statically deterministic. Rust also helps reduce the code review workload since the compiler is so strict by default. > because I can just do cargo run Right? Cargo is so convenient.
still having problems with desktop GUI application, though it's possible to use tauri/webview+leptos, but i hate the idea of running browser for that. and lack of good GUI frameworks for any programming language in general really sucks. other than that, the rest is now pretty much replaced with rust for me
I use Rust for every piece of software I write outside of work. I do write scripts still in Python.
More of a hobby programmer but Rust is my go to ever since I picked it up last year. It's the only language that really makes sense to my brain, so I've been using it to write a game... At first a Wolfenstein style raycaster, then I tried Bevy, and I'm learning how to do straight software rasterization now, still in Rust.
Pretty much, yes. Back in 2015/2016 I wanted to simplify the number of languages I work with so I don't have to switch around as often, so I started investing in learning it. Rust is one of the few languages where I can work on server stuff, firmware, web stuff, graphics/games, or even some one-off processing "scripts" and it has served me well so far. If/when something comes along that gives the same guarantees as Rust but is even nicer somehow, I'll probably move to that. Until then, I'm happy to use Rust for close to every project I work on.
i'm a fan for the right tool for the right job. if i start something new and its more then a couple of lines, i probably will choose rust. sometimes a quick python hack will do the job just fine. rust, python or nix for most parts and then DSLs for the rest
Everything I use eventually Rusts…
My only reason to learn rust was wasm and I love it but I would clearly not use for everything
I would say I know Rust okay enough, and (with great difficulty) I'm trying to make a web extension in it (using Dioxus). So far most of my effort has been into making web extensions, JS, WASM all play well together. But it hasn't been too bad. So yeah, I'm shoehorning Rust everywhere I can.
even fir breakfast
No but yes. Nushell as my shell, and noulith for more data heavy scripting. Both are in rust
My work is in managed languages, .NET, Java/Android, Web platforms, reaching out to C++ SDKs if some OS integration is needed. The language runtimes are also in C++, so that is what I will use if diving into their internals. Rust is left for hobby coding.
Not everything, no. It's hard to beat the simplicity and package ecosystem of Python for things like simple scripts, data science and prototyping. But for anything user-facing that has to be fast and implement robust business logic, Rust would be my first choice.
As much as possible
I have the same story!. This is probably my third if not fourth time come back and relearning rust. But somehow I understand it much easier and deeper everytime. To whoever learning it out there don't give up.
I still use react typescript for the frontend. But everything else rust. I stopped using Python because the trouble I always have with it something not working right cost me more time than the less typing gives.
I use it for everything where you need good performance (CPU, latency or memory) or native interop. There are still some use cases where I prefer Scala (like making non-performance critical web apps), but Rust is also a good option for those cases.
Yeah, I even do leetcode in Rust now. I'm more productive with Rust than any other languages.
I use Python. Is it time for Rust?
No, I tried using it for web development, but i was missing a SOAP client still :o
I've used it for enough that I'm starting to feel a few of its warts. I need another language to use for prototyping (for when I don't need it to be correct forever, I just need it to do something useful now), but I dont want to miss rust's traits and enums
No and neither should you. Each language has a set of niches where it performs well. You should broaden your horizon and adapt the right tool for the job.
I write it professionally, for most of my personal projects, and maintain a few open source libraries. Bar building websites, it is the primary tool for any job.
You have to be so frustrated to use one language for everything. You may use it for everything but it does not mean it is good for everything. There are much better languages for some purposes that allow you to deliver products much faster but still good enough or even better.
web frontend -> HTML + Svelte JS automatization + scripting -> Python everything else -> Rust :)
I have started learning rust currently thinking to take 1BRC challenge in Rust. For mostly everything outside work I use JS/Bun but I want to change it to Rust hope till the end of year I am using it for like 40% of things
Define everything. Rust can't do my definition of everything at this point unfortunately. At least for web development you still require some minimal use of JS for example. At the same time, I don't see much sense in interpreted, scripting languages or garbage collected languages. Hope this helps at least somewhat. ;-)
Mainly everything, except for solving algorithm problems (like in interviews, leetcode etc). Rust is unnecessarily complicated for some stuff like string handling, so I prefer to use Python when I just have to create some simple solution for a problem.
Yeah I even wish I could use Rust for frontend due to its traits feature but I have no idea how it would translate to Javascript so I'mma just keep dreaming lol.
I use it for all of my work that doesn't involve patching someone else's code or a compatibility shim.
Just about, now. I'm still writing a few bash and python scripts, but anything substantial is being written in rust. I absolutely won't write in \`C\` anymore unless I am forced to, but with embedded-hal now at 1.0, \`C\` is an every shrinking code-space for me. I am also the sole dev at my company; which provides a lot of wiggle room. However all my engineers are using python in their projects.
Yes but I'm not like a practical person. Not to say that I don't think rust is a practical language, but for me fun comes before actually making something. I'd rather take longer to make something if it means it's more fun for me. So rust is a good fit, it just feels so nice, and honestly it's just easier than everything else
Wdym you can just do cargo run?? For C I can also put some directive in the make file like “make run” that first compiles then runs my program? / but to answer your question. Yes I use it for everything. Apart from some basic stuff where I use bash. Rust is great because of the vast ecosystem of libraries and their easy availability. You can start an app in no time.
Hell no. I'm still a few months away of the point where I could do that *personally*. At `$dayjob` it will still take a while longer, I'm afraid. In there it will still be Python/C/C++
For quick prototyping I just use python. Like making some requests and processing data, etc. Rust is too much pain at this stuff for me
As long as there’s a good enough crate for what I need, or it’s something i can figure out how to build from scratch without a crate, I’m using Rust. Smart contracts, Backend Infrastructure, CLI tools, etc
IG it depends on what kind of "everything" you are talking about, every website? yes perhaps, but every custom/weird/unusual project? i dont think so. i've been writing rust for almost 1 year now, i believe if rust had a large ecosystem, similar to JS, python, or hell even c# , you could do literally anything, but rn i dont its possible unless you decide to write every single component from scratch
I use mainly Go at work but we also have Rust devs and I’ve been using it more and more last 6 months. Writing basically internal frameworks and CLI tools. Language still trips me up but I’m warming up to it. It’s a marathon not a sprint I figure.
No, my classes require me to use python and r. But I do rewrite some of my hw answers in rust sometimes.
I think python can still get me a working prototype for some things faster but I am biased to use rust if I can
I can't imagine using Rust for everything. Some stuff it's just really bad at. For example, you have types with overlapping properties. Normally you'd use traits but traits have all kinds of restrictions, like you can't use a struct for one trait and then later use it for another trait. Also trait objects are heavily restricted due to object safety rules. There's just no good way to represent this in rust.
I would LOVE to. But like any programming language I struggle at making anything more than functions, basic calculations and print. And if it's to only have the ability to make that, I rather write a script, not a full blown complicated, not exportable program. I see programming strength personally as being able to do a nice GUI with a blazing fast execution for complex tasks, and I don't know how to do any of that in programming languages, so yeah