Live data from Hacker News

The best Go framework: no framework?

threedots.tech

121–130 of 185 posts

Re: The best Go framework: no framework?

#121

Earlier quoted context omitted.

I write Spring full time these days. You may have Stockholm at this point (like me), but Spring is terrible in two areas: - when things go wrong - onboarding newer / more junior devs For point 1, there are so many layers of abstraction and 20 page stack traces that you could fill an entire log buffer with just one NPE... Kidding aside, I can't tell you how many times I've wrestled with the auto-configure magic. The r…

is there a go-to third-party documentation for spring (eg a book) you would recommend? I find official docs difficult to navigate. (which are either very narrow tutorial or in reference format, with important details omitted).

https://www.baeldung.com/ has been my lifesaver.

It's usually search "baeldung spring " and I get a nice article telling me how to do it but also explaining it as well so I can have the knowledge in the future.

I think the main author Eugen (there are many now) has a nice book.

Re: The best Go framework: no framework?

#122
post #33
post #23

I couldn't disagree with this any harder. I'm a Java BE Engineer who joined a Go shop, so I have a direct comparison. Both are microservice environments for products of similar complexity. It is insane to me how much less productive Go is for your average microservice enterprise environment. I'm sure it's great for systems programming or tool development. I like the simplicity. But the ecosystem is borderline useless…

I have to switch between Java Spring boot, Go and Rust. The latter two are framework less and easy to understand just by reading the code. Spring-boot development requires so much googling to figure out why I get UnsatisfiedDependencyException and what each annotation means. Even if I get it to work I still don't understand how it works.

From what I remember from spring boot it is (or feels like) more of a system to assemble your application from discrete modules, but which modules are used for what can be determined by configuration and various rules.

I mean the use cases of that will be limited these days; application architectures have changed to the point where what used to be a module within a Spring application can now be a microservice to be enabled or spun up depending on rules defined outside of the application.

But this is a very superficial point of view, I haven't seriously touched Spring for a decade and, thanks to some experience with Go, I feel like I won't need to either for most modern-day applications.

While Go may not be for everyone or for every application, its mindset of keeping things simple, just use the SDK or some libraries, etc does make for better developers. IMO.

Re: The best Go framework: no framework?

#123
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?

Re: The best Go framework: no framework?

#124
post #32

Earlier quoted context omitted.

This 100%. I think the people largely arguing for no frameworks have no idea what real productivity looks like at large scale engineering orgs. This mostly means you are not handcrafting libraries. There is a dedicated team who manages platform tooling including the frameworks/SDKs you use. Product teams may contribute to that but they will mostly be consumers. I always equate this to car manufacturing. I am not buyi…

> There is a dedicated team who manages platform tooling including the frameworks/SDKs you use. Ah, so an organization so bloated that you have entire teams "managing platform tooling" (whatever that means) instead of iterating on features customers actually care about.

When you start to scale for your amount of customers and features, you have to manage caching, job queues, and more. Things frameworks like Rails or Django provide mostly OOB. If you’re using Go or Node, you’ll end up writing your own de-facto framework (even if “writing” means pulling in different libraries and gluing them together) around those features, especially in the case of micro services where you’ll want each of those things available in each service.

Re: The best Go framework: no framework?

#125

Earlier quoted context omitted.

Spring Boot is actually a VERY easy to use framework. So much so that Netflix shifted out of writing their own libraries to using Spring boot. For example, the code below is a complete Spring Boot application with all of the default configuration in place. It will take just a couple of minutes to have this running and it provides quite a lot of features under the hood - which you don't need to worry about. @SpringBoo…

> For example, the code below is a complete Spring Boot application with all of the default configuration in place. Uh no, you forget the part where you have to add a bunch of stuff to your build system (maven or gradle, usually), so it actually knows what to do with this. You can't just compile that class with java -c, run it, and have a running application the way you could do it with lighter-weight frameworks.

Yes, you have to learn how to build a minimal pom.xml to make this compile and run. IntelliJ will do this for you with its Spring Boot project template. After that, it really is this easy.

I consider the boilerplate needed to build a main.go file that starts a gRPC listener to be harder.

Re: The best Go framework: no framework?

#126
post #66
post #32

Earlier quoted context omitted.

This 100%. I think the people largely arguing for no frameworks have no idea what real productivity looks like at large scale engineering orgs. This mostly means you are not handcrafting libraries. There is a dedicated team who manages platform tooling including the frameworks/SDKs you use. Product teams may contribute to that but they will mostly be consumers. I always equate this to car manufacturing. I am not buyi…

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 a “relatively long-standing codebase” with a framework “that is a dream to work on and has been touched by many engineers in a huge corporate setting.” And I could show you unworkable travesties that have to be eventually rewritten despite being written in library-only microservices that claim (because “micro”) to prevent this kind of thing from occurring.

Whether selection bias from your experience or an appeal to authority, there isn’t much to your argument. To me it just sounds like comparing well managed to poorly managed codebases.

If I have to manage a team, I’d much rather have the framework laying the groundwork for documenting “how we do things” than rolling consistency out ourselves.

Re: The best Go framework: no framework?

#127
post #8

This is one of the better things about Go and its community: eschewing frameworks like this. Having an ecosystem of in-house libraries tailored to your products' use cases is not the same as developing an "ad-hoc framework". Where I work, we have several languages deployed in our fleet of microservices. A couple have frameworks, and these frameworks are "try to do it all" types, complete with dependency injection and…

> layer upon layer of abstraction

I suppose it's a quibble, but this annoys me. It shouldn't matter how many layers of abstraction there are, because I should only have to interact with the topmost one. For example when I write vanilla Java there are, off the top of my head, the following layers of abstraction: the Java language, the JVM, Userland, Kernel, C, X64, and CPU microcode. No abstraction is perfect and maybe the day will come where I need to understand the hardware frontend on x64 chips to get my Java program working right, but in the overwhelming majority of cases I only need to worry about the abstraction presented by the Java language itself and maybe on the operations side those of the JVM.

All automated computing abstractions are, in the pathological case, leaky, but there comes a level of leakage where it essentially stops being an abstraction at all, useful or otherwise.

Spring Boot isn't an abstraction, it's a language extension implemented via Java annotations. Thus you must in addition to understanding the relevant parts of Java, also understand the relevant parts of Java/Spring. Personally I think it's poorly documented and doesn't really have a cognitively manageable semantic theory, but it's been a long time since I've worked with it so maybe that's been sorted out?

Re: The best Go framework: no framework?

#128
post #86
post #41

Earlier quoted context omitted.

You're saying that grpc and protobuf are over engineered but you're happy with Spring? gRPC and protobuf are just transport and serialization, they have nothing to do with business logic, on the other hand Spring is a heavy, bloated framework. Most Java frameworks are complicated backed by layers of abstraction and black magic. btw no framework does not mean you don't use any library, there are some good lib aka micr…

> 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.

Re: The best Go framework: no framework?

#129
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. persistence/3rd party layer (codegenerated too), add additional go source code file for things that wasteful to be codegenerated, only input struct, basic persistence methods or network calls, and output struct (DAOs) goes here

if using gRPC layer 1 already codegenerated, so only need to fill layer 2 with business logic and codegenerating layer 3.

Re: The best Go framework: no framework?

#130
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.

That's highly dependent on use case and baseline skill set of a given team.

Often times you can get away with a subset of functionality which makes for a simple implementation.

Post reply on HN