Live data from Hacker News

The best Go framework: no framework?

threedots.tech

171–180 of 185 posts

Re: The best Go framework: no framework?

#171

I like fiber the most, but can use anything like echo (and past companies use only httprouter, gin, httpkit, etc) as long as the codebase not overly layered, I guess any framework is fine only need to split to 3 kind of layer: 1. serialization/transport layer (codegenerated) -- framework goes here 2. business logic layer (one that unit tested), only input struct, transform/process, and output struct (DTOs) 3. persist…

Your comment made me realize I'm not truly anti-framework, I'm anti-sell-your-architecture-to-the-framework, which most frameworks want you to do. Problem is, many MANY people do not have sufficient experience to know the perils of putting the framework in charge of the architecture, so they do just that, and decry any other approach as "Java-esque." (That label says an awful lot in and of itself.) The impact of this…

I think you still are anti-framework by any reasonable definition of the word. Library = your code calls it, Framework = it calls your code.

Re: The best Go framework: no framework?

#172
post #96

Yeah, Having built a web application serving 100K+ users in Go. First 2/3 weeks were spent on making sure we were a framework. So new Modules could be added. New external calls were abstracted and also dealt with lot of circular dependency. This was all fun and learning, but wouldn't mind having a "Flask" or "Express" version of a Golang framework which took care of all the boilerplate out of the box. We did try some…

Would https://gofiber.io/ work for you?

Will checkout thanks.

Re: The best Go framework: no framework?

#173
post #86

Earlier quoted context omitted.

> btw no framework does not mean you don't use any library I hear that silly argument "no framework === rewrite everything from scratch" far too often. There's a giant difference between libraries and frameworks! It's terminology: it's a framework if you build your app inside it. It's a library if you build it inside your app. The later is fine. The former: I dislike it - even in JavaScript, Ruby, Rust or anything, I…

That’s because your premise is weak. You argue that Django is the wrong choice for lots of projects but the counter factual is that our job is to figure that out. We have to choose the lesser evil. It’s not convincing to just call everyone stupid. Everything is a trade off. You have no idea what those could be in any particular situation so that’s why your whole argument falls apart Then you focus on construction and…

> It’s not convincing to just call everyone stupid. Everything is a trade off.

I wish it were less acceptable to play the "balanced" person in the middle.

If and when there is a balance point, someplace where the actual truth tends to be, imho, it's almost never in the middle.

There are reasons those frameworks (and Golang, too) tend to do things in an opinionated way.

I wish there were more strong opinions lightly/loosely/weakly/gently/another-word-ly held[1]. I think opinions too strongly held is a surer path to there than starting from a place of trying to "meet in the middle."

[1] DDG-ing the term showed a bunch of adverbs of holding! Here are a some:

    why it works: https://www.nwea.org/blog/2022/strong-opinions-loosely-held-demystifying-social-emotional-learning/

    someone also said something on medium: https://medium.com/@ameet/strong-opinions-weakly-held-a-framework-for-thinking-6530d417e364

    contrarians take a stand, too: https://commoncog.com/strong-opinions-weakly-held-is-bad/

Re: The best Go framework: no framework?

#174
post #66

Earlier quoted context omitted.

I have been a web engineer for a decade. I've worked on Java Spring apps, PHP, Node.js (express), Python (both flask and Django), clojure, Rust, and now Go. I have worked on teams large and small, and on codebases old and new. In my experience the problem with this kind of conversation is that you can actually have a pleasant experience in all permutations of the above. Since people have a ceiling on the number of pr…

> I _promise_ you that you can absolutely have a relatively long-standing codebase without a framework that is a dream to work on and has been touched by many engineers in a huge corporate setting. Similarly I could show you absolutely unworkable travesties that have to eventually be rewritten despite being written with frameworks that claim to prevent this kind of thing occurring. Conversely, you can absolutely have…

[deleted]

Re: The best Go framework: no framework?

#175
post #120
post #69

Earlier quoted context omitted.

By far my least favourite thing about the Java web ecosystem is how weirdly obscured the bootstrapping process for starting processes is. So much of how your application starts is determined by XML files and DI frameworks that I often have no idea (or am sometimes not even exposed to) where the `main` function is.

I’m only assuming, but I guess your last experience with Java is a bit dated, XML configurations have been largely replaced. And then what we are left with is a huge, old project vs some new microservice, which would be an unfair comparison in any language

You're totally right. I'm sure things are better now in modern Java and adjacent spheres like Kotlin.

Re: The best Go framework: no framework?

#176

Earlier quoted context omitted.

Everyone makes mistakes, even framework/compiler teams. I mean look at how long it took Go to get generics. Huge mistake IMO. I still dislike what ASP.NET did with their startup, and I don't think it's improved much. The minimal startup is just a bunch of magic (where did the var 'args' come from? Just magic.) Framework folks are people, they try new things, it doesn't always stick.

That feels a lot of ‘old man telling skies’. What is main(), where did it come from? Who calls it? What is argc and argv? Who puts that stuff there.

main() is a well established entry point in computer science. It’s the first thing one learns when learning to program. Nowhere else in C# are there “ambient” variables.

https://en.m.wikipedia.org/wiki/Entry_point

Re: The best Go framework: no framework?

#177
post #86

Earlier quoted context omitted.

> btw no framework does not mean you don't use any library I hear that silly argument "no framework === rewrite everything from scratch" far too often. There's a giant difference between libraries and frameworks! It's terminology: it's a framework if you build your app inside it. It's a library if you build it inside your app. The later is fine. The former: I dislike it - even in JavaScript, Ruby, Rust or anything, I…

If you don't use a framework, the structure of your code will still grow to resemble one anyway. Something internal, nonstandard, more difficult to maintain, and probably less congruent with the problem space.

> more difficult to maintain, probably less congruent with the problem space.

This is not true as blanket statement. It may. But with "a framework" you are bound by the architecture, upgrades, use-cases and so on that this framework covers. And limited by the ones it doesn't.

In practice, choosing a framework on day one of the project, means you cement yourself in architectural choices when you still lack all information about what architectures will be needed. You don't know your problem space.

All you know, for certain, is that his problem space will turn out different than what you thought it would be today. Flexibility to move along as this evolges is critical to "maintainability".

In practice, therefore, you'll quite likely end up with a framework that is severely harming your ability to write maintainable and congruent code over time.

Re: The best Go framework: no framework?

#178
post #86

Earlier quoted context omitted.

> btw no framework does not mean you don't use any library I hear that silly argument "no framework === rewrite everything from scratch" far too often. There's a giant difference between libraries and frameworks! It's terminology: it's a framework if you build your app inside it. It's a library if you build it inside your app. The later is fine. The former: I dislike it - even in JavaScript, Ruby, Rust or anything, I…

That’s because your premise is weak. You argue that Django is the wrong choice for lots of projects but the counter factual is that our job is to figure that out. We have to choose the lesser evil. It’s not convincing to just call everyone stupid. Everything is a trade off. You have no idea what those could be in any particular situation so that’s why your whole argument falls apart Then you focus on construction and…

You miss a crucial nuance that I did make:

> there will be a lot of projects where Django is a very poor choice.

often and lot is crucial - it's opposed to all. Because it implies exactly what you then continue to state: that its our job to figure out if this project is one of those "lot [..] with a poor fit" or one of the ones where it actually, and will remain, a good fit.

Re: The best Go framework: no framework?

#179

Earlier quoted context omitted.

That’s because your premise is weak. You argue that Django is the wrong choice for lots of projects but the counter factual is that our job is to figure that out. We have to choose the lesser evil. It’s not convincing to just call everyone stupid. Everything is a trade off. You have no idea what those could be in any particular situation so that’s why your whole argument falls apart Then you focus on construction and…

> It’s not convincing to just call everyone stupid. Everything is a trade off. I wish it were less acceptable to play the "balanced" person in the middle. If and when there is a balance point, someplace where the actual truth tends to be, imho, it's almost never in the middle. There are reasons those frameworks (and Golang, too) tend to do things in an opinionated way. I wish there were more strong opinions lightly/l…

Yeah, there’s a reason for everything. But apparently not to use a framework. Thats “always” a bad idea, apparently.

I’m not trying to meet anyone in the middle. I’m saying use a framework all the time, every time.

Re: The best Go framework: no framework?

#180
post #178

Earlier quoted context omitted.

That’s because your premise is weak. You argue that Django is the wrong choice for lots of projects but the counter factual is that our job is to figure that out. We have to choose the lesser evil. It’s not convincing to just call everyone stupid. Everything is a trade off. You have no idea what those could be in any particular situation so that’s why your whole argument falls apart Then you focus on construction and…

You miss a crucial nuance that I did make: > there will be a lot of projects where Django is a very poor choice. often and lot is crucial - it's opposed to all . Because it implies exactly what you then continue to state: that its our job to figure out if this project is one of those "lot [..] with a poor fit" or one of the ones where it actually, and will remain, a good fit.

[deleted]
Post reply on HN