3 ms·

We’re switching into Powershell for operations. With azure automation. We’re switching to Go for concurrency. C and C++ for computation (though to be fair, we

by devjab 3y ago

We’re switching into Powershell for operations. With azure automation. We’re switching to Go for concurrency. C and C++ for computation (though to be fair, we were already doing this with C# and the integration between them has always been great). Our generalist language has become TypeScript however. Not because it’s great technically, but because it lets us share resources better which in term has made us much more productive in meeting our business needs. I don’t think C# is bad, I also think it’s much better today than it used to be. If your use of it remains within what works well I think it’ll be hard to find a language with better tooling, but if your needs go beyond that you’re going to have to fight it a lot.

canadianfella 3y ago
[dead]
pharmakom 3y ago
What does Go offer that C# does not? Both have actors, channels, threads, etc.
- throwaway2990 3y ago
  > What does Go offer that C# does not? Nothing. This often happens when people don’t know .net to begin with. Better they go to go than complain about non existent issues in. .net.
- lenkite 3y ago
  Do C# channels offer lightweight concurrency ? The defining feature of Go is only matched by Erlang/Elixir and now Java. AFAIK C# has nothing like it.
  - neonsunset 3y ago
    C# approach to concurrency has always been better since its introduction. It does have Channels which offer more focused pattern for SPSC, MPMC, etc. scenarios but neither Java nor Go offer a comparable level of ease of use as C#’s hot-started tasks: // The tasks will run in parallel var data = service.GetData(id); var user = service.GetUser(name); Handle(await data, await user); Re: the above comment on switching to Go for concurrency - probably one of the most ill-informed things I have read in the last few days. Doing this borders on incompetence due to the lack of analysis of the utilized technology - Go's GC offers far worse throughput and its concurrency story at best is "on par" with C#.
    - lenkite 3y ago
      There is no async coloring in Go. In the example you cited above, service.GetData can be a plain synchronous function in Go. You don't need to distinguish between sync/async as this is defined by the caller and not by the callee. Any function can be made asynchronous without changing its signature. That's one of the critical advantages of having first-class concurrency. There is no "function coloring". The simplicity of this approach and the advantages this brings to code structuring and easy refactoring simply cannot be understated.
      - neonsunset 3y ago
        Deferring to function coloring terms usually indicates a skill issue of not understanding that types are meant to represent what the code actually does. Task-returning method indicates an asynchronously produced (deferred/delayed) result, a promise. If a language hides this fact (that the returned value needs to be awaited), it is grossly misdesigned - at most it can offer not blocking a thread, completely missing the point and leaving 20 years of improvements other programming languages have on the table. But it's not as bad, yet instead in many other languages you are forced to manually schedule and then block/join until all of your tasks/promises/goroutines finish. Not in C#, that makes it as easy as it gets, which you can see in my example. On top of that, you always pay for concurrency in Go, even when you don't use it, it is by definition always "colored" which further contributes to the overhead. Also, in my example, the tasks will run in parallel. They won't in Go.
        lenkite 3y ago
        > Task-returning method indicates an asynchronously produced (deferred/delayed) result, a promise. If a language hides this fact (that the returned value needs to be awaited), it is grossly misdesigned .. Very hard disagree. This depends on your computing philosophy. Go was designed based on the principles of CSP in mind and that code is produced by humans for humans first. The CSP architecture has proven to work and fit well for high-concurrent middleware. Not just for Go either. You are not forced to block until goroutines finish as you claim. You can do other work or yield to the go scheduler. All the necessary busy work is taken care of by the runtime - which is terrific for folks who don't want to fiddle with low level details. > On top of that, you always pay for concurrency in Go, even when you don't use it, it is by definition always "colored" which further contributes to the overhead. And that is a completely fair compromise. Supporting easy concurrency natively in the runtime was an excellent design tradeoff since the computing world is moving to more and more cores. There are fewer and fewer uses for non-concurrent software. > Also, in my example, the tasks will run in parallel. They won't in Go. You appear to be confusing Go with NodeJS. If you have more than one core and GOMAXPROCS > 1, the tasks can indeed run in parallel.

by devjab 3y ago

canadianfella 3y ago

[dead]

pharmakom 3y ago

What does Go offer that C# does not? Both have actors, channels, threads, etc.

throwaway2990 3y ago
> What does Go offer that C# does not? Nothing. This often happens when people don’t know .net to begin with. Better they go to go than complain about non existent issues in. .net.
lenkite 3y ago
Do C# channels offer lightweight concurrency ? The defining feature of Go is only matched by Erlang/Elixir and now Java. AFAIK C# has nothing like it.
- neonsunset 3y ago
  C# approach to concurrency has always been better since its introduction. It does have Channels which offer more focused pattern for SPSC, MPMC, etc. scenarios but neither Java nor Go offer a comparable level of ease of use as C#’s hot-started tasks: // The tasks will run in parallel var data = service.GetData(id); var user = service.GetUser(name); Handle(await data, await user); Re: the above comment on switching to Go for concurrency - probably one of the most ill-informed things I have read in the last few days. Doing this borders on incompetence due to the lack of analysis of the utilized technology - Go's GC offers far worse throughput and its concurrency story at best is "on par" with C#.
  - lenkite 3y ago
    There is no async coloring in Go. In the example you cited above, service.GetData can be a plain synchronous function in Go. You don't need to distinguish between sync/async as this is defined by the caller and not by the callee. Any function can be made asynchronous without changing its signature. That's one of the critical advantages of having first-class concurrency. There is no "function coloring". The simplicity of this approach and the advantages this brings to code structuring and easy refactoring simply cannot be understated.
    - neonsunset 3y ago
      Deferring to function coloring terms usually indicates a skill issue of not understanding that types are meant to represent what the code actually does. Task-returning method indicates an asynchronously produced (deferred/delayed) result, a promise. If a language hides this fact (that the returned value needs to be awaited), it is grossly misdesigned - at most it can offer not blocking a thread, completely missing the point and leaving 20 years of improvements other programming languages have on the table. But it's not as bad, yet instead in many other languages you are forced to manually schedule and then block/join until all of your tasks/promises/goroutines finish. Not in C#, that makes it as easy as it gets, which you can see in my example. On top of that, you always pay for concurrency in Go, even when you don't use it, it is by definition always "colored" which further contributes to the overhead. Also, in my example, the tasks will run in parallel. They won't in Go.
      - lenkite 3y ago
        > Task-returning method indicates an asynchronously produced (deferred/delayed) result, a promise. If a language hides this fact (that the returned value needs to be awaited), it is grossly misdesigned .. Very hard disagree. This depends on your computing philosophy. Go was designed based on the principles of CSP in mind and that code is produced by humans for humans first. The CSP architecture has proven to work and fit well for high-concurrent middleware. Not just for Go either. You are not forced to block until goroutines finish as you claim. You can do other work or yield to the go scheduler. All the necessary busy work is taken care of by the runtime - which is terrific for folks who don't want to fiddle with low level details. > On top of that, you always pay for concurrency in Go, even when you don't use it, it is by definition always "colored" which further contributes to the overhead. And that is a completely fair compromise. Supporting easy concurrency natively in the runtime was an excellent design tradeoff since the computing world is moving to more and more cores. There are fewer and fewer uses for non-concurrent software. > Also, in my example, the tasks will run in parallel. They won't in Go. You appear to be confusing Go with NodeJS. If you have more than one core and GOMAXPROCS > 1, the tasks can indeed run in parallel.