I wrote a small library called keepcalm (https://crates.io/crates/keepcalm) to assist with shared and shared mutable data, which both tend to take a decent amount of effort to get right the first time through.

It turns out that the abstractions are actually performant enough that I never had to remove them from two projects I started using them in.

For most people, a SharedMut or Shared wrapper (or the underlying Arc+Mutex) is sufficient to get you most of the way to prototyping and beyond, based on my experiences.

I agree completely.

This is awesome, it says many of the things I would say, and also gives some great tips that I should adopt ASAP.

A few pieces of feedback:

- embrace rich types. Give everything a type. That way you can let your IDE and compiler do the work for you when you change an API signature. If you have a function foo(usize, usize, usize) and change the signature you'll have to fix things manually. If it's foo(Length, Width, Height) your IDE can probably make your refactor for you, and the compiler won't let you screw it up. (Edit: somehow I managed to miss the section where they make a point very similar to this.)

- This is complementary to "Use Simple Types", not in opposition. Put String in your rich type rather than &str.

- These techniques can be used on modules on different parts of a working production system. You can have a bullet-proof core along with experimental modules still containing prototype code like "unwrap". Package the module in a thread so that the unwrap can't blow up your core, stick it behind a feature flag and ship it to alpha testers while you iterate to full production quality and wide release.

- this is a spectrum, not a binary. After reading this article you think "if I'm going to use what feels like a different language for prototypes than I do for production, why not just use a different language?" then realize that this is a spectrum. The code evolves from "super-prototypy" to "full production" over time, and most code ends up stopping in the middle without ever going all the way to "full production". Part of the rust experience is realizing that clone() is fine in 95% of your code. The "anyhow" error crate is a nice middle ground between unwrap and highly actionable error types and you'll find more of your code using anyhow than using highly actionable error types.

This is what I need because I have given up too many times after reading the rust book and tried to use idiomatic rust.

I made things in Haskell for 10 years before switching to Rust.

Rust and Haskell are excellent for prototyping and enterprise development.

But it comes with a big "if" that the author downplays:

If you like type tetris.

That's an interesting read. I have not yet tried Rust. Most of my experience in this arena is with Go.

I'd be curious to hear if anyone has tried random procedural generation with Rust. That's where I spend most of my hobby coding time.

undefined