Live data from Hacker News

The best Go framework: no framework?

threedots.tech

61–70 of 185 posts

Re: The best Go framework: no framework?

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

I switch between Go, Spring, and ASP.NET (the latest one, which used to be Core, but isn't anymore). I don't think your Spring experience should be extrapolated to other frameworks — dealing with it is certainly significantly more painful than working with dotnet.

You don't get type safety for your database queries without jumping through hoops (compare anything it provides to LINQ — it's not even in the same league). Hibernate feels like a significant step-down after Entity Framework (I might be an idiot who doesn't know how to use it, that's entirely possible, but this just proves the point — it was easy to get started with EF, it didn't require a doctoral in ORM studies to become proficient with, it's dead easy to write queries for (thanks to LINQ), and the vast majority of those translate to pretty efficient SQL which is fine for 99% of my queries).

You get lots of behavior decided at runtime (while ASP.NET for the most part is very explicit in its configuration).

It also doesn't use many annotations (most of those I use are fully optional, like adding pretty names to database columns; and those can be configured through explicit method calls).

It does require DI (and IoC containers are swappable if you don't like the default), but I didn't have nearly as many issues with it as when working with Spring projects, whatever the reason may be.

Re: The best Go framework: no framework?

#62
post #13

For junior developers reading this: frameworks are great, learn to love them, they will save you much time and stress when shipping real products.

However maybe also learn to love a language that embraces them at the same time so you don't come away with a poor experience because of only trying a language that has poor frameworks (Go, JS/TS, etc). Definitely try something like Python + Django, Ruby + Rails, Java/Kotlin + Spring to get a feel for what a mature framework can really do. Then if you find you still don't like frameworks and the style of programming…

Also, this shit is harder than it seems, and it is painfully easy to introduce huge vulnerabilities if you don’t know what you are doing. SQL injections, CSRFs, etc can all be a problem if you go down a naive route.

Re: The best Go framework: no framework?

#63
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…

When I did Java, I found the Java ecosystem to be very productive because of the libraries available, but Spring was basically useless and was just a way to convert compile-time errors into confusing runtime errors.

Most of the useful stuff in Spring is just thin wrappers over other libraries (including the standard library) anyway.

Re: The best Go framework: no framework?

#64
post #20

You also get to implement stuff like CSRF protection, cookie signing, anti session fixation, etc. You also lose out on community contributions because you are your own community now. You also better have stellar internal documentation because onboarding developers is going to be a pain otherwise. 99% of cases people are better off using a boring conventional web framework and implementing their actual business logic…

This has always been the sticking point for me when I am wanting to try out new frameworks. When starting a new project I used to get excited on the idea of using a lean barebones framework, only to realize later on the boring bits that I had to figure out/implement or rely on some third-party library that may not stay up to date with best security practices in the future.

Re: The best Go framework: no framework?

#65
Yeah, I think it might be a good option for experienced devs and it can also turn into a rabbit hole for junior folks. No silver bullet and everything depends on what you are trying to build. But yeah this discussion never get's old :)

Re: The best Go framework: no framework?

#66
post #32
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…

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 projects they have worked on for a long enough time to have a reasonable opinion on the approach, they come out of this with massive biases and cannot accept that others have had pleasant experiences on the same tools and team sizes if they have had an unpleasant one.

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.

Re: The best Go framework: no framework?

#67
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…

Spring works really nice when working on monolithic services, but Golang is on the complete opposite side of the spectrum - Go is really good for microservices.

Spring is more like traditional application development, where you revisit your code multiple time during its long life cycle. In comparison, Golang is more like spit it out fast and forget. Its syntax is so dumb that you can’t possibly misread the code from any angle, so maintenance is also brain dead simple.

In this aspect, using frameworks in Golang simply defeats the point of using the language, because frameworks make codes harder to read. The language is to be used like C, where (almost) everything is manual and explicit.

Re: The best Go framework: no framework?

#68

A lot of people use go for microservices, and then you kind of need a framework. And all the proto + protoc + protoc-gen-go + grpc + swagger/openapi + json-grpc-gateway dance is… not easy to understand at first

Well, maybe the problem is in gRPC and Protobuf?

Re: The best Go framework: no framework?

#69
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…

Different strokes I guess. I've previously worked at big orgs. with Spring, now working with Go microservices and enjoying it by and large. I don't miss the days where I had to deal with random missing or conflicting beans stopping my app from starting. The nice things about a Go app is because the control flow is so exposed, if it compiles you can be pretty sure it is going to run, and if it doesn't compile you can…

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.

Re: The best Go framework: no framework?

#70
post #58

For junior developers reading this: frameworks are great, learn to love them, they will save you much time and stress when shipping real products.

For junior developers reading this: don't listen to the above; it's bad advice. I mean, unless you want to remain a junior forever.

How about offering real counter advice instead of just saying its bad advice?

Going to have to also agree with the OP. Frameworks are great for the majority of real world cases. There are definitely cases where specific optimizations are required and maybe a framework is not best fit but those are rare.

Lets try to steel man your disagreement though. Having worked in larger orgs I believe there is a trap that some fall in when using frameworks. Ignoring what is happening inside of the plumbing of the framework and ignoring why the framework is doing it. From that perspective you can fall in the trap of not having mastery of domain and it can limit your career in the long run.

On the otherside my argument is that frameworks provide immense value to orgs of all sizes. Even for a single person team there is value because you are not wasting your time on problems that are not part of the business. You should understand how the framework works in the long run though. A lot of these patterns carry over between frameworks and languages, mastering your first one will open a lot of doors in the long run.

Post reply on HN