3 ms·

Go is designed to do concurrency via message passing, not shared memory. Yes, this is slower, but it also means you don't need a fancy borrow checker slowing do

• perfmode 7y ago
  instead you pay for context switches in the scheduler and suffer an order of magnitude slowdown in production. and when you profile and find the performance issue, you rewrite the portion of code to use mutexed shared memory to hit your performance targets.
• nazka 7y ago
  Let me rephrase. Go was designed with the old best practice to share data of languages before Rust came: “you do not communicate by sharing memory, instead you share memory by communicating”. It is slower but you have to do this because Go can’t guaranty memory safety and doesn’t have system to prove that at compile time. Then the team behind Rust after many research found that you can actually guaranty memory safety if you can track how data are used by each thread. To do this you need to track how each value is used and borrowed by each thread to insure memory safety. And so the borrow checker was born. It gives you the best of both world: speed And safety while adding only a little bit of time to the program to compile. If Rust is slow to compile it’s not because of the borrow checker it only adds a little bit to the bottom line, but it’s because of Generics and other things. Which is also something that Go is lacking and doesn’t have yet.
• piano 7y ago
  > Go is designed to do concurrency via message passing, not shared memory. ... and yet experienced gophers will criticize newcomer's code for using channels too much and they will tell you you need to use traditional stupid shared memory approach instead of channels in many cases.