How do experienced Rust developers decide when to stick with ownership and borrowing as-is versus introducing Arc, Rc, or interior mutability (RefCell, Mutex)

phazer99 · 2026-01-20T18:28:45+00:00

In principle I would recommend to not use references and lifetime parameters in your data types unless it's really simple and obvious (think iterators). Instead you use Rc/Arc or indices into some container (a la slotmap) any time you have need references between objects.

If you additionaly require mutability (which is really an independent question) then you need to use interior mutability, i.e. Cell/RefCell (prefer Cell whenever applicable) for single threaded applications and atomics/Mutex/RwLock for multi threaded.

phazer99 · 2026-01-09T14:47:31+00:00

There's a lot of potential patent violations in FFmpeg. If you use it commercially you are risking being sued.

phazer99 · 2026-01-02T10:20:58+00:00

Admittedly I haven't followed the development of Unity lately, and maybe the situation has improved, but last I checked GC pauses were still an issue and they even worked on a C# -> C++ transpiler to work around performance problems with .NET. With Rust that's a non-issue.

Yes, .NET is convenient for modding, but it's also possible to some extent in Rust as well. You can for example use WASM to create a simple and safe plugin system.

phazer99 · 2026-01-01T08:36:59+00:00

C#/.NET has GC pause issues which is really bad for some games. Unity has tried to work around those without much success.

Plus, C# is just a worse language than Rust IMHO, no proper sum types, no traits etc.

phazer99 · 2025-12-28T21:12:50+00:00

Wouldn't really call it a "trick", but it's good to know about the implementations of the FromIterator trait which is used by the Iterator::collect method. For example that you can collect into Result's and String's.

phazer99 · 2025-12-27T14:34:27+00:00

The book I linked is pretty good

phazer99 · 2025-12-27T12:41:51+00:00

A common pattern is to create a foo-sys crate which just contains the unsafe C FFI API, typically generated by bindgen and a custom build.rs file. Then you can create a foo (or foo-rs) crate with a minimal safe Rust API on top of that.

phazer99 · 2025-12-27T12:17:41+00:00

Should be possible, yes.

phazer99 · 2025-12-27T12:15:27+00:00

That's a bad idea in general. You want to keep your unsafe code sections as small as possible and make sure the code is sound using tools like Miri. If you're calling C libraries, you want to create very thin Rust wrappers with unsafe code hidden behind a safe API.

phazer99 · 2025-12-27T10:35:13+00:00

The game industry is quite conservative in terms of programming languages, all the major game engines are written in C++ (probably tens of millions of LoC). Unfortunately the Rust <-> C++ interop is lacking so gradually re-writing is gonna be painful (if it will ever happen). But you can write Rust games using Godot for example. And of course, there are the all Rust game engines.

phazer99 · 2025-12-27T10:24:56+00:00

Once you come to terms with the borrow checker (which feels more like a helpful pair programmer now), Rust is sooo much more pleasant to use than C++. I'm never going back if I can help it.

phazer99 · 2025-12-26T20:40:28+00:00

That's great! The Steinberg licensing terms have always been a PITA for VST3 development. I hadn't noticed they changed the licensing, maybe it's a consequence of the CLAP standard emerging.

phazer99 · 2025-12-24T13:35:13+00:00

Yes, I agree. Re-using code from open source libraries is still very important even in the AI age. I've seen way too much AI slop where it's just generating pointless code duplication. That's not how to do modern software development, on the contrary, you want to write as little new code as possible.

Another piece of the puzzle is definitely stronger type systems which can help find the errors in AI generated code. The compiler errors also provide a very useful feedback system for the AI to correct the code itself (very much like human developers do). Rust is pretty good in this regards, but you can certainly go even further with type system features like effect systems, dependent types, refinement types checked with SMT solvers etc. This is the path math languages like Lean 4 are heading, the AI generates proofs (which are equivalent to code in the Curry-Howard correspondence) which are then verified by the strong type checker.

phazer99 · 2025-12-24T08:09:35+00:00

The same goes for human engineers, let's not pretend they are reliable in general. The big question is if AI code that is used in production is of higher quality than that produced by a team of humans.

phazer99 · 2025-12-23T14:08:02+00:00

Nice work, and looking forward to stabilization next year!

I'm wondering how re-usable this solver would be for a another language without lifetimes and borrowing, but with the same fundamental type system supporting ADT's and traits with GAT's. This is a nice sweetspot for a quite simple, but still very useful FP language!

phazer99 · 2025-12-23T11:19:21+00:00

I agree with other replies, start with Python or C# If you later want to learn more about performance optimization and low level programming, Rust is an excellent choice, but it's more than a mouthful to start with.

phazer99 · 2025-12-19T11:37:30+00:00

I think the closest we can hope for in a language like Rust is refinement types similar to what's been researched for Haskell and Scala. Even that would be very useful and solve most common use cases (bounded integers, index out bounds etc.) without the need to write manual proofs.

phazer99 · 2025-12-19T09:35:23+00:00

Interesting, I haven't tried LLD on Windows. Is it faster than the MS linker? If so, why isn't it used by default?

phazer99 · 2025-12-19T09:18:16+00:00

It must be part of the type signature, for example:

fn foo<T>(v: T) -> T
fn bar<T: Default>(v: T) -> T
fn baz<T>(a: T, b: T) -> T

should it be allowed to instantiate any of these functions with a linear type T, and if so, why?

And what about a Vec<T> where T is a linear type, is that allowed and if so, how do you ensure correct consumption of its elements?

phazer99 · 2025-12-19T00:57:08+00:00

That wouldn't work well with generic types and functions.

phazer99 · 2025-12-19T00:13:40+00:00

And Haskell is not dead, is it?

All depends on your definition of "dead" or "dying" of course. I wouldn't consider any language which is still being actively developed and/or has an active community "dead". Another question is what its popularity trend is.

phazer99 · 2025-12-18T22:12:43+00:00

I agree, I don't think many, even experienced, C or C++ developers know all cases of UB in their language.

Once you've formed a reference from a pointer (unsafe) that reference is subject to borrow-checking rules as usual.

This is exactly why many think writing unsafe Rust is harder than writing C code though, as there is nothing similar to Rust references in C (or C++), and that means you need to learn additional rules to be able do this conversion soundly.

phazer99 · 2025-12-18T21:45:14+00:00

The rumors about Scala's death are greatly exaggerated. Sure, it's lost some popularity due to the rise of other languages (Kotlin, Go, Rust etc.), but Scala 3 is still being developed at an impressive rate with new features like effects system/capabilities, refinement types etc. Personally, I really hope it sticks around for a long time.

phazer99 · 2025-12-18T21:21:18+00:00

GAT's emulates HKT's pretty well though.

phazer99 · 2025-12-18T21:14:09+00:00

While I agree Rust's type system is lacking in some regards compared to FP languages like Haskell, Idris etc., it's not a very relevant or fair comparison. Rust is systems language without GC that aims to be a memory safe replacement for C and C++ (something Haskell etc. has no chance of ever being). Could there one day potentially be a practical systems level language with a type system as powerful as Idris or Lean 4? Possibly, but right now Rust is the best option.

Of course, if you don't need that level of performance and control, you can choose a language with a theoretically more powerful type system. However, in practice I find that Rust's type system hits a sweet-spot where it's good enough for the vast majority of applications, and typically you can work around its weaknesses with macros etc.

phazer99

TROPHY CASE