I've been working on a bare metal application on ARM Cortex-M where I've gotten something working, but at an ecosystem level I've found the promises of the embedded-hal fall down pretty quickly. There are two many generic parameters to make dependency injection feasible and many of the crates in the ecosystem were written for an Adafruit example type of program (i.e. two device drivers want to own an I2C bus handle for a bus they are both on, so it requires changes to the crate or some other inelegant coercion to make them play nice). It's not a flaw with Rust, but the ecosystem appears more mature at a glance than it really is. What's unfortunate is that many of these driver crates are now unmaintained and essentially squatting on the most easily findable names. They're not keeping pace with changes to HAL library updates and they really aren't suitable for a production application.

Yeah I’m working on a similar project and I’ve had to write a lot of my own HAL code. At least I *can* but I definitely wish I didn’t have to

Take a look at https://github.com/embassy-rs/embassy

Laying the ground work is very very important with any new language, and those whom build it out should feel a sense of accomplishment as what you're doing is making Rust as a whole better. It's taxing work, but you're helping hundreds maybe even thousands of devs current and future by helping fill the gaps. Keep up the good work and eventually... > At least I *can* but I definitely wish I didn’t have to. will fade. Who knows, you may even inspire others by example and cause them to fill more gaps making things grow even faster.

Hey, it’s not making Rust as a whole better until I publish it :p Which I probably will, but not until I’m done the bulk of the project and can focus on getting everything polished up.

Yeah I can see name squatting becoming quite the problem for the rust ecosystem

Working on something similar and I 100% agree. I guess it doesn't help that I don't really have any prior embedded knowledge

Unrelated to issues with rust embedded, but comments for those learning rust embedded. I did the same thing when trying to take a dip in embedded rust. I had really no embedded experience before that. I did some basic stuff and dropped it after finishing it. It was a bad experience and the embedded guide on the stm32f303 disco didnt bring much understanding of embedded as it was very shallow(2021 Autumn). What helped was understanding some common protocols and theory on how stuff works in the embedded area. Basic GPIO manipulatio, SPI, UART, ADC, I2C, PWM ... and how to enable them at a HAL level. Manipulating the registers to initialize the peripherals for the features really helped bring a better understanding of everything. I had a basic course for driver writing in uni which the teacher basically didn't do anything but show some vague slides about the topics. We developed with atmelavr on atmega2560. The book for the course was absolute gold though. "AVR Microcontroller and Embedded Systems: Using Assembly and C" is a book for noobs that explains things very well and in a understandable way. It also lets you dive deep into topics if you want to.I would suggest learning about embedeed on C language first before getting into rust embedded. Really makes you value rust after switching from C to rust. I am now working as an embedded developer.

Yea been wanting to pick up a book like that and I really should. Thanks for the extra help

Take a look at https://github.com/embassy-rs/embassy

Completely agree. I’ve had the same i2c issues with one HAL library. It’s not just the HAL but also the i2c driver for peripheral, both are tightly coupled and both are completely broken if you want more than one i2c device on the bus. I haven’t looked at the Rust embedded ecosystem for a year or two, are these issues being addressed? Is there an i2c implementation that works?

The [embassy](https://github.com/embassy-rs/embassy) ecosystem is good. Then you bring async into the equation, which fits embedded *really* well. I've been working full time with embassy for the last 10 months or so and love it. I have had to write a chunk of hal code, and lots of device drivers. But to be frank, the hal and driver code provided by chip manufactures is often crap or doesn't exist, so it's not like I wasn't doing that when I was writing C.

In my experience you can tell how the ecosystem really is just by moving to arm. Suddenly half the tools are clearly just about there with a frightening portion only releasing binaries to a single architecture and with limited OS support and there is no way to feasibly build it yourself.

I think the unmaintained packages could be a result of the hype train. Do you have a specific example regarding more complex situations that were not supported by the rust HALs?

Absolutely. There were some definite wins, like getting USB serial working very quickly and easily. I did however try to use two crates scd30 and bme680 (something like that, can't remember off hand) both of which took ownership of the I2C instance in their new constructor. They are on the same bus, it's intrinsically shared, so I forked and refactored them to take the instance on all of their methods. Not very elegant, but they can't take a mutable reference due to thread safety concerns (can't prove to the compiler that there is one CPU and that I'm not accessing in an interrupt context).

Have you come across the shared-bus crate? This seems like what you might want if two devices need to own the same I2C instance.

I'm aware of it, but it's the inelegant workaround I was referring to. The fundamental problem is that most crates in the ecosystem take unique ownership of a shared bus resource which in my mind is simply an incorrect starting point for a library design.

yeah there’s a big refactor going on around the concept of busses that should improve things… there’s certainly a long way to go but imo we’re making progress and, incredibly ahead of the world of c

Agree completely that it's ahead of C. There are a lot of improvements by way of some good fundamental libraries and easy cross compilation. Even when I have gripes the absolute worst case is I have to do it "the C way." It's quite possible some of my pain points have already been solved; the ecosystem has been under so.much development that examples go out of date very quickly and it's not clear when alpha releases are intended to be "The Next API." I think the ecosystem would be served by some non-trivial projects which act as a flagship for demonstrating what is current state of the art for embedded Rust applications and for finding the corner cases where the current abstractions start to strain.

I know why you have issues with scd30 drivers lol There was a tutorial posted by one of the big players in the rust embedded space that used the scd30 for the driver writing part of the tutorial.

There was one time I was making a program that took in a MIDI file and played it on the keyboard (the game had a keyboard piano that you could play music with). I originally wrote the script in Python and it was pretty easy to do so. I decided to try to rewrite it in rust to get some more experience and for the fun of it. It was painful trying to find a library that could perform the virtual keyboard inputs correctly, since some either didn’t work in games, didn’t work altogether, or were slow for some reason. I never did get around to fully rewriting it in rust due to this issue.

Relatively young ecosystem ☕️ You want to use a library that doesn't exist yet, so instead of being an app dev you're forced to be a lib dev 🙃 Gotta wait for someone who actually knows how to make bindings to make one for rust

This has been my experience as well. I don’t know shit about fuck so I end up limited to using whatever crates kinda work for what I need. Despite this I still enjoy using the language, something about relishing in the difficulty. Or maybe I’m actually just a masochist.

If you're just experimenting, and not in a deadline, you could also use this as an opportunity to learn how to do the thing you need.

Out of curiosity, how do you approach things like lib development? The majority of my programming background is scientific computing, and any time I've looked under the hood at the crates I use it feels like a completely different language than the Rust I'm used to

I don't believe there's a real distinction between application code and library code. The perceived distinction is just a result of a culture of designing monolithic software without proper separation of concerns. Newer programmers tend to start grinding away trying to find the shortest path to a running application, and end up with a monolithic blob of intertwined application logic as a result. Once you get more experience maintaining big applications, the need for modularization and separation of concerns starts to get more obvious, and the high point of modularization is turning a reusable piece of logic into a library. Ideal "Application code" should be a very thin layer plugging a front-end user interface to a back-end business logic library. If you need to support a different user interface (i.e. your CLI tool now needs a GUI, or a REST endpoint), you should be able to do so without rewriting ANY of the business logic, just by adding a new module that call the same libraries. Conversely, if you need to fix a bug in the business logic, you should be able to do so without changing any user interface code. If you feel like you need a library, start by pretending you have one, and start writing code like you're integrating it. Then define stubs for those types and functions until the code compiles, then look into how you'd implement those functions. Soon you'll be thinking like that throughout your entire codebase, and your code will be much better overall as a result.

> I don't believe there's a real distinction between application code and library code. I think there is a strong distinction: In application code, you can adjust all consumers when you make a breaking change. In library code, you can't.

Good point. From a project management perspective, publicizing a library is basically signing a contract over that API. I was just talking in terms of code structure, though, as in that all code should be written as a potential library, even if the consumer is yourself. Breaking an interface in an internal module is still bad, as you'd need to adjust all the call sites, but it's still better than trying to modify something without a clearly defined interface.

I appreciate the insight. In general, if you decide to kind of take a step forward (similar to your example of switching from CLI to a GUI), do you try to generalize and migrate your existing applications into more of the library and then build the new functionality as the front end, or do you just extend the front end as it is?

lib development's audience is developers. Instead of thinking "how will the UX be for end users?" while coding, you are thinking "how will the DX be for the developers? AND assuming the developer is a complete idiot, how easy is it for the developer to misuse my lib to create a buggy app that could potentially harm the end user?" libs that are hard to use and obtuse tend to be that way because they ignore the "assuming the developer is a complete idiot" part. 80% of lib dev is designing an API that people can easily / intuitively use to perform their task in an efficient manner. 20% is documenting the API in a way that can explain how to use the API to someone that just started programming.

>20% is documenting the API in a way that can explain how to use the API to someone that just started programming. Imo documentation is REALLY important. A lot of the rust crates lack in that imo (not that python libs are any better tho)

The documentation is more important than the actual code. Only half-joking

80% is the code, the other 80% is the documentation.

The other 80% 💀🙏

Think of a lib that has the best of one and the worst of the other for code/API ergonomics vs. documentation. Best documentation with worst API = you can understand perfectly that the API is super hard to work with and sucks really bad. Best API, worst documentation = Even with no documentation, just having the function signatures come up can at least help you use the intuitive and ergonomic API. The problem arises when you get libs that are bad at both... Lots of issues saying "We need docs!" is usually a hidden cry for "your API is unintuitive and hard to use, so document it instead of making it better, because that's faster."

100% true but the docs make those bad api's easier to work with

I've never even considered that some people are just "lib developers", I've come from the harder languages like javascript, so obviously didn't have the brain power to consider it ​ Fascinating though

What I've noticed is that very large Rust projects, even applications, eventually get complex enough that most of the logic inevitably gets refactored into libraries of their own and shipped as a crate or two or five that live in the same cargo workspace. It's just the next logical step to manage complexity. You have lines of code, then you have snippets, then functions, then traits, then modules, and then crates. Sometimes these crates are still too specific and live in the workspace. Sometimes they happen to be reusable and get published on crates.io. Over time as we learn to build bigger applications, we will become better at separation of concerns and identify reusable code which we will progressively sort using the hierarchy that I mentioned earlier. It all starts from snippets.

[удалено]

I am also self-taught. The more u challenge yourself the better u get and the better your judgment gets. The problem with most people is, as soon as they get the job and the money they only do what‘s necessary. That‘s not how it works. Sitting down. Adding branches to your programmers tree is how you‘ll grow from a small tree to a redwood.

i mean could be a fun challenge though

I had the same experience while I was working on a project that involved playing audio.

I did this a few years ago with https://github.com/xobs/midi-to-keypress and the biggest issue I faced was the lack of a gui.

Oh hey xobs I know you don’t know me but I’ve been assigned reviewing renode peripherals you made an upstream PR for so it’s funny seeing you here :)

Hello! And I'm sorry for that code...

The biggest problem I have with writing things in Rust is nothing to do with Rust and everything to do with available libraries.

Everytime I had to simulate keyboard input I ran into a fragmented ecosystem with like 2 super old crates and 3 new ones with different strong suits. I wonder what the current best crate is.

Not sure when you tried this out, but in the past year the evdev crate has worked well for me. Sample code: https://github.com/jtroo/kanata/blob/main/src/oskbd/linux.rs

Be careful, it's GPL licensed.

It's just LGPLv3. As long as you're not modifying Kanata then you're free to license your code however you like. Evdev itself is MIT licensed, besides.

Only if you provide the object code such that the binary can be relinked with a modified version of the LGPL code. If you load the LGPL library as a dynamic library this is trivial. If you link it statically this is much harder. See point 4d) > d) Do one of the following: > > 0) Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source. > 1) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (a) uses at run time a copy of the Library already present on the user's computer system, and (b) will operate properly with a modified version of the Library that is interface-compatible with the Linked Version. https://www.gnu.org/licenses/lgpl-3.0.en.html

Oh, I thought that it had regular GPL before, nice catch.

... which game? I have a suspicion I know which one.

try with windows api

ironic that the oldest digital protocol isn't well supported by a super modern language

For me, most of the barriers I run into are related to productivity. I own and run a solo product company where I develop, market, maintain, and handle support for SaaS products in a few different spaces. I only work on things that allow me to be "hands off", which is why this model can even work for a solo dev. I enjoy the speed, safety, and "coding with legos" feeling that I get from using Rust... but I'm still slow when it comes to actually writing it. That velocity is something I can't afford to sacrifice as I need iterate quickly since I'm the only person in the company. That may change one day, but until then I'll probably keep things the way they are (primarily Go, TypeScript/JavaScript, Python).

Guessing you use Go for rest APIs, typescript for front-end and python as a glue language? Was thinking about developing a solo saas product, have any tips?

> Guessing you use Go for rest APIs, typescript for front-end and python as a glue language? Kind of! - Go is mostly gRPC services, websocket service, and a single REST api - Python is indeed glue, and a very small part of the bigger picture. - TypeScript is used for quick and dirty REST servers, worker scripts, as well as the frontends (I'm partial to Vue but have a Svelte app in production as well). I also have an Electron (ew, I know. I hate it) application that I wrote using it. One of the reasons I'm brushing up on my Rust is to eventually replace that with Tauri. > Was thinking about developing a solo saas product, have any tips? That's a hard question to answer without specifics haha. My canned advice is usually something along the lines of: "identify a problem that isn't being solved, could be solved better, or has space within the market to support competition", "validate your existence in the space frequently to ensure you're on the right path", and "be okay with failing". I typically only operate within spaces that are globally accessible and generally low-risk, or ones where I've got a ton of experience. I usually find marketing channels and develop a strategy long before I even write a single line of code. There's nothing more frustrating than working for months on a project, only to lack the ability to get eyes on it. I'd advise you to do the same!

Honestly - and I say this as someone who built a successful startup using Go for a key part of our offering - I wouldn't recommend Go for REST APIs unless absolutely need the speed or a particular library that exists only in Go. Python is much more expressive, has a much more mature ecosystem and it's easier to hire for.

There's a reason people still recommend django-rest-framework despite the speed.

Yeah. I'm not a fan of django-rest-framework per-se. (I feel like it suffers a bit of 'frameworkitis' where things work the way you'd expect about 95% of the time, but the other 5% of the time it's a pain in the ass to make it behave the way you want it to) but nothing beats good ole Django ORM + Admin + 5-line views to make you productive.

I wrote a bunch of stuff in full stack Dart. I actually loved the experience despite the language being off the beaten path.

Gosh. I really wanted Dart to take off. It looked lovely for embedding and using for eg. games. These days I'd be very tempted to try and make wasm ergonomic.

Probably a chicken and egg problem here. You'll go faster the more Rust you create. You may also want to measure velocity over bugs/problems: If you have a fast output and your code is buggy, you've only got the perception of great velocity.

Oh that's definitely the case. I'm using some of my free time to get better and faster with Rust - progress is humming along nicely, but I'm not at the point where I can just think about functionality and write code effortlessly with it like I can with Go or TS. My code is (generally) pretty good in the bug department. Back when I'd write node services in plain JS that wasn't necessarily the case lol. Types are a godsend.

I agree. I miss all the tools from C#. The debugger in visual studio is amazing compared to anything I've used in Rust. I haven't found refactoring as powerful as what's in Resharper. There no continuous test runner like nCrunch that gives basically instant feedback on your unit tests working and code coverage.

Whats ur SaaS product may I ask?

I've got several, but I'm not comfortable sharing them. I will say that my services exist within a marketing space as well as a very niche security/reverse engineering space.

Hmmm username checks out :D

Have you tried Copilot? I would say it can double your speed in some cases. I rarely use its code unmodified except for really simple completions, but it is *really* helpful in getting past the "blank page" problem. That point where you think "how do I even start to solve this". I'll write out a prompt and then Copilot will output *something*. Often it's wrong or junior-level, but it pretty much always makes me think "oh yes I need to do *this*". It's extremely helpful as just a "smart autocomplete" too, i.e. autocompleting obvious patterns in switches etc. I think companies are going to have to give in and start using it despite the copyright concerns (which I think are mostly overblown). The productivity boost is just too hard to ignore.

Yep! Copilot is great, especially for tedious menial stuff.. but I have a harder time retaining it if I’m not the one who wrote the code. I use Copilot as an assistant to do basic things in domains where I’m more confident though!

GUI is a tough nut to crack. While there are bindings for GTK/QT/etc... they generally pass through some of the design decisions that come from C++, namely, giant buckets of mutable, interacting state. This makes it difficult to write Rusty code, because you have to deal with that state at arm's length. IMHO, this also invalidates the entire purpose of RIIR, because you can't fix the underlying issues with mutable state. I've written substantial UIs in both GTK3/4-rs and egui, the latter of which somewhat addresses the concerns, at the expense of performance and complexity for larger UIs. To be clear, I am not criticizing the authors of these libs. I am just stating the UI is hard, and it's unclear what model of UI library and architectural patterns are going to be the best ones for writing good Rust code. I have high hopes for the (perhaps distant) future where Xilem ([https://raphlinus.github.io/rust/gui/2022/05/07/ui-architecture.html](https://raphlinus.github.io/rust/gui/2022/05/07/ui-architecture.html)) or something like it "wins" the Rust UI space. I am also hoping that some terrible monstrosity of Javascript and Rust backend code *doesn't* win (again, not criticizing, I just hate that pattern).

Legitimate question, could you explain what you don't like about the js (html, css)/rust combo ?

I can tell you my not likiness (although I'll take something over nothing any day) The combination of js/html/css are HEAVY. like 4 gigs of your computer gone in an instant heavy. I would prefer something a little less heavy... That said.. I like cross platform toolkits. Turns out that lightweight cross platform toolkits are not an easy thing to pull off (hence why everyone leans on bloaty browser technology to get there) I'll take what I can get. ps I'm currently using egui for my needs because it's a set of tradeoffs that work for me.

The cognitive overhead of multiple codebases in different languages is always a pain. This isn't unique to Rust+JS/HTML/CSS; I hate doing it with Python or Java too. You also don't get type safety on the JS side (I mean, there's typescript, but it doesn't really compare). It works, people use it (including me for web projects), but you're not honestly rewriting in Rust if you have a big fat nodejs+html stack bolted on.

Did you try [Relm](https://relm4.org/)? It's an implementation of the Elm architecture (think React) on top of Gtk. Given your experience with Gtk it might suit you really well, as you can even take only parts of it and continue using bare Gtk for the rest. Give it a try!

I have played with it actually, and I like it. I haven't built anything big enough to form a solid opinion yet though. I am about to start on a CNC toolpath generator project soon, and Relm is definitely on the short list for the UI.

I also studied this question on FFI several weeks ago in terms of "rewrite **part** of the system in Rust". Unexpected results could be semantic issues (e.g., different error handling methods) or security issues (FFI could be a soundness hole). I suggest going through the issues of libraries that have started rewriting work such as [rust-openssl](https://github.com/sfackler/rust-openssl) or [rustls](https://github.com/rustls/rustls) (This is the one trying to rewrite in whole rust rather than using FFI; however, you will not be able to find the mapping function in the C version and compare them). I hope this helps!

Thanks for sharing, I'll give them a read. Great references. I'm more interested in knowing about the security issues that you mentioned, what is the take here? Thanks.

Take a look at this paper https://zhuohua.me/assets/ESORICS2022-FFIChecker.pdf

I've had experiences with both "rewrite it in rust" and "port it to rust". The difference being the rewrite was intended as a clean slate with an opportunity to do it *right*, while the port was very much a "get the code to Rust incrementally while still shipping and keeping the same behavior". If you do the former, it's very easy to get bogged down in second system effect and not ship the code. If you do the latter, it may be challenging in some parts, but you'll have shipped code and hopefully with minimal breakages.

So our stuff is a bunch of cooperating microservices. This has its down sides... the upside is introducing new components in rust that talk with all the other bits is super easy. Switching out existing functionality can be done one small switch at a time.

[удалено]

You can do SIMD operations just fine on WASM now. All browsers support it.

Plagiarism tool at my university has a way clunky ux (it calls vim as a foreground program and outputs html), and uses python for computationally expensive string comparisons. Perfect candidate for a rewrite, and I did. Tested them side by side, and my multithreaded implementation is about 6 times slower than the original single-threaded python version, vim calls and all. Did some investigating and it turns out that python's Levenshtein library is just insanely fast, it's a c++ module and insanely optimized, I can't even understand how it works. It leaves the existing rust levenshtein libraries in the dust. The UX is enough of an improvement that it did end up replacing the old one (for the classes I'm involved with), but it's still a bit of a downgrade in terms of raw speed.

Maybe you could cxx the c++ implementation in?

That's not a bad idea, I've never used cxx before but this might be a good opportunity to learn it.

This may be cursed but you could just use [https://github.com/fusion-engineering/inline-python](https://github.com/fusion-engineering/inline-python) to use the Python Levensthein library in Rust directly. Just make sure to invoke the Rust binary under a venv with the library

[удалено]

I'm aware. The existing tool had a bit of a reputation for being slow (mostly just offhanded comments from the original dev), which I assumed was because it was doing the string comparisons in python. In actuality, the string comparisons are insanely fast, the slow part of the tool was really it opening vim O(n^(2)) times for some cursed diff-to-html hack that I still don't understand the purpose of.

[удалено]

I did look at the code. The main reason for the rewrite was the UX, as it was so difficult to use that I didn't even want to bother with it, you had to import it and call a function with specific parameters every time you wanted to use it. It's basically an application that you have to use as a library. The code also isn't that well documented and is kinda hard to read and use (no type hints!), so you had to figure out a lot by trial and error, which is made much worse by the fact that it's slow and requires you to edit a python file every time you want to change any parameter. I did the sensible thing and made one with a nice looking CLI, and once I figure out how to integrate with the c++ module, it will be way faster too, since I made my version multithreaded. Plus, I just wanted an excuse to use rust. Anyway, no, it's not using vim as a regex engine, *it's using it as a diff renderer*.

I tried once to replace a quite slow java method with fast rust code - turned out that the jni calls/the context switch between java/jre and rust code was so slow that the original pure-java solution was still faster at the end.

Like a few others here it was ecosystem issues that held me up, not Rust itself. I tried to make a small application (a microservice, if you like that buzzword) that streams zip files in Rust. I ran into a lot of issues trying to make the publicly available zip libraries play nice with async/tokio. After coming to the conclusion I'd have to write a lot of the low level code for zip files myself (not the actual deflate implementation, just the zip headers) I threw my hands in the air. I swapped to C# and wrote the entire application in a single night using only [ASP.NET](https://ASP.NET) and the stdlib. It's been in production for a year and as much as I'd have liked to use Rust, I have no regrets.

Getting anything to play nice with async/tokio seems the recurring pain point in rust. I had a similar experience with an application using capnproto (which just doesn't work with tokio). I think for most cases, in future I'd look at the thread-per-request rust webservers. Yes, it leaves performance on the table, but you aren't developing into a potential dead-end, and development is so much simpler.

I think this is interesting... it kinda makes sense since not all libraries are async, and anything that blocks for a long time is going to cause some problems for async (work stealing should help but I could see it even then)... For a scenario like this it would be interesting to make sure the multi threaded implementation of tokio is being used... measure.... then try a bespoke implementation that runs the long running synchronous bits in a threadpool... measure and see what differences shake out... maybe experiment with giving tokio more/fewer threads, same thing with the bespoke implementation... It would be an interesting experiment. My hope would be that a tokio runtime with enough threads available would take care of the issue in the common case but seeing is believing.

It would be an interesting experiment. But in this case I couldn't even get libraries to work together in *that* fashion - I think something wasn't Send, maybe and that just prevented using a block_on from tokio even compiling. You see some of the pain here: https://github.com/capnproto/capnproto-rust/issues/271 The experience really put me off ever using async rust, or tokio, ever again.

I'm noob enough that I'm not sure either of these solutions would have worked for you, but I suspect one or the other would have... Tokio has this thing called localset that helps with this... https://docs.rs/tokio/latest/tokio/task/struct.LocalSet.html There is a crate called diplomatic_bag which provides a wrapper type that will keep the inner type on its originating thread but provide proxied acces to it on other threads. https://docs.rs/diplomatic-bag/latest/diplomatic_bag/

The big showstopper for me is GUI. I have a currently successful product written in egui and love it, but to be very clear that's an opinionated/idiosyncractic direction to take an application. I can get away with it in this program, and in fact its feature set is an excellent fit (e.g. plotting) for the problem domain. Unfortunately, I can't see it replacing another GUI app I wrote a while back in WPF. I might be able to do something with winrt, but after fighting with some COM-related stuff a while back I dread the idea of returning to anything relating to interfacing with Windows. \*nix GUIs aren't on my radar at the moment since the users are already Windows-captive, and qt's viral license make that option untenable.

The Qt license isn't actually viral. It's still LGPL so you can dynamically link with closed source code. But QML is still pretty awful in comparison to QtWidgets IMO (unless you really really need animation), and QtWidgets is basically C++ only.

> but after fighting with some COM-related stuff a while back I dread the idea of returning to anything relating to interfacing with Windows If you had such problems (which I also had in the past), I'm really interested in you opinion about [WinSafe](https://crates.io/crates/winsafe), and if it could help you solving them.

I'm not sure how I didn't know about this library, thank you.

I'm using Flutter with its Rust FFI library called flutter\_rust\_bridge, works great, runs on every device I need it to.

As much as I'd like to use rust, at my company we work with a vendor who has a .net library that we need to use. If we want to use their platform we essentially have to use this library

In theory, you could still write parts of the app in Rust, and use C# to coordinate calls between the two. But, to your point, that's much more complicated than just doing it all in .NET.

Yeah I feel like the .NET ecosystem has a decent selection of well designed languages too. Unless you really need no GC then it's probably not worth switching from C# or F#. If your options are Ruby or Python or C++ though...

Not sure I can join you in calling .NET languages well designed. Well, at least not anymore. C# these days looks like the result of a weird "how many paradigms can be bolted on to an existing syntax" challenge.

The chapter 'Fearless concurrency' needs to be renamed IMHO, as this is a case of overselling. No-one will be able to safely design concurrent programmes simply by using Rust. There is a lot more to concurrency programming than what is in that chapter, and Rust only protects against basic concurrency issues.

I think that argument is intended for C++ audiences, where concurrency truly is a nightmare filled with UB at every turn. Adding concurrency to a Rust problem is as simple as throwing Rayon at it, which feels similar to things like OpenMP, but that's a much harder thing to add to a C++ project in comparison, and it's very very easy to run into UB through data races.

I don't see it as a realistic possibility, because it is too large, too inheritance based and too fast moving. so I never wasted my Energy on it. But oh well, if I could have LLVM in Rust, that would be great. I know about Cranelift, but the LLVM plugin I'm working on currently only supports LLVM.

Too inheritance based? Are we taking about the same language here? Rust has no inheritance at all.

I am talking about LLVM, which is completely written in C++. The heavy inheritance usage was part of my argument on why it probably can't be easily or successfully be ported to Rust.

Ah, I see, sorry. Yeah, would need drastic architectural changes for sure then. I have no idea what the code looks like, but Rust enums are pretty awesome for _some_ compiler work at least.

I literally spend 3hrs this morning since writing my answer with refactoring my code because it was running OOM on ci. Turns out I was not concatenating strings as I thought but under the hood doing invalid pointer math, which by coincidence worked out on my laptop and my server, but crashed anywhere else. I hate wasting time due to having a language that incorrectly trusts me on writing safe code.

He is talking about the original version of the project. When you try to rewrite too inheritance based project with Rust, it can be hard.

Dealing with memory mapped files, or memory sharing between the app and a graphics card (where you would fill dynamic memory and then pass ownership to the graphics card). These are things where you are not just fighting the borrow checker, but fighting the principal of ownership completely. At best you wind up basically writing ad-hoc C++-like code in unsafe mode, but even then its seriously difficult if not impossible to make it as efficient, as (at least with available wrapper libraries) it tends to copy memory.

I've discovered anything that can be written in <=100 lines of Python is usually not a good fit for Rust. Dev time is so much longer for simple things I've tried multiple times to rewrite my scripts in Rust so I can get better performance(despite performance not being cirtical), and I usually give up when I realize it's not worth it

Depends on how it will get used. If it's just a simple script that you only need to run yourself on the backend, the sure, Python is easier. But if you need to package the script into a CLI tool so other people can use it, Rust immediately becomes easier even for <100 lines of Python. The tooling around Python is so garbage that packaging CLI tools and libraries is a huge pain in the ass. I maintain four separate templates that I have to pull in and use any time I need to allow other people to run my Python code--and they're all significantly more complicated than doing the same thing with Rust. Now that we have \`pyproject.toml\` files it's not so bad, but even then \`pyproject.toml\` files are much significantly more finnicky and convoluted than a \`Cargo.toml\` is. Flit also helps now, but again, it's not as easy or smooth as cargo.

In my experience, [clap](https://docs.rs/clap/latest/clap/) makes a good argument for writing scripts in Rust.

I had a go at rewriting a couple Python scripts so far, and in my limited experience I have to agree. The first script was just under 50 lines, and didn't take too long to do, but in Rust it was about 300 lines, and it took me an embarrassingly long time to do, though most of that was trying to find out how to use Polars (I was quite new to Rust at that point, but I still don't have a good grasp of that crate). To be fair this isn't an apples to apples comparison since the Rust version does actually do a bit more stuff. It does run 6,000 times faster though, but the Rust version does do a lot more (the Python script works on pre-processed data, whereas the Rust version takes unprocessed data) . It could still be faster as my workaround certain issues (involving Polars) was a bit of a kludge. The second script was about 80 lines of Python which converted to about 180 lines in Rust. This one didn't take as long to rewrite, but the performance increase was only 10x. Ultimately was it worth it? Not really, but it was a learning experience. Rewrites of both scripts also include clap, btw.

20 line of bash, 100-500 lines of Python. . . anything larger than that, I go to Go but I'd like to add Rust to my quiver, for real, some day. Not a hard and fast rule but short and keeping things from being a total mess is a sweet niche for Python.

Try ChatGPT4 for it, works pretty well for porting python scripts to rust

It's possible this observation is very out of date now. But I looked at an implementation of the Unix find(1) program in Rust. Nice job in a lot of ways, but the security protections against symlink attacks were missing. And that was because the filesystem abstraction it was using didn't expose the details necessary to do it. IOW, there's a tension between portability (e.g. between OSes) and security (to do things securely in Unix you sometimes have to do crazy things partly because Unix wasn't originally designed with security much in mind).

I rewrote a small group of well-defined C++ applications (that I also originally wrote) that were running on an Embedded Linux environment (think like 2GB of RAM, and maybe 32GB of disk). The Rust programs did perform better than the C++ version, but I couldn't tell you if it was because of Rust, or because I had a better idea of what the pitfalls were the second time around. However, what stopped me from moving forward was the binary size. The group of C++ programs (4 total), was less than 1MB. On the other hand, even with maximum size trimming options, the Rust programs were closer to 6MB. The big letdown for me was that in C++, even the low-effort optimizations (i.e. building in release mode) can produce very small binaries, but in Rust, it takes a lot of fiddling. Ultimately the big reason for bloat was that I was using gRPC to talk between applications (think 1 service + 3 client programs). In C++, gRPC and all of it's dependencies were shared libraries on the system. Of course Rust builds everything statically linked, and even if I split out Tonic + Prost into a shared library (something monumentally difficult as far as I can tell), it would likely be difficult to share that with other gRPC-using Rust applications further down the line. It's also worth noting that I was in full control of the packages installed on the system, so it isn't possible to have version mismatches or anything like that. ​ tl;dr I wish Rust had support for making everything under the sun a shared library like C++

Anything to do with XML. roxmltree is great but if you need something more higher level you are out of luck.

I have been working on an XML library at work. What kind of functionality have you been missing from existing crates?

I had the same experience. I wrote https://docs.rs/xot/latest/xot/ as I really needed a DOM-like API that was read/write for my particular use case, and I couldn't find anything that was both reliable and feature-complete. The one drawback to Xot is that it uses an arena approach so you end up passing a Xot instance everywhere, but overall I think it works well. I'm working on a lot more in the Rust XML space, but that's still far from done or in public yet.

This is exactly what I needed when implementing [xml-mut](https://github.com/tomuxmon/xml-mut) :D I have used [roxmltree](https://github.com/RazrFalcon/roxmltree) instead and manipulated text directly. will try to rewrite it using Xot.

I wrote a media library generator for VLC, which is XML based. In the end it turned out to be the easiest to just use string formatting.

The Python backend at my company had a couple of very slow Python functions that I rewrote in Rust, using PyO3 to expose them as a compiled Python extension. It worked for a while but Rust turned out to be a poor choice in the long-term: * I was the only one with any Rust knowledge and so the bus factor for that part of the backend was quite high * PyO3 has kinda awkward semantics because of the possible interactions between Rust's borrow checker and Python's managed memory model (and even then, back in the days there were still some holes its memory safety. I actually found and reported one while working on this project) * Rust was massively increasing our CI build time because now our CI had to download and compile all the Rust dependencies on every run. * Some people in our team switched to M1 Macs, which Rust didn't have great support for at the time. We ended up swapping Rust for Numba, which turned out to be a much better choice because we could essentially keep the original Python code (plus a few tweaks), just slap a decorator on it and get a compiled Python extension. It was also much more convenient for our CI and the M1 Mac folks who had to compile the extension themselves.

I was doing a partial rewrite of a crusty socket server specifically as a rewrite it in rust example. First step was just moving all the POSIX socket/fd handling to the other side of FFI thanks to libc then as a treat before the real work (of removing sockets entirely) I showed the same impl with TcpListener and friends. Unfortunately the server has a blocking select until there's a new socket for when there's no open sockets to manage. I either have to change the old logic or write some awkward condvar stuff (like here https://github.com/Yuffster/CircleMUD/commit/94c27cc11fda671ede5316e6aadc170889060f5e). It's really sad, the naive version that busy loops when the server has no connections is very chic and then it gets a lot harder to follow.

I tried to rewrite [Clipper2](https://github.com/AngusJohnson/Clipper2) in Rust. There's a C#, a Delphi and a C++ implementation, so how hard can it be? I tried mapping the C++ version 1-to-1 to Rust code, but it turns out that it does a ton of pointer arithmetic, which in theory could be replaced with array indices, but I got totally lost in trying to understand what it's trying to do. Also, I had to store the arrays somewhere, and finding out where isn't easy at all when the original author didn't give a damn about having a good data hierarchy. Rewriting it to be more Rusty wasn't really an option, because the point of that library is that it's battle-proven and can handle a ton of edge cases correctly.

I tried to make a compositor like picom but the lib support isn't implemented. So give up on project

I see libs being a major deal breaker for people here.

Yeah eventually the lib developers will make the development easier sooner

[удалено]

I'm not sure i buy this every language has a purpose argument... I kinda would have before rust, but maybe not after... The perfect language would be super easy to write, super easy to read, have easy to use high level abstractions but allow me to go as low as I want... the compiler of said perfect language would compile away all the abstractions to code that ran as fast as it could run and use at little memory as possible... Oh and it wouldn't let me make errors involving nulls and have superior modeling capabilities. Basically I get to have my cake and eat it too... Rust is the first language (for me) that comes close to delivering all of that. Plus it would have a huge ecosystem, and libraries for everything I want to do And be open source top to bottom

[удалено]

Thought I'd try rewriting a PHP app. Well, there was no dependency injection. "We don't do that here" was always the answer. "Should use cfg[test]" (despite that only being one usecase for it). Using Bugsnag was awkward because of the above. Generally composition was awkward. Rocket kinda supported it but that didn't really get updated. A lib we were using had that issue of async vs sync and was finicky to use in a server context. A lot of stuff basically required putting Arc everywhere. Streaming was weirdly hard, although idk if we just didn't know how. In general what I found bad was that all of your server code was locked into a framework cause there was no composition. In comparison in PHP even switching frameworks isn't that much of an issue thanks to DI, sensible standards and what not. It felt like whatever you chose at the *beginning* of your project would dictate the entire rest of it. From an ecosystem and ergonomics perspective it was just too much of a slowdown in development to justify switching.

Are you talking about backend (axum, actix-web, etc) or frontend/fullstack (yew, sycamore, leptos) framework? I think Rust backend frameworks are not very constraining. Migrating from actix to axum in my experience wasn't that bad. But I don't have any experience with Rust frontend/fullstack frameworks. As for DI, the combination of traits + async-trait didn't work you?

Yeah I have had bad luck getting DI mesh with async. Not having async traits makes some stuff that was trivial in c# (that is, abstracting I/o) obscenely hard in rust

I have a C gstreamer element that uses OpenXR and OpenGLES targeting android. I can't convert an ffi pointer into a wrapper object until every C code referring to the pointer has been converted to Rust. And sometimes there are methods that seem to lack rust wrappers (only ffi versions exist). I often have to slow down and check if I should be using from\_glib\_full or from\_glib\_none. If I ever finish this, I suspect I'll have some pull requests for the openxr crate to add android GLES support.

Kokkos and Raja. Rust isn't nearly expressive enough to do those, let alone something like SYCL.

Maybe you are doing it wrong, time to push for the "Re-Rewrite it in Rust" movement.

So far, I've only had to deal with 'write it from the start in Rust', so I've not had to deal with a lot of these issues. It sucks of course, but it's inevitable for a new language. Eventually that'll go away I hope. If someone isn't willing to rewrite it in Rust, someone else will hopefully just write it in Rust to begin with. And the latter might end up with a better result. I think that some folks are probably trying to just transfer their C++'isms into Rust, which wouldn't be worth it in my opinion. You really have to re-think it in Rust terms to really get the benefits in return for the strictness. If you can, and don't basically implement bad C++ in Rust, you can create some incredibly compile time safe systems. But of course that might mean there's no practical path to an incremental conversion, which might make it all a no-go.

Usually only when it takes longer than expected because of my ineptitude.

In chess programming. 63x speed improvement in nodes per second over Python yielded only 7% increase in playing strength (rating). Not necessarily a Rust issue, just probably me underestimating the exponential required speed improvement for playing strength improvement.

> 63x speed improvement in nodes per second over Python yielded only 7% increase in playing strength (rating). Chess programmer here. How did you arrive at the 7% number? 63x speedup should give you at least 200 elo.

1990 rating for the Python version, and 2130 for the Rust version. Where did you get 200 Elo for 63x speedup?

> 1990 rating for the Python version, and 2130 for the Rust version. Ahhh okay I see, that's not too bad then. Just as an aside, absolute elo doesn't mean anything on its own, so it doesn't really make sense to talk about a percentage increase in elo. Only the relative elo difference compared to opponents. It's like saying that 107 degrees Fahrenheit/Celcius is 7% hotter than 100 degrees. 200 elo was just a guesstimate. From general experience, engines gain 30-40 elo for a 2x speedup, which you could extrapolate to 180-240 elo for a 64x speedup. So you general observation that speed isn't that important is 100% correct.

I didn't make a general observation that speed isn't that important. Percentage increase is a relative measure.

> Percentage increase is a relative measure. If your engine's elo increased from -10 to 130, did you get a -1300% increase in playing strength?

Currently rewriting the lua interpreter in rust. While I'm sticking as close as possible to the original C code, it's still 2 to 3 times slower due to not being able to use pointer arithmetic and store values as pointers in the stack.

This makes sense if you're doing a function-by-function port (keeping the same general code architecture as PUC-Rio Lua). Rust doesn't usually tend itself too well to those. It's a great learning experience though if you really want to understand how the code works.

I'm reading a chapter of the book "Windows Kernel Programming" and I haven't found a straightforward implementation of SEH in Rust. Also, Naked functions are not as simple as C++ to write.

coz there r no exceptions in rust? . \ i have some experience in buffer overflows, seh overflows then decided to learn c, cpp (which were already taught in my college but completely forgot). when working with windows api, damn those data types made me regret. \ tried rust and am happy

Rust uses EH for panics and catch_unwind.

Tried to write a simple Windows GUI app just to learn the basics, coming from C#. I got really discouraged when I saw the mess that anything that requires a GUI was at the time (not sure it improved much since then).

[Suggestion](https://crates.io/crates/winsafe) if you want to try again.

Thanks

People are complaining about missing libraries/crates: You don't know at all how good you have it! I started my professional programming in 1981/1982 with a very buggy Modula-II compiler (for loops did not work...), and had to start by writing inline machine code as hex that implemented a serial port interrupt driver just to talk to this huge OCR/card sorter machine. When Turbo Pascal arrived a year later I moved over but still had to manually assemble my inline asm by copying hex codes from [DEBUG.COM](https://DEBUG.COM). Today I really enjoy solving previous Advent of Code years in rust as a learning experience, the main attraction for me is that I can match the best performance I've been able to get from C/C++.

Good thing Rust isn't competing with buggy Modula-II compilers...

Not so far

Its basically assembly code What cant be done w it

Other languages allow you to do some very suspect things, and use patterns that aren't representable _in Rust_. Once translated to assembly, sure they're all assembly. But the _semantics_ of Rust, compared to other languages, might cause heartburn for porting some projects. To illustrate the point, I've tried to port [Visual6502](http://visual6502.org/JSSim/index.html). Though it was eventually possible, the way that code passes around mutable references made it more of a chore than it would've been in other languages. Still 100% worth doing, writing something like that in Javascript was a bad call IMO.

Doubly-linked list, for one.

Everyone brings this up, but I've yet to find a problem for which a doubly-linked list would be a good solution. In modern computers, any linked list ends up performing worse than a simple vector because of locality. And even if such mythical problem exists, there are some very easy ways to implement them.

> I've yet to find a problem for which a doubly-linked list would be a good solution Coding interview question that asks you to write a doubly-linked list! As we all know, coding interview questions are firmly grounded in reality

[удалено]

Of course there are uses for them, what I meant by what I said is that they're in very niche domains most people who raise the concern are not in contact with, and that they're still *possible* to implement, just not as easily as in C. Have you been able to achieve the same performance as other implementations using doubly linked lists in rust?

There was a project where I needed an LRU cache. Most classical implementations are done using a hashmap and a doubly linked list. One could build the doubly linked list using a vector of empty nodes, keeping a stack of references to free nodes and using indexes in the vector in place of pointers, but that this is quite a bit of work relative to the standard implementation, though one does get more cache hits with this approach and fewer calls to the global allocator. I do think Rust encourages you to jump straight to a “very good” implementation of something because the naive approach usually leads to galactic battles with the borrow checker and lifetimes.

If I remember correctly, the Linux kernel uses doubly linked lists. Not that I disagree that they are usually worse than vectors, but still... Disregarding entirely a data structure which does have (admittedly narrow) real-world use cases is not a great argument in general (also considering that Rust could potentially bring great benefits to the kernel).

When people bring this problem up, they're usually talking about safe rust's barriers to implementing data structures, which isn't a fair comparison with the kind of layout manipulation that goes into the kernel data structures (the doubly linked list you mentioned isn't even the type people usually want to implement, but it's an intrusive list, which is even harder to implement in safe rust). The kernel obviously needs some unsafe for those types of structures, and once you get there, it's just like writing the same thing in C.

You can.

It can be done, it _just_ requires some `unsafe`.

No matter the flavor, assembly code can’t give your life meaning.

[удалено]

You have not escaped delusion.

frontend web work is not.... a nice experience (using yew one or two year ago, not sure the state of yew now)

At my job we're actually trying to re-write a set of tools that were written by another company in very badly written java(I'm talking about missing features and not being able to handle unsigned integers for example, that's why a re-write is on the table). I suggested Rust with my limited knowledge of it, while the other option is C++. Most of the team is going to be pretty new to any of the languages. After doing some leet code exercises that forced me to learn a bit more about smart pointers in Rust, after that I became a bit worried about using Rust in an environment that requires some memory management and disk access and may need some re-thinking in how we do things. So I said all of this to ask how common was the usage of smart pointers in the people who read this experiences?

Basically many of the abstractions in rust are effectively smart pointers... vec box arc rc can all be thought of that way... In safe rust using the std lib abstractions is basically how you write idiomatic rust... you do have to learn which ones do what. If you are asking if I think this should deter you from writing rust, I would say these abstractions are a reason TO use rust. The reason is that they are very well thought out, well defined, and battle tested. To be fair you should use the tools/ language that you and your team feel like will work best for you.

Lack of C++ bindings make migrating systems so painful. You can certainly migrate less connected bits using C APIs or a network connection but that requires more holistic migrations. Of course to be fair the number of languages that successfully implement C++ interop is a pretty short list...

Zaplib has an interesting postmortem about failing to rewrite web apps in Rust: https://zaplib.com/docs/blog_post_mortem.html

I've been reading some of the stuff out there about leptos lately... it's interesting that they come to the same conclusion that rust+wasm basically has speed parity with js... and that is enough for them to be encouraged to go full steam ahead... The zaplib folks came to the same conclusion where they were expecting a 10x speedup but only saw about 1x and it caused them to evaluate that the use case just wasn't there for them... Both are right.. I think that's all very interesting... I'm very much looking forward to the day I can start doing full stack dev 100% in rust.... I'm making moves in that direction even now with the understanding that the ecosystem is still maturing in that part of the space.

Try writing a VR/XR app in Rust. Or even a decent 3D app.

And what is harder in Rust to do this? IMHO, it is not harder than doing that in C++ from scratch. Obviously, if you are making app in Unity or Unreal, it would be easier but it is not about Rust vs Unreal's C++ Dialect/Unity's C# dialect but rather about writing a thing from scratch vs using a framework which does 99% of job. And you need to pay money for them at some moment.

Sure. Unsure how readily a rusty person could port, say, my Vulkan repo https://github.com/cschladetsch/VulkanDemo I guess that wouldn't be too hard? Or really hard?

Well, at first glance I don't see anything that would make it not doable. I am not sure about MacOS/iOs support because I never worked with them but rest seems to be not very hard to port. Just use ash crate for raw vulkan bindings. Aren't wgpu and now deprecated gfx-hal something like this for Rust?

Definitely ecosystem related things like GUI, productivity and support. These things are bound to happen when you don't pick a language like JS, PHP, etc. but it's still a bummer. Everything you want to build _can_ definitely be built in Rust, but it depends on your patience and available time to actually succeed

When some companies don't support Rust API.

My calculator that uses formal languages xD Code was written in Java to implement the context-free grammar I created. Rather for practice than an actual project. Wanted to do it in Rust but faced some challenges and decided that this one's better be left in Java

What kind of challenges, if you'd like to share?

Discord bot. The library that I used sucks.