3 ms·

These points are absolutely consistent with my experience. I'd also dispute the author's claim that, "If the language has the problem that people are fighting w

These points are absolutely consistent with my experience. I'd also dispute the author's claim that, "If the language has the problem that people are fighting with the language in order to become productive with it, perhaps something is wrong with the language, and not the programmers?" And I would argue that this is an ill-placed criticism: it doesn't mean something is "wrong" with either the language or the programmers: instead, it just means that it's a technology that has a learning curve. I also had early awkward periods of low productivity when I first started learning how to touch-type: that doesn't mean that something is wrong with keyboards!

kenhwang 8y ago
I found out that 90% of the time, I'm more at fault than the borrow checker because I'm writing code that would be unsafe should concurrency/parallelism be introduced. But a lot of people don't naturally write or even know how to write concurrency safe code, especially when there's no intention for the code being parallelized.
- sargun 8y ago
  I'm not arguing the borrow checker is wrong, I'm just saying, rather than being the Star Ship: Enterprise's computer, and asking me to put up shields, I want the language to put up the shields for me. Yes, they might result in a power drain, but 99% of the time, I don't want to get shot, at the expense of power. Just treat things as immutable, and copy them around, or automagically allow for wrapping / unwrapping a (Ref)Cell/(A)rc
  - andolanra 8y ago
    Rust is designed to make it easy and safe to build the 1% of your application that cares strongly about resource usage, because for certain application domains (like low-level server software or operating systems) that section might make up more like 10% or even 100% of your application. In those situations, Rust can provide a lot of advantages that a less strict tool might not be able to provide. It sounds to me like the design philosophy that informs Rust is different from the design philosophy you'd prefer, and that's okay! That means Rust might not be a compelling fit for your problems, but not every tool is going to fit every problem domain. That doesn't mean the tool is broken, just that it's designed for a different situation.

kenhwang 8y ago

I found out that 90% of the time, I'm more at fault than the borrow checker because I'm writing code that would be unsafe should concurrency/parallelism be introduced. But a lot of people don't naturally write or even know how to write concurrency safe code, especially when there's no intention for the code being parallelized.

sargun 8y ago
I'm not arguing the borrow checker is wrong, I'm just saying, rather than being the Star Ship: Enterprise's computer, and asking me to put up shields, I want the language to put up the shields for me. Yes, they might result in a power drain, but 99% of the time, I don't want to get shot, at the expense of power. Just treat things as immutable, and copy them around, or automagically allow for wrapping / unwrapping a (Ref)Cell/(A)rc
- andolanra 8y ago
  Rust is designed to make it easy and safe to build the 1% of your application that cares strongly about resource usage, because for certain application domains (like low-level server software or operating systems) that section might make up more like 10% or even 100% of your application. In those situations, Rust can provide a lot of advantages that a less strict tool might not be able to provide. It sounds to me like the design philosophy that informs Rust is different from the design philosophy you'd prefer, and that's okay! That means Rust might not be a compelling fit for your problems, but not every tool is going to fit every problem domain. That doesn't mean the tool is broken, just that it's designed for a different situation.