4 ms·

As someone who hasn't written C# regularly for over a decade, but has done Go every now and then recently, why would you replace C# with Go? It sounds like it w

by tinco 2y ago

As someone who hasn't written C# regularly for over a decade, but has done Go every now and then recently, why would you replace C# with Go? It sounds like it would be a step down in maintainability with not much advantage.

neonsunset 2y ago
You are about to hear a long tirade how OData is terrible (has little to do with .NET) or some arbitrary reason from this particular HN account. In practice, it’s often management decision and has little value as .NET usually has better tooling like gRPC one.
- devjab 2y ago
  You should get a healthier hobby than stalking me.
ledgerdev 2y ago
Long term c# dev, who's used golang on a few projects. I really want to love go with an htmx+templ, amazing speed and gc, but find it sort of weird/quirky and just plain tedious in use. Linq in c# is so nice, and lots of little c# features(maybe too many) in recent years has made it quite nice for daily use. With aot definitely prefer c# the language over golang. I do sort of loathe aspnet/mvc and especially blazor stuff. We desperately need a better web framework than asp but nothing will ever gain enough traction because of the ms dominance. Microsoft the sprawling corp never fails to disappoint, but damn the .net framework team does do some awesome work. That said, I'm instead putting future efforts into python because let's be honest, uv/fastapi/fasthtml are more than fast enough for nearly every single project I've ever worked on.
devjab 2y ago
We work with solar data, which involves a myriad of data formats and delivery systems. This is mainly because solar inverter engineers didn’t think anyone would put solar inverters directly on the internet. It even said so with big red block letters in one of their manuals. Anyway, basically the entire industry decided to never read the manuals and just put the inverters directly on the internet. Which means we’ve collected data with various services. Especially because it used to be done by different parts of the business, which means some of it is in power apps, some of it is in Python some of it is in C#, some is in Typescript and some is in C. We want to lessen that and GO fits our purpose better than C# because of how async/await has been inherently flawed from its creation. A big part of this is developer based, because of how it was designed it’s just very easy to fuck it up. It’s very leaky and you need to propagate everything, it’s very easy to create deadlocks and you can’t cancel tasks in any meaningful way. On the technical side it’s just terrible for our use case, we’ve cut our Azure cost immensely with go-routines compared to C#. The biggest cost saving has obviously been with power apps, followed by Python but because of the amount of data we handle C# is also very expensive. On the philosophical side of things. We prefer things like explicit error handling and not having to create a class to have a function. So a lot of it isn’t technical, and some of it is.
- neonsunset 2y ago
  Tasks specifically allow to never worry about the kind of race conditions you get with WaitGroups and channels for unary cases - after all, you `await` the result immediately, or later on, and even if you do it multiple times with a Task<T>, it is foolproof and will not allow you to make a synchronization mistake because there is no synchronization to do by the user. They are also cheaper than Goroutines if that's what you want to say: https://gist-github-com.translate.goog/neon-sunset/8fcc31d6853ebcde3b45dc7a2af32127?_x_tr_sl=uk&_x_tr_tl=en&_x_tr_hl=en&_x_tr_pto=wapp#tldr https://gist-github-com.translate.goog/neon-sunset/8fcc31d68... In addition, all meaningfully cancellable operations accept 'CancellationToken' which is way easier than goroutine context passing, some overloads also accept timeout instead if that's expected to be the main use of that. You could make a case about preference for different language syntax and expressiveness, different quality of an SDK from a particular vendor, but the technical arguments made here just do not correspond to reality.
  - devjab 2y ago
    You're not really making a lot of argumentation to back up your claims. Anyone can Search engine benchmarking and get the results they want. Just look here: https://karl-pickett.medium.com/benchmarking-a-toy-c-task-vs-a-go-goroutine-is-there-any-difference-248f73f7f7b7 https://karl-pickett.medium.com/benchmarking-a-toy-c-task-vs... Hell, you can even test things yourself: https://go.dev/src/runtime/stack.go https://go.dev/src/runtime/stack.go For our specific use case C#'s TPL was ok, but it comes with a massive overhead compared to Goroutines. We can have tens of thousands concurrent threads running at the same time at very little CPU usage (which is primarily what we pay for). It’s not that you can’t use async/await tasks to do the same, but they use a lot more CPU and as such is less cost effective for us. As far as blocking and having meaningful (again meaningful is the keyword) cancellation I encourage you to look to Microsoft and understand the limitations outlined by them in the learning articles starting here: https://learn.microsoft.com/en-us/dotnet/csharp/asynchronous-programming/ https://learn.microsoft.com/en-us/dotnet/csharp/asynchronous...
    - neonsunset 2y ago

by tinco 2y ago

neonsunset 2y ago

You are about to hear a long tirade how OData is terrible (has little to do with .NET) or some arbitrary reason from this particular HN account. In practice, it’s often management decision and has little value as .NET usually has better tooling like gRPC one.

devjab 2y ago
You should get a healthier hobby than stalking me.

ledgerdev 2y ago

Long term c# dev, who's used golang on a few projects. I really want to love go with an htmx+templ, amazing speed and gc, but find it sort of weird/quirky and just plain tedious in use. Linq in c# is so nice, and lots of little c# features(maybe too many) in recent years has made it quite nice for daily use. With aot definitely prefer c# the language over golang. I do sort of loathe aspnet/mvc and especially blazor stuff. We desperately need a better web framework than asp but nothing will ever gain enough traction because of the ms dominance. Microsoft the sprawling corp never fails to disappoint, but damn the .net framework team does do some awesome work. That said, I'm instead putting future efforts into python because let's be honest, uv/fastapi/fasthtml are more than fast enough for nearly every single project I've ever worked on.

devjab 2y ago

We work with solar data, which involves a myriad of data formats and delivery systems. This is mainly because solar inverter engineers didn’t think anyone would put solar inverters directly on the internet. It even said so with big red block letters in one of their manuals. Anyway, basically the entire industry decided to never read the manuals and just put the inverters directly on the internet. Which means we’ve collected data with various services. Especially because it used to be done by different parts of the business, which means some of it is in power apps, some of it is in Python some of it is in C#, some is in Typescript and some is in C. We want to lessen that and GO fits our purpose better than C# because of how async/await has been inherently flawed from its creation. A big part of this is developer based, because of how it was designed it’s just very easy to fuck it up. It’s very leaky and you need to propagate everything, it’s very easy to create deadlocks and you can’t cancel tasks in any meaningful way. On the technical side it’s just terrible for our use case, we’ve cut our Azure cost immensely with go-routines compared to C#. The biggest cost saving has obviously been with power apps, followed by Python but because of the amount of data we handle C# is also very expensive. On the philosophical side of things. We prefer things like explicit error handling and not having to create a class to have a function. So a lot of it isn’t technical, and some of it is.

neonsunset 2y ago
Tasks specifically allow to never worry about the kind of race conditions you get with WaitGroups and channels for unary cases - after all, you `await` the result immediately, or later on, and even if you do it multiple times with a Task<T>, it is foolproof and will not allow you to make a synchronization mistake because there is no synchronization to do by the user. They are also cheaper than Goroutines if that's what you want to say: https://gist-github-com.translate.goog/neon-sunset/8fcc31d6853ebcde3b45dc7a2af32127?_x_tr_sl=uk&_x_tr_tl=en&_x_tr_hl=en&_x_tr_pto=wapp#tldr https://gist-github-com.translate.goog/neon-sunset/8fcc31d68... In addition, all meaningfully cancellable operations accept 'CancellationToken' which is way easier than goroutine context passing, some overloads also accept timeout instead if that's expected to be the main use of that. You could make a case about preference for different language syntax and expressiveness, different quality of an SDK from a particular vendor, but the technical arguments made here just do not correspond to reality.
- devjab 2y ago
  You're not really making a lot of argumentation to back up your claims. Anyone can Search engine benchmarking and get the results they want. Just look here: https://karl-pickett.medium.com/benchmarking-a-toy-c-task-vs-a-go-goroutine-is-there-any-difference-248f73f7f7b7 https://karl-pickett.medium.com/benchmarking-a-toy-c-task-vs... Hell, you can even test things yourself: https://go.dev/src/runtime/stack.go https://go.dev/src/runtime/stack.go For our specific use case C#'s TPL was ok, but it comes with a massive overhead compared to Goroutines. We can have tens of thousands concurrent threads running at the same time at very little CPU usage (which is primarily what we pay for). It’s not that you can’t use async/await tasks to do the same, but they use a lot more CPU and as such is less cost effective for us. As far as blocking and having meaningful (again meaningful is the keyword) cancellation I encourage you to look to Microsoft and understand the limitations outlined by them in the learning articles starting here: https://learn.microsoft.com/en-us/dotnet/csharp/asynchronous-programming/ https://learn.microsoft.com/en-us/dotnet/csharp/asynchronous...
  - neonsunset 2y ago