Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The best Go framework: no framework?

threedots.tech

Post reply on HN
Print view View original

141–150 of 185 posts

Re: The best Go framework: no framework?

#141

Post by epolanski »

I love writing no framework/no lib backends in nothing but Node.js and TypeScript with some fp-ts and io-ts on top of that.

Node's standard libraries (http, fs, etc) give you already enough to work with.

Sure, you're going to have to re-implement plenty of things (e.g. file serving, which anyway isn't great in node), and many other things but there's plenty of pros:

- you can always understand how things work and change them to suit your use cases. That's just not the case with external tools. Good luck figuring out the codebases or even be able to build them locally

- it's much better for educational purposes to understand how things fit together and are supposed to work

The biggest con: security. Libraries and frameworks likely patch many vulnerabilities you didn't even know existed. This alone pushes me off from this approach and instead I fall back to some bloated framework, but security is important.

The second biggest con: performance. You're likely gonna do plenty of performance mistakes if you don't have a good knowledge of how Node really works.

Re: The best Go framework: no framework?

#142

Post by mk89 »

throwaway894345 wrote: post #106
Thaxll wrote: 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…

> You're saying that grpc and protobuf are over engineered but you're happy with Spring? This was my reaction. Every Spring app I've been involved with was a nightmare of gratuitous complexity that was nearly impossible to debug. I'm sure if I were a master of Spring I could figure it out, but that's the nice thing about Go--pretty much any programmer could work out what's happening even if they aren't particularly f…

You can use yaml nowadays with Spring. It's not anymore that ugly stuff it used to be 10 years ago where you had to wire everything together bit by bit.

I believe one thing that really tells the Java world apart from others is the heavy reliance on DI containers like spring/karaf/osgi etc. Once you understand that, everything is simpler.

I would say "believe me" in a face to face conversation, but even then it's proven useless :)

Working with Spring for me has become one of those things like when people suggest to "choose a boring technology" to build something. Yes, that's it. In the positive sense, of course.

There is literally an easy integration with everything you need, the learning curve is relatively smooth, and yes while it's true there are quite a few annotations you need to get used to, I believe after a few days you finally get used to it, and finally it simplifies a lot your development experience rather than making it worse.

For me the only reasons I would pick Go is because of native binaries (smaller footprint, memory, cpu etc), and it's "slim" for simple programs (like Python, but again binaries/native). I also like a lot Go's syntax so that's another pro.

Finally they are both very solid languages with strong tooling and wide communities.

Ps: the cool "new" guy seems to be Quarkus, though :)

Re: The best Go framework: no framework?

#143

Post by wing-_-nuts »

pkphilip wrote: post #93
Thaxll wrote: 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…

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…

>So much so that Netflix shifted out of writing their own libraries to using Spring boot.

The irony is that my team shifted from using spring boot to another framework for 'performance reasons'. Each instance only handles ~ 1k tps. Sighs

Re: The best Go framework: no framework?

#144

Post by ar_lan »

davidkell wrote: post #10

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: frameworks introduce additional complexity (especially ones with obscure dependency injection), learn how to use different tools properly and analyze when they should/should not be used. Learning your language properly (and carefully selecting when a framework makes sense vs when it doesn't) will save you much time and stress when shipping real products.

There's a time and place for framework/no framework, though I'd err on the side of not introducing a huge framework until it's actually needed.

Source: I work on a real, shipped for 3 years, SaaS product primarily written in Go (multiple services). The primary applications are framework-less, but some of our operators make use of kubebuilder (which certainly would qualify as a framework).

Re: The best Go framework: no framework?

#145

Post by mattgreenrocks »

kokizzu2 wrote: post #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. 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 choice often doesn't become apparent until much farther down the road. Then you start getting into the weird cottage industry involving brittle hacks with DBs/frameworks in order to delay setting them up so that you can run unit tests in under ten minutes.

It's ridiculous.

Part of the blame lies with the devs: refusing to take responsibility for your architecture means you are at the whim of the framework. And the framework devs are also at fault for pushing the lie that you merely need to write the absolute bare minimum of code and everything else will be taken care of.

Re: The best Go framework: no framework?

#146

Post by usrusr »

mattpallissard wrote: post #130
echelon wrote: post #128

Earlier quoted context omitted.

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.

But for those who do use a framework the problem space and failure modes are quite similar: some succeed at fitting in the unavoidable domain code into the blanks left by the framework, others build a "framework within the framework". And occasionally that might even be the right call, because the framework+blanks fits some of the requirements so well, while others exist that are served well by the "framework within the framework". Does not contradict "most framework within the framework are horrible mistakes" at all.

Re: The best Go framework: no framework?

#147

Post by arwineap »

Tainnor wrote: post #84
cduzz wrote: post #53

Earlier quoted context omitted.

I'm not sure that's contradicting the parent post. A framework is an added friction to picking up a development environment but potentially a huge asset to velocity once people are up to speed. You haven't gotten properly up to speed in that framework and that site's use of the framework. Perhaps you never spend enough time in that domain to really need to pick it up, in which case you'll always pay the "WTF is this?…

Some of the pains with Spring Boot don't go away even when you understand it better. The fact that the framework relies so heavily on reflection makes debugging a pain, turns what should be compile-time errors into runtime errors (which, among other things, makes updating libraries annoying), and also leads to very slow integration tests. I also haven't yet met a developer who fully understands what @Transactional do…

> The fact that the framework relies so heavily on reflection makes debugging a pain, turns what should be compile-time errors into runtime errors

This perfectly explains my problem with the fx library, and why so many java devs seem to gravitate to it

Re: The best Go framework: no framework?

#148

Post by jurschreuder »

Go without a framework and just the standard lib is already about equivalent to Python with FastAPI.

All you need to do is add a logger of choice, which will be different based on your architecture (one / multiple servers) anyway.

You might want to add user auth, which is often an external server anyway.

Maybe you want some boilerplate / codegen tool to add/remove/select objects from a database. But I personally don't use that because it's hard to optimize performance with those tools and SQL is already a good tool for it imho, don't need an extra abstraction.

In summary, all you need is the standard lib and maybe 3 external libs in Go, because it was made in a time when an api was already pretty standard.

In other languages you need way more extra stuff to create an api, so the need for a framework is greater.

Re: The best Go framework: no framework?

#149

Post by osigurdson »

GiorgioG wrote: post #39
osigurdson wrote: post #28

Earlier quoted context omitted.

The number of times that the asp.net "startup" has changed is completely ridiculous. It all started from a very bad place with a startup class that is stupidly called by reflection, forcing the developer to use trial and error to discover what methods should be used. Thankfully, they have finally done away with this but it is sad that they ever allowed these horrible patterns in the first place. Another abysmal area…

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.

I don’t enjoy being critical, but sometimes it is justified. When you have something used by millions of people, it should be more carefully vetted.

Re: The best Go framework: no framework?

#150

Post by sidlls »

User23 wrote: post #127
sidlls wrote: 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 mayb…

You’re talking about a different kind/level of abstraction. I’m referring to abstractions built within a language; there isn’t a direct; meaningful comparison to the abstraction of, say, a language over machine code.

Spring Boot isn’t an abstraction, but the language extensions and the things built on them within the frames are (badly engineered ones at that).

Post reply on HN