arendjr

@solardirus @SorteKanin Maybe Go is easier to read in a word-for-word sense, but when I read a program, I want to understand what it does and why it works the way it works. I want to validate its properties to build a mental model of how pieces interact.

As soon as I start doing that I find Rust is much easier to reason about, because the compiler enforces a lot of properties that I rely on, whereas with Go I end up looking through multiple files to get the same picture.

@jenesaisquoi @Ordoviz It’s a gray area, legally. What you say is theoretically correct, but there’s practical issues once you’ve looked at the code that will open you up to legal liability anyway.

For instance, what if you need a utility function during your reimplementation for which there is really only one obvious implementation? You can no longer claim to have come up with it by yourself.

I doubt the FSF would sue over it, but companies are known to avoid the risk.

@somedev @netwren I wrote an older article about implementing Redux reducers in Rust: https://fiberplane.com/blog/writing-redux-reducers-in-rust

For us, the use case was migrating existing Redux reducers written in TypeScript to Rust for code reuse (and later, performance) reasons. We didn’t need to rebuild Redux itself though, since our Rust reducers could still be invoked from the TypeScript side of things.