3 ms·

And in Go, it's inferred and you don't have to bother repeating yourself.

• tialaramex 4y ago
  Rust deliberately chooses not to infer the return type in a function signature. Inferring return types is convenient for the person writing the function, but adds cognitive overhead for people using the function and makes it easier to introduce incompatible changes without realising (the signature you wrote is unchanged but a different signature is now inferred)
  • gabereiser 4y ago
    Not arguing that. Indeed forcing type signatures helps the reader at the expense of the writer (who has the burden of documentation? S/He who writes the types). I’m saying, to a person with less skills than I, it’s an almost insurmountable undertaking to learn Rust while Go at least seems somewhat familiar. They aren’t teaching these in universities I visit so new engineers might have a tough time grokking the syntax. I prefer Go for two reasons. 1) It’s faster for me to get my idea across (this is my personal hurtle) and 2) Go’s concurrency model. What I would like to try in Rust: rewriting my game engine. Building a hobby OS. Building a hobby programming language. These are areas where Go isn’t the best tool.
• candiodari 4y ago
  The return type might be inferred, but you're definitely supposed to remember locks. Nothing in the language will prevent you from accessing a protected resource without locking the lock. In Rust that can be made impossible.
  • gabereiser 4y ago
    Making a locking thread safe slice or map is as easy at creating a struct with two fields and three member functions… then you can access it and it will lock itself and unlock itself.