4 ms·

HTMX with GoLang is such a relief compared to working with anything else in web-related apps. We're still doing a monorepo with NextJs some NX (which is frankl

HTMX with GoLang is such a relief compared to working with anything else in web-related apps. We're still doing a monorepo with NextJs some NX (which is frankly also rather unnecessary since everything it does can be done fairly simply with pnpm workspaces and vite), a complicated storybook setup and 9 billion libraries for components, utilities and what not. We're also still trundling along with C# even though it's 2024 and functions should be capable of living outside of classes in any language... Naturally build on "clean architecture" and "solid" which makes the entire code base a ginormous mess of unnecessary abstractions where a simple helper which does one single thing and is never re-implemented lives in 9 billion files in several different csproj's because it "might" need to be abstracted one day (it won't). It takes me longer to figure out where things are in those projects than it does to develop an entire internal service with HTMX and Go... Which despite being a huge success for everyone, and hailed by the business itself has made no impact on our future plans. We can sit in a meeting where everyone has achieved something marvelous with HTMX and Go and still decide to keep using NextJS and C#. It's silly, but I've never really worked for a company where it wasn't this stupid and at least we're not so trapped by ourselves that we can't build things with "non strategic" tools.

neonsunset 2y ago
If you think that Go is a better choice than C#, you probably spend too much time watching tech influencers on youtube and twitch and too little time programming and getting familiar with the technologies they spread FUD about. Go is inferior to C# in every possible dimension: performance, package management, terseness and expressiveness - Go brings notoriously more boilerplate, Go has poorer ecosystem for writing web applications, worse ORMs and worse tools for troubleshooting advanced issues in production - the list goes on. There are companies that do C# disservice, but you're going to hate to see what they will do with Go instead.
- Quothling 2y ago
  I'm not sure how you feel I attacked C# aside from thinking it had the unnecessary bloat of requiring functions to live in class objects. As far as splitting everything up into 9 billion files and projects it's not something C# really forces you to do. I don't mind dotnet too much, I've worked with it for a decade and it's never been as great to work with as what it's become. I'd never pick it over Go for a new project if I had the choice though. I'm genuinely curious as to why you'd say these things however: > Go has poorer ecosystem for writing web applications For me personally the std http handlers is by far the best experience I've ever had with web development. Though I suspect that you may have worked with Go before the std was enough, and if so your experience was probably a little "tainted" by how the the ecosystem can be a little too "node" like. > worse ORMs and worse tools for troubleshooting advanced issues in production Now this is personal preference but I don't particularly like the rich debugging capabilities of the Microsoft package for C#. Exactly because it's hard to use them in production. Which depends on what sort of production environment you have, but we rely on open telemetry even for our dotnet applications. As far as ORMs go... We operate at a scale where they aren't useable. Entity Framework is quite nice... It's just that the industry has sort of moved beyond the need for ORMs. Even if your teams manage to avoid the lazy loading pitfalls your ORM is eventually going to be more complex than simply working without one. Partly because they weren't really designed for things like an Expand Contract Pattern (which you can implement, but then you're doing more work than simply writing raw SQL), but mainly because LLM's have made it sooooo easy to be both productive and remain control over your data. > Go brings notoriously more boilerplate I can write a struct and a function and then call it on my type in less lines of code than it takes to do the whole namespace... So I'm really not sure what you mean by this. If it's the C# magic which happens behind the scenes I think it's up to your personal opinion whether or not you want the control. As you might have guess from my take on ORM's I prefer the transparency and control.

neonsunset 2y ago

If you think that Go is a better choice than C#, you probably spend too much time watching tech influencers on youtube and twitch and too little time programming and getting familiar with the technologies they spread FUD about. Go is inferior to C# in every possible dimension: performance, package management, terseness and expressiveness - Go brings notoriously more boilerplate, Go has poorer ecosystem for writing web applications, worse ORMs and worse tools for troubleshooting advanced issues in production - the list goes on. There are companies that do C# disservice, but you're going to hate to see what they will do with Go instead.

Quothling 2y ago
I'm not sure how you feel I attacked C# aside from thinking it had the unnecessary bloat of requiring functions to live in class objects. As far as splitting everything up into 9 billion files and projects it's not something C# really forces you to do. I don't mind dotnet too much, I've worked with it for a decade and it's never been as great to work with as what it's become. I'd never pick it over Go for a new project if I had the choice though. I'm genuinely curious as to why you'd say these things however: > Go has poorer ecosystem for writing web applications For me personally the std http handlers is by far the best experience I've ever had with web development. Though I suspect that you may have worked with Go before the std was enough, and if so your experience was probably a little "tainted" by how the the ecosystem can be a little too "node" like. > worse ORMs and worse tools for troubleshooting advanced issues in production Now this is personal preference but I don't particularly like the rich debugging capabilities of the Microsoft package for C#. Exactly because it's hard to use them in production. Which depends on what sort of production environment you have, but we rely on open telemetry even for our dotnet applications. As far as ORMs go... We operate at a scale where they aren't useable. Entity Framework is quite nice... It's just that the industry has sort of moved beyond the need for ORMs. Even if your teams manage to avoid the lazy loading pitfalls your ORM is eventually going to be more complex than simply working without one. Partly because they weren't really designed for things like an Expand Contract Pattern (which you can implement, but then you're doing more work than simply writing raw SQL), but mainly because LLM's have made it sooooo easy to be both productive and remain control over your data. > Go brings notoriously more boilerplate I can write a struct and a function and then call it on my type in less lines of code than it takes to do the whole namespace... So I'm really not sure what you mean by this. If it's the C# magic which happens behind the scenes I think it's up to your personal opinion whether or not you want the control. As you might have guess from my take on ORM's I prefer the transparency and control.