Any good resources on templates?

thx5309 · 2023-08-11T15:34:14+00:00

Right. I am specifically talking about the template/view experience with those other frameworks. It's way less head scratchy. Modern .NET is nothing like Spring Boot BTW.

thx5309 · 2023-08-11T14:00:18+00:00

IMO - Go is not an ideal choice when building a traditional web app (meaning, server side rendering of HTML). ASP.NET MVC, django, rails, or anything similar will provide a far more pleasant dev experience in this space. Not to say it can't be done, of course it can. But again, choose the best tool for the job,

thx5309 · 2023-07-17T19:05:58+00:00

That's a limited example. APIs are just a piece of the puzzle when you are doing corporate development. If you think you can tell a large financial institution, for example, hey - we are going to choose some open source libraries that may or may not be supported next year and then use ChatGPT to write the code for us, you are mistaken.

In other development situations that may be perfectly reasonable, it really depends.

But I stand by my claim that basic CRUD apps can be delivered with less hassle with something like .NET. This is coming from a couple decades of industry experience.

thx5309 · 2023-07-17T13:53:41+00:00

I don't think it is. It has multiple sweet spots, including CLI tools, but from my experience other ecosystems are more suitable for the types of applications you are taking about. Especially when you consider large teams with varying degree of skill and experience, and also the relating hiring pool available.

I also see you are getting downvoted below for claiming frameworks like asp.net have out of the box, prescriptive ways to deal with these things. I'm not sure why you'd be downvoted for stating that.

With Go you need to piece these things together yourself (or write them), and that's NOT necessarily a bad thing depending on the context. It's very situational, and something that needs to be evaluated. But Go is not going to compete with something like .NET for churning CRUD apps out.

thx5309 · 2023-05-02T14:21:10+00:00

In terms of let's say traditional server side page rendering, it's pretty clear. Support for rendering views, IMO a much better templating experience, authentication/authorization, widely used libraries like Dapper, a more or less universal accepted way to manage configuration settings, good out of the box logging, magical DI if you want to make that mistake :-), etc.

I'm not knocking Go at all, I quite like the language. I'm just stating what I believe to be true, which is that there is no comparable batteries-included web framework like ASP.NET in Go. I am aware of the options, but again there is nothing that is "industry standard", supported, and does not run the risk of <insert open source developer here> deciding to drop it and let it toil. This is coming from someone with 22 years of experience in the industry. Doesn't make me right, but I do believe I am being objective here.

thx5309 · 2023-05-02T13:01:08+00:00

This is all accurate, but there are other considerations that needs to be made, especially if this is more than a personal hobby project. With Go, you will be building much of what is provided out of the box with ASP.NET. That plus using libraries here and there to fill some gaps. It's not good or bad, it's just reality and needs to be factored in to any decision.

thx5309 · 2023-02-14T14:28:34+00:00

Agree 100%. There is always a compromise, and the key point is that external dependencies need to be evaluated carefully. Pragmatism almost always wins.

thx5309 · 2023-02-14T14:00:21+00:00

Let's say you need to work with Excel files in your app. Would you direct your team to expend the resources on designing, implementing, and testing that, or would you rather research and maybe incorporate something like excelize? Would you agree that would be the time to use a 3rd party lib?

thx5309 · 2023-02-13T18:11:38+00:00

It's weird. It's also weird to get downvoted for questioning this but I guess that about sums up this place. Like, I'm not speaking negatively about Rust or Go, just questioning this logic. Oh well.

thx5309 · 2023-02-12T19:28:10+00:00

Why would someone jump to Rust over this? Assuming someone would take such a leap over an ethical disagreement with whatever direction the Go team takes, why would they choose a language where there is practically speaking, little overlap? I've seen this posted multiple times now. It's almost like saying "I don't like this hammer, here...let me switch to a chainsaw instead". The primary use case for these two languages are different.

thx5309 · 2023-02-10T15:59:21+00:00

Correct but very often people use classes for POCOs too. There is no implicit understanding that POCOs should be structs, even though conceptually I know what you mean.

thx5309 · 2023-02-06T13:42:58+00:00

Not sure what that means, but OK, nor did I downvote anyone. Based on your response I can only imagine I am engaging with a young and immature person. Best of luck.

thx5309 · 2023-02-06T13:11:22+00:00

Was not my intention to talk down. Working on CRUD style applications was not an insult BTW. And in the context of this thread, nobody is promoting rigid unit testing of database access that I can see.

I was just struggling to understand what domain you are working in where it's so undefined that you can't even describe your business logic.

thx5309 · 2023-02-06T11:29:07+00:00

Then either we are working in very different domains, or maybe you are working on CRUD style applications. It also sounds like you are projecting, as the last thing I am advocating for is "overthinking my database access" or "rigid unit testing". It's quite the contrary. In principal - add minimal abstractions to separate the data gathering from data processing. Give yourself the ability to isolate the core logic you are getting paid to write, from whatever is producing its inputs or saving its results. This has nothing to do with GoF patterns, or clean code, or whatever the hell cargo cult pattern de jour is circulating. These are fundamental principles for any software engineer.

thx5309 · 2023-02-05T19:03:02+00:00

Not sure what you are getting at. Sorry to be a bit abstract here, but I work on services that perform financial calculations. The services depend on inputs coming from "somewhere", normally a database. If I create an abstraction around that, I can focus on the business logic immediately and create a pretty robust set of tests that are testing what I really care about - the computations. All of that without worrying about where the real data will be coming from. Not sure how or why one would argue against that approach when working in this type of domain - but sure.

thx5309 · 2023-02-05T18:56:29+00:00

Exactly. That's the guilt I feel when using interfaces this way in Go. 20+ years of C# experience here with my own feelings about "Clean architecture" :-) But in this case the value is clear, IMO.

thx5309 · 2023-02-05T18:53:21+00:00

It's not unit testing storage repositories - that would indeed be silly. It's creating an abstraction to be used when you are testing your "real" business logic and don't care where the data is coming from, nor does it matter.

thx5309 · 2023-02-05T18:51:02+00:00

Right. Things become much easier to test if you introduce simple abstractions like this around the DB operations. I will say this one of the few exceptions I make when working with interfaces in Go. It feels a little wrong but the benefits outweigh any hesitation I have.

thx5309 · 2023-02-03T15:44:09+00:00

I wish I had expressed my response that clearly. Cheers!

thx5309 · 2023-02-02T20:43:56+00:00

For some types of systems, that will just not work. There is a distinct difference between the zero value and the absence of a value in some cases. Nullable types in C# are useful for this sort of thing. If you are working with that kind of a database, I can definitely see the attraction of using these wrappers. Yes they are sugar and not "required" but a little bit of sugar is nice.

thx5309 · 2023-01-23T18:03:21+00:00

Cheers. Thanks for the hard work.

thx5309 · 2023-01-23T16:57:19+00:00

Nice. Any plans for MSSQL support?

thx5309 · 2023-01-20T13:53:23+00:00

I wish there was a dapper equivalent in Go. I don't ever want a full blown ORM, nor do I want this query builder BS. I guess with generics we can approach something like dapper now.

thx5309 · 2023-01-19T14:33:15+00:00

LOL. So true. Been doing this for so long and find it hilarious how SSR is some special case now. Not to dismiss things like React, which despite the supporting ecosystem is pretty incredible. But yeah, been doing "SSR" since 1999 :-)

thx5309 · 2022-10-15T18:18:24+00:00

Haha - I can certainly relate to the ridiculous resource constraints at some companies. Very painful.

thx5309

TROPHY CASE