I've discovered a similar pattern, when I look at successful projects in my past. I prioritize "working", then "solid", then "fast" where it's needed.

Ironically, it's this principle that makes me look to non-Rust languages; I find that Rust's borrow checker forces us into faster but less flexible patterns up-front, and incurs a lot of refactoring friction later.

It's because of this that I'm interested in the PL space, and excited about upcoming languages like Lobster and Cone.

That's just.. not how Rust works. I assume that after being frustrated by the Rust borrow checker, you chose to use easy to write wrappers like `Arc` and `RefCell`. I think it is something that beginners often do.

I wouldn't rewrite my project to some other language before I know how it is going to look like in the language. I had to be somewhat confident. If you find yourself frustrated by Rust's borrow checker, that tells me that you are not yet ready to port a project to Rust. You don't have the "Rust mindset" yet.

You make a lot of assumptions, and dismiss my valid opinion as uninformed. I would say that's arrogant and offensive, but I'm sure you meant well.

More to the point, in my many years of experience with Rust, I've found that if you're working on a stateless project, or a small project, or have a very clear picture up-front, you can know what data you will need to centralize and split ahead of time, and things will go smoothly. However, that's rarely the case in the parts of industry I've been in, where we need to prototype, refactor, and build out our programs constantly. In these cases, Rust is slower to work with compared to other languages, because the borrow checker makes our APIs brittle, causing refactors' blast radius to increase.

I'd be curious to hear if your architecture experience with large Rust projects might be different, I'm always open to more data points.

>make it good

Wait, when did that happen?

Even "make it work" is debatable.

I'd say when ES6 landed. I used to hate JS, but since ES6, I think it's a pretty good language for building frontends.

ES6 is indeed pretty good, all things considered, but GP specified javascript tooling, which, uh, could still use some work before it's considered truly "good".

I'd say ES5 made it work and ES6+ made it good. I think by the time the Pattern Matching, and Record & Tuple proposals are completed and implemented it'll go to fast.

to be fair they didn't say it has completed the progression through that program.

This got a genuine laugh from me. Stockholm syndrome is a prerequisite for writing JS

I like how you've followed the delusional -> delusional pattern.