On Thursday, 19 July 2018 at 09:44:16 UTC, Steven Schveighoffer wrote:
> On 7/18/18 1:58 AM, John Carter wrote:

> With web services, most of the time the shared state you want elsewhere anyway (to make it persistent), so it's a better fit for processes than most program domains.

Sharing a _complex_ state to thousand of users is the job for an ACID database.
And that couples very well with separate processes.

If the shared state is trivial, there's a pletora of library that abstract aways the fact that you are sending messages to a process, thread, or corutine: well, it seems that was the goal of std.concurrency, also! :-P

/Paolo

On Tuesday, 3 July 2018 at 03:27:06 UTC, Ali wrote:
> Well, D is not exactly known for contract oriented programming or DbC (Design by Contract)
> we have to thank Bertrand Meyer and his language Eiffel, for that

Thanks for pointing this out !

His book "Object-Oriented Software Construction" is an absolute MUST-READ for any decent programmer.

Contracts, large-scale object-oriented architecture, how to assign responsabilities to the right class, etc.

Even somthing seemingly insignificant as using uppercase typenames is a complete life changer, as this way you can immediately see the role of a single-word identifier just by its case.

That's after reading his book almost three decades ago that I've decided to use the following conventions for my personal code :

- PLAYER : type
- Player : member variable
- player : local variable

Still don't understand why people are still adding silly prefixes or suffixes ("m_", "_", "this->", etc etc) to differentiate local variables from member variables etc :

- Player : type
- player_, _player, m_player, this->player, etc : member variable
- player : local variable

While using the identifier case gets the job done in a simpler and more readable way...

IMO reading this book should be mandatory for any second-year student who is learning professional software development...