3 ms·

I would say it works as long as you don't need any major coordination outside of a few channels. As soon as you get into mutex territory you happily end up shoo

I would say it works as long as you don't need any major coordination outside of a few channels. As soon as you get into mutex territory you happily end up shooting yourself in the foot hoping that go test -race caught the bug someone else introduced. Or you spend unnecessary time implementing some concurrent safe type trying to hide the synchronization behind a pretty interface. At work we have a split code base between rust and go, using go to interface with the world due to better ecosystem while using rust for the heavy lifting of business logic in an extremely concurrent implementation. Even though the rust side is more complex it is much easier to work with and refactor leading to fewer bugs. The language simply gives so much for free, when you get over the first humps of a slow start. The Rust cycle of 1. make it work, 2. handle errors, 3. encode invariants in the type system to prevent inadvertent refactors is simply magical.

dotancohen 5y ago
> The language simply gives so much for free Are we familiar with the same Rust? Though I've only looked at it briefly about two years ago (beginning of pandemic), I don't remember getting much "free" with the language. Especially not coming from a "batteries included" Python background. I would honestly love to know what you feel that Rust provides out of the box. I'm very likely to use it in the future and such a head start may be valuable. > The Rust cycle of 1. make it work, 2. handle errors, 3. encode invariants in the type system to prevent inadvertent refactors is simply magical. Isn't that the workflow of any minimum viable product development paradigm?
- Gwypaas 5y ago
  I think we are looking at it with two different views of "free". It is not batteries included outside of synchronization, string operations, collections and iterators. We are using the Tokio ecosystem which has some nice batteries included. My view of "free" in the comment is correctness. Concurrent code simply keeps on working through refactors to suit the business needs. Most of the time the tests pass the first time the code compiles again after a refactor of core pieces. That is something I haven't experienced in any other language. I simply do not feel scared touching, changing or removing anything to get the most lean code base possible. Compare this to Python where I want to have the mental model of the entire "world" for every change I do and then simply hope that the tests will catch any errors. Go is better when kept simple, but still a lot of implicitness and conventions leading to easy shooting yourself in the foot. > Isn't that the workflow of any minimum viable product development paradigm? Definitely, Rust simply gives more tools for it. For example through sum types and traits to enforce invariants. Say comparing to the awful iota hacks to get "enums" in Go, accidentally having a meaningful default value or run time verification because somewhere you ended up with an interface{}. In rust for the "make it work stage" simply throw expects everywhere and choose to panic on errors, or just bubble to the top without caring. It never silently simply works unless you've explicitly chosen how to deal with the possibilities which is very reassuring. Go has some of that feel, but actually doing something useful with errors more than logging I have never seen a good paradigm for yet. Errors as/is kind of works but still puts most of the work on the user to figure out the correct thing. Maybe I haven't dove deep enough though. For some info on how far you can take error handling in Rust forcing correctness on the users see this blog post from Sled (an embedded KV database) http://sled.rs/errors.html http://sled.rs/errors.html
  - dotancohen 5y ago
    Thanks, I've yet heard of Tokio, I'll save that and the Sled article in my rust.org file. Interestingly, the example code on the Tokio github page use the antipattern described in the Sled article, regarding the try operator.

dotancohen 5y ago

> The language simply gives so much for free Are we familiar with the same Rust? Though I've only looked at it briefly about two years ago (beginning of pandemic), I don't remember getting much "free" with the language. Especially not coming from a "batteries included" Python background. I would honestly love to know what you feel that Rust provides out of the box. I'm very likely to use it in the future and such a head start may be valuable. > The Rust cycle of 1. make it work, 2. handle errors, 3. encode invariants in the type system to prevent inadvertent refactors is simply magical. Isn't that the workflow of any minimum viable product development paradigm?

Gwypaas 5y ago
I think we are looking at it with two different views of "free". It is not batteries included outside of synchronization, string operations, collections and iterators. We are using the Tokio ecosystem which has some nice batteries included. My view of "free" in the comment is correctness. Concurrent code simply keeps on working through refactors to suit the business needs. Most of the time the tests pass the first time the code compiles again after a refactor of core pieces. That is something I haven't experienced in any other language. I simply do not feel scared touching, changing or removing anything to get the most lean code base possible. Compare this to Python where I want to have the mental model of the entire "world" for every change I do and then simply hope that the tests will catch any errors. Go is better when kept simple, but still a lot of implicitness and conventions leading to easy shooting yourself in the foot. > Isn't that the workflow of any minimum viable product development paradigm? Definitely, Rust simply gives more tools for it. For example through sum types and traits to enforce invariants. Say comparing to the awful iota hacks to get "enums" in Go, accidentally having a meaningful default value or run time verification because somewhere you ended up with an interface{}. In rust for the "make it work stage" simply throw expects everywhere and choose to panic on errors, or just bubble to the top without caring. It never silently simply works unless you've explicitly chosen how to deal with the possibilities which is very reassuring. Go has some of that feel, but actually doing something useful with errors more than logging I have never seen a good paradigm for yet. Errors as/is kind of works but still puts most of the work on the user to figure out the correct thing. Maybe I haven't dove deep enough though. For some info on how far you can take error handling in Rust forcing correctness on the users see this blog post from Sled (an embedded KV database) http://sled.rs/errors.html http://sled.rs/errors.html
- dotancohen 5y ago
  Thanks, I've yet heard of Tokio, I'll save that and the Sled article in my rust.org file. Interestingly, the example code on the Tokio github page use the antipattern described in the Sled article, regarding the try operator.