3 ms·

Rubbish! You could make the same argument for parallelising, abstraction, logging, and just about every other feature. But then you’d never build anything becau

Rubbish! You could make the same argument for parallelising, abstraction, logging, and just about every other feature. But then you’d never build anything because there are infinite possible features you could include. Build only what you need today, and prepare for what your employer says you will need tomorrow. Anything else is like saying everybody should buy a jeep in case they move to the countryside. Async brings its own costs. Unless your employer benefits, you are costing them money by giving them features they don’t need.

cryptonector 9y ago
You have to think at least a bit ahead. Better to write thread-safe async code from day 1 than to rewrite later.
- blowski 9y ago
  YAGNI - https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it I’ve worked with plenty of valuable apps not using async. If the requirements change such that async becomes the best way to solve the problem, that’s something the business would decide at that point.
  - cryptonector 9y ago
    Sometimes you can think ahead and see the need coming -- or not coming -- and act accordingly. Experience is helpful here. When I have to write C I try to at least write thread-safe C close to something I could expose as a library. I've had too many cases where I or someone else wrote code they NEVER thought would be needed as a library, therefore took all sorts of liberties, and then suddenly there was a need for a library to do what said code was doing. Oops. I've run into fewer instances of sync code that turns out should really have been async and where adding threads isn't good enough, but I've still run into some. This isn't about functionality -- this is about scalability. When you know you need to scale, you have to think ahead about it.
    - blowski 9y ago
      A lot of projects are little more than crud with a few complicated business rules. Use a framework with a good caching layer, and a lot of the time the employer is very happy with the outcome. It’s cheap to build, maintain, and host. But then along comes a developer who says “we must build this app with async so we can scale”. Suddenly the junior devs build an absolute mess because they don’t know how to work effectively with async. So a few seniors get involved. Then the project runs out of cash. Sure, some projects benefit from async and some fundamentally require it. But not all of them, I doubt even the vast majority of them. You only need to scale when you’re successful, and most applications are not successful.

cryptonector 9y ago

You have to think at least a bit ahead. Better to write thread-safe async code from day 1 than to rewrite later.

blowski 9y ago
YAGNI - https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it I’ve worked with plenty of valuable apps not using async. If the requirements change such that async becomes the best way to solve the problem, that’s something the business would decide at that point.
- cryptonector 9y ago
  Sometimes you can think ahead and see the need coming -- or not coming -- and act accordingly. Experience is helpful here. When I have to write C I try to at least write thread-safe C close to something I could expose as a library. I've had too many cases where I or someone else wrote code they NEVER thought would be needed as a library, therefore took all sorts of liberties, and then suddenly there was a need for a library to do what said code was doing. Oops. I've run into fewer instances of sync code that turns out should really have been async and where adding threads isn't good enough, but I've still run into some. This isn't about functionality -- this is about scalability. When you know you need to scale, you have to think ahead about it.
  - blowski 9y ago
    A lot of projects are little more than crud with a few complicated business rules. Use a framework with a good caching layer, and a lot of the time the employer is very happy with the outcome. It’s cheap to build, maintain, and host. But then along comes a developer who says “we must build this app with async so we can scale”. Suddenly the junior devs build an absolute mess because they don’t know how to work effectively with async. So a few seniors get involved. Then the project runs out of cash. Sure, some projects benefit from async and some fundamentally require it. But not all of them, I doubt even the vast majority of them. You only need to scale when you’re successful, and most applications are not successful.