4 ms·

We use GO (with templates) and HTMX for internal apps in enterprise which is completely tied in Microsoft. It’s a much better experience than Blazor. I think th

by devjab 2y ago

We use GO (with templates) and HTMX for internal apps in enterprise which is completely tied in Microsoft. It’s a much better experience than Blazor. I think that any productive language (think what you would likely have used Python for) with templates that can be mixed with HTMX is easily the best experience you’re going to have writing internal enterprise applications. We use GO because we’re slowly replacing our C# and TS backends with GO, but you can achieve the same with many techs. Probably even C# and (ironically) web forms. It obviously has some limitations, and if you need complicated role based access control you’re going to want to use something else. But for 95% of your use cases it’s soooo easy to build an app with JS with server side functionality with HTMX and templates. The major disadvantage is that it introduces multiple frontend techs as you do not want to use it on anything facing customers / investors / whatever on the internet.

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.

by devjab 2y ago

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.