3 ms·

Your example is not concurrency though, it’s parallelism. You’re consuming two different services at the same time and waiting for the result. What you would wa

by devjab 3y ago

Your example is not concurrency though, it’s parallelism. You’re consuming two different services at the same time and waiting for the result. What you would want to showcase is how you handle two different consumers calling a single service. The difference is rather important once you have many consumers calling a lot of services and your computation needs to be done on the right state. As a side note I really don’t think C# does parallelism better than Java.

neonsunset 3y ago
It is both, please do not misconstrue this. If two callers call the same method concurrently, whether it requires any synchronization or a more advanced primitive like Channel (for which C# has well-written implementation) or nothing at all is a case-by-case choice. Java's parallelism by definition cannot be better because they had to retrofit a green threads design onto existing ecosystem, only ever addressing the hardware thread blocking issue with all the ceremony and bloat to do the most basic actions concurrently and/or in parallel still remaining in place. Java requires far more steps to achieve comparable behavior for what C# requires you doing nothing or a method call at most. Dispatching array elements to a consumer in parallel? call .AsParallel(), and no, Java's Stream API requires more work. Want to fire off two asynchronously completing methods? Just use the example above, neither Java nor Go can hold a candle to this. Methods are CPU-bound and blocking? Easy - just use Task.Run to achieve the same.
- devjab 3y ago
  > It is both, please do not misconstrue this. I’m sorry, but it’s really not the same thing. You appear very confident, and sort of rude, in your argumentation, but there is just such a huge difference between parallelism and concurrency I don’t even know where to begin. I mean, you’re talking about (a)synchronous calls, tasks, and, what not, but what you need to solve is when two thousand sensors want to update the same data through the same service all at once. And they want to do this fairly often. In reality it’s even more complex than this because a lot of the sensors carry data on behalf of each other so often you’ll receive the same data multiple times and so on, but there isn’t much need to get into that. But hey, you do you, if C# works for you, great.
  - deleted 3y ago
    [deleted]

by devjab 3y ago

neonsunset 3y ago

It is both, please do not misconstrue this. If two callers call the same method concurrently, whether it requires any synchronization or a more advanced primitive like Channel (for which C# has well-written implementation) or nothing at all is a case-by-case choice. Java's parallelism by definition cannot be better because they had to retrofit a green threads design onto existing ecosystem, only ever addressing the hardware thread blocking issue with all the ceremony and bloat to do the most basic actions concurrently and/or in parallel still remaining in place. Java requires far more steps to achieve comparable behavior for what C# requires you doing nothing or a method call at most. Dispatching array elements to a consumer in parallel? call .AsParallel(), and no, Java's Stream API requires more work. Want to fire off two asynchronously completing methods? Just use the example above, neither Java nor Go can hold a candle to this. Methods are CPU-bound and blocking? Easy - just use Task.Run to achieve the same.

devjab 3y ago
> It is both, please do not misconstrue this. I’m sorry, but it’s really not the same thing. You appear very confident, and sort of rude, in your argumentation, but there is just such a huge difference between parallelism and concurrency I don’t even know where to begin. I mean, you’re talking about (a)synchronous calls, tasks, and, what not, but what you need to solve is when two thousand sensors want to update the same data through the same service all at once. And they want to do this fairly often. In reality it’s even more complex than this because a lot of the sensors carry data on behalf of each other so often you’ll receive the same data multiple times and so on, but there isn’t much need to get into that. But hey, you do you, if C# works for you, great.
- deleted 3y ago
  [deleted]