No solution, but I have a similar issue with the higher crate.

There the /prelude/src/lib.rs file lets rust-analyzer lose its mind and allocate gigabytes upon gigabytes of memory, even though the file compiles just fine and nearly instantaneous…

I think this has something to do with recursive macros. Doesn’t iced also have such? I have faint memories of a column! macro?

• cargo install is for installing rust programs for your user, not for adding dependencies to your Rust project. Many cargo subcommands can be installed this way, for instance cargo bloat.
• The file you are talking about is called Cargo.toml, because it is the file you need to write in order to configure cargo for your Rust project. TOML is the name of the file format. For details, please see the introductory chapter to Cargo in the Rust book.
• Cargo recently got a new subcommand called cargo add, which allows to add dependencies directly on the command line. However, all it does is to add/edit/remove the respective lines in Cargo.toml. (Personal opinion: I have found it way easier to just edit the file directly than to learn yet another command…)

That said: You still need to edit the Cargo.toml file, even if you solely use cargo add to manage your dependencies. That’s because that file contains a lot more information about your project than just the dependencies. For instance the current version, the feature-flags, your name, a link to the public repo,…

I haven’t done much Rust coding this year yet, mainly because I am trying to learn Lean4 and spent the last couple of months writing a (partially) formally validated (but not very fast) Binary Heap in Lean4.

However, a few days ago I had an inspiration at night, that brought me back to my Rust spare time project: The visual novel engine I had started last year.

For now I only did a relatively small change, but it’s one that will save me a lot of time (and nerves) later on. I am using a Free Monad based embedded Domain Specific Language for writing the game logic. The change now was to wrap that Free Monad in a State Monad Transformer, which I use to store the game state in.

This idea seems to be working surprisingly well, and that has given me enough motivation to return to this project and to keep developing it further for now.

Long and boring explanation with way too much detail:

Sorry for going on a tangent, but there is a Rust-specific detail that makes this cool beyond the usual advantages of using a State Monad Transformer, and I cannot stop myself from sharing.

For composing a large Free Monad, do-notation is more or less a must-have. However, do-notation in Rust only works well with types that implement Copy. If you want to use any other type in do-notation, you can only access variables of it in the following two lines. An attempt to access the data later will lead to an ownership problem (explained here). I have tried to overcome this by adding additional syntax to do-notation, but that is a crutch at best.

So, this is where the State Monad Transformer comes in. It side-steps this problem by moving the state out of the do-notation block into the Free Monad’s Pure-nodes. That way it is readily available via the State Monad Transformer’s get()/put() functions, and the “use within two lines” limitation is not a big issue any more, as one can always get the value on one line, do something with it in the next line, and write the result back on the second line.

I would be very surprised if they wouldn’t fix all 50 filesystems.

In all projects I have worked on (which does not include the Linux kernel) submitting a merge request with changes that don’t compile is an absolute no-go. What happens there is, that the CI pipeline runs, fails, and instead of a code review the person submitting the MR gets a note that their CI run failed, and they should fix it before re-opening the MR.

That’s a very good point. I hadn’t considered potential lack of domain knowledge at all. In that case Rust might even help, because it’s easier to write interfaces that can’t be used wrong - so that even someone without the needed domain knowledge might be able to fix compile issues without breakage.

Behind all the negative tone there is a valid concern though.

If you don’t know Rust, and you want to change internal interfaces on the C side, then you have a problem. If you only change the C code, the Rust code will no longer build.

This now brings an interesting challenge to maintainers: How should they handle such merge requests? Should they accept breakage of the Rust code? If yes, who is then responsible for fixing it?

I personally would just decline such merge requests, but I can see how this might be perceived as a barrier - quite a big barrier if you add the learning cliff of Rust.

Points that I would gladly agree upon - but it seems the Wikipedia authors don’t.

I am not knowledgeable enough to draw a definite line what counts as functional and what doesn’t - so I chose to go with whatever Wikipedia says… Even though I dislike it.

I know, from a mathematics standpoint it does not make sense, but from how the term is used nowadays in programming it does: Those languages allow to compose functions, pass functions as parameters, return functions, etc.

Truth has been spoken.

Except that Kotlin is functional (just like Rust, C++, Visual Basic, JavaScript,…). It is, however, not Pure Functional (like Haskell or Lean4 would be - if you haven’t checked out Lean4, I can recommend it, great fun).

(Sauce: https://en.wikipedia.org/wiki/List_of_programming_languages_by_type#Functional_languages)

And for it to be a worthwhile saving in low memory or storage situations, further constraints need to be met too. For instance, you would need to compile your own standard library, or go fully no-std…

deleted by creator

I am still in the process of customizing my desktop on my new MNT Reform laptop. This includes some work on my status bar tool. I just fixed decibel scaling for the ALSA volume plugin yesterday: https://github.com/soulsource/swaystatus/tree/feature/alsa

I am planning to merge the ALSA plugin to the main branch this week.

Next thing to add is a battery display. Probably using the udev crate, though I am tempted to just use sysfs instead.

Visual Studio Code with rust-analyzer has all the features I would expect from an IDE. I mean, rust-analyzer works together with cargo, so refactoring over file boundaries is not an issue. Visual Studio Code has built-in support for debugging and source control…

That said, I am currently trying to change my workflow to use vim instead of Visual Studio Code, due to my laptop’s small screen size. Rust-analyzer works great in vim too, but I still need to tweak a few things, like how warnings from cargo check are being displayed…

I’m mostly using Rust for a spare time Visual Novel Engine (and Visual Novel) project.

I picked Rust, because I wanted to do something productive with my higher-free-macro crate (which is a tech-demo, but hey, if I have written it, I can just as well use it for something). If you want to get an idea how scripting the VNs in that engine will work, check out the “text adventure” example in higher-free-macro. However, Rust is definitely not an ideal choice for this project. Since performance usually isn’t a concern for visual novels, a higher-level, pure functional language like Haskell or Lean4 would probably have been a better option.

Apart from that I’m using it for many smaller things. For instance I’ve written a small tool for my status bar, swaystatus. (I was not aware that i3status-rust exists when I started working on it, and now I am already committed.) Here I chose Rust mainly because I wanted to learn about Foreign Function Interface in Rust. While I didn’t upload the sources to github until recently, I mostly had been working on this tool several years ago, when I still was a Rust newbie. However, I got back to this project some weeks ago, when I realized that I would like to have an ALSA volume display, which is now in a WIP state on a separte branch.

I’m also using Rust for some out-of-tree prototypes at work. In this case the main reason for choosing Rust is development speed. I’m using Iced.rs to build those prototype GUIs, and Iced is an amazing toolkit. Making a prototype with it is shockingly fast. If I were to do something similar with basically any other GUI toolkit, it would take me significantly longer.

And last, but not least: I’ve published a free app for SailfishOS which is compatible with passwordmaker.org: Passfish, and its underlying library, passwordmaker-rs. Here I chose Rust, because it’s way less error prone than C++ (and let’s better not talk about QML JavaScript). Also, I wanted to show that using Rust for SailfishOS app development is viable, and that it’s actually a quite pleasant experience. (If you want to try passfish, builds are available via the official SailfishOS store, or on OpenRepos).

I second the recommendation to start with The Book. It contains all the necessary information, especially in the chapter about ownership.

Ubuntu was pretty good, until 2010 or so. People who still recommend it probably haven’t used it in the last 10 years.

“PPA” is Ubuntu’s branding for third party repositories. So, of course you will have a hard time adding a Ubuntu-specific third-party repository to anything that isn’t the Ubuntu version it’s made for…

Debian of course supports third party repos, just like Ubuntu. On Debian they just aren’t called “PPA”.

For more information on how to add third party repos to Debian (or Ubuntu, if you don’t use Canonical’s weird tooling), check out the Debian Wiki page on UseThirdParty or SourcesList. There’s also an (incomplete) list of third party repositories on the wiki: Unofficial. And just like with PPAs, anyone can host a Debian repo.

I wouldn’t call Monads a “language feature” of Rust.

There are some types in the standard library that have Monad properties (Option, Result, Vec,…), but there is no Monad trait that would allow to be generic over them.

There have been attempts to introduce such a trait, the most well known probably being the higher crate. However, even with that crate, it’s not easy to work with Monads.

For instance, in the stable tool-chain, it’s currently (to my knowledge) not possible to express a Free Monad without using macros. If you care for the details, I’ve written a blog post about my Adventures with Free Monads and higher. With the Nightly toolchain it is possible to write a generic Free Monad, by the way, thanks to non-lifetime-binders.

Other Monads, like State, Reader and Writer, are also challenging to implement in Rust. I did get them to work, however I failed to implement Applicative for them, so, while they are mathematically Monads, they do not have higher’s Monad trait. Here a possible future improvement of non-lifetime-binders could help. Again, a blog post: Writer and State Monad in Rust, based on higher.

Oh, and last, but not least, do-notation in Rust is a bit inconvenient, because of lifetime rules and lambda captures. For instance, using non-copy types is messy. I’ve added explicit clone support to higher, but that’s a crutch, and overly verbose.

I can only speak out of my own experience, which is mostly C++, C#, C and Rust, but I also know a bit of Haskell, Java, Fortran, PHP, Visual Basic, and, to my deepest regret, also JavaScript.

For additional context: I have been working in game development for the last 7 years, my main language is C++ for Unreal, but I’ve also worked on some Unity projects with C# as main language. Before I switched to game dev I worked in material science, and used C, mostly. I use Rust for my spare time projects, and the game company I work at is planning to introduce it into our Unreal projects some point later this year.

Of all the languages I mentioned above, (Safe) Rust and Haskell are the only ones that have not yet made me scream at my PC, or hit my head against the desk.

So, some of the reasons why I personally love Rust:

• Rust is extremely simple compared to the other languages I mentioned above. If you read the official introduction you know all you need to write Safe Rust code.
• Rust’s syntax is elegant. It’s not as elegant as Haskell, but it’s a lot more elegant than any C-based language.
• Rust is (mostly) type safe. There are (nearly) no implicit conversions.
• Rust is memory-safe, without the runtime overhead that garbage collected languages incur.
  • This is a bit of a neutral point though. The Rust compiler will complain if you make mistakes in memory management. Unlike in managed languages, you still need to do the memory management by hand, and find a working solution for it.
• The memory management model of Rust (“borrow checker”) makes data dependencies explicit. This automatically leads to better architecture that reflects dependencies, because if the architecture doesn’t match them, development will become an uphill battle against the borrow checker.
• Due to the borrow checker, you can use references extensively, and rely on the referenced object to valid, and also that it is up-to-date (because it cannot be muted or go out of scope as long as you hold the reference).
• Traits are an amazing way to abstract over types. Either at zero-cost (static dispatch), or, in the rare cases where it’s needed, using virtual function tables.
• Rust aims to have no undefined behaviour. If it compiles the behaviour of the code is well defined.
  • This, together with the borrow checker, ensures that there are (nearly) no “weird bugs”. Where in C++ one quite regularly hits issues that at first glimpse seem impossible, and only can be explained after several days of research on cppreference (“oh, so the C++ standard says that if this piece of code gets compiled on a full moon on a computer with a blue power LED, it’s undefined behaviour”), that almost never happens in Rust.
• Macros in Rust are amazing. There are macros-by-example that work by pattern-matching, but there are also procedural macros, which are Rust functions that take Rust code as input, and generate Rust code as output. This gives you amazing power, and one of the most impressive examples is the Serde serialization framework, that allows you to add serialization to your data types simply by adding an attribute.
• Tooling for Rust is pretty good. The Rust compiler is well known for its helpful error messages. The rust-analyzer plugin for Visual Studio Code is great too. (It also works with vim, Qt Creator and others, but the but Visual Studio Code works best imho.)

The points mentioned above mostly apply to Safe Rust though. Unsafe Rust is a different story.

This brings us to the downsides. Rust isn’t perfect. Far from it, actually. Here are some of the things that aren’t great about Rust.

• No Higher Kinded Types. This is my main issue with Rust. Even C++ has them (as usual for C++ in a horrible un-ergonomic and utterly confusing way). If Rust had Higher Kinded Types, the language could have been simpler still. For instance, there would have been no need for the async keyword in the language itself.
• Unsafe Rust is hard. In my opinion even harder than C++, because of Rust’s aliasing rules. Unlike C++, Rust doesn’t allow mutable memory aliasing. That’s because mutable aliasing can never happen in Safe Rust, and not supporting it improves performance. This means that when writing Unsafe Rust, one has to be careful about aliasing.
  • Luckily one only rarely needs Unsafe Rust, usually only in order to call functions from other languages. Still, it’s hard, and I’d generally suggest to use an automated code generator like cxx.rs for interfacing with other languages.
• Interior Mutability. I understand why it exists, but it breaks a lot of the guarantees that make Rust a great language. So, my conclusion is that one should avoid it as much as possible.

However, the upsides clearly outweigh the downsides imho.

tl;dr If a (Safe) Rust program compiles, chances are pretty high that it also works. This makes programming with it quite enjoyable.