Hacker News Reader

Comment by GodelNumbering | Hacker News Reader

I haven't used Rust extensively but my feeling is, if you change the design (which inevitably happens in many early stage projects), the refactoring takes more time due to borrow-checker semantics. Although I am far from a representative sample and could well have been using it wrong

View on HN

When you write Rust long enough you settle on certain architectures (message passing, event loops) that go well with the borrow checker, and don't end up thinking about it too much. Plus you can always throw an agent at the first set of errors from the refactor and let the compiler guide the annoying parts.

> When you write Rust long enough you settle on certain architectures (message passing, event loops) that go well with the borrow checker

So basically Go?

Go only provides one concurrency paradigm. Rust support many (if not all).

The type system of Go is very weak. I'd say that'd be my main reason to pass on Go, even when the concurrency paradigm fits the project perfectly.

The biggest reason to pass on Go right now (if your software can tolerate a runtime) is the lack of algebraic data types when doing interesting domain modeling. It makes such a huge difference it’s worth tolerating the pain points of Rust (or Swift, or F#) just to have them.

Traits, Enums, and Typestate allow much richer paradigms at much lower cost

Its just not a thing to consider and doesn't happen often.

Reply on news.ycombinator.com