Live data from Hacker News

The best Go framework: no framework?

threedots.tech

101–110 of 185 posts

Re: The best Go framework: no framework?

#101
post #41
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…

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 can be about as intrusive as the built in grpc server. This is just an, at best, outdated take.

Re: The best Go framework: no framework?

#102
post #70
post #58

Earlier quoted context omitted.

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 fa…

"Wasting your time on problems that are not part of the business"

How much time?

Sometimes a task that takes X time and seem unrelated to your "main" task, actually increases your productivity when doing the main task.

A prime example is sleeping when trying to build muscle and lose weight.

On a surface level, sleep is a waste of time: you should be in the gym lifting weights or out there running/cycling/swimming. But actually no. Sleeping improves your results, and improves your performance on your workouts.

I'd argue there's a similar dynamic here.

Working on the lower levels of your problem might seem like a waste of time, but it's actually not. If nothing else, you feel more enjoyment from your work. Being engaged with what you do and not being engaged is huge.

Another problem that often occurs when you are always only working in the "high level" is you have no idea how to do anything well unless the framework does the heavy lifting for you. As soon as you step outside of what the framework was designed to help with, you are lost and have no idea how to approach the problem. All your approaches are half-assed solutions. You see this every single day on "big teams".

Re: The best Go framework: no framework?

#103
post #84
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…

> I also haven't yet met a developer who fully understands what @Transactional does, exactly.

I have found Spring Boot to be a step forwards from the old Java EE world in basically every way except for this. Transactional boundaries are somehow more difficult to analyze.

Re: The best Go framework: no framework?

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

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 reality is you'll include so many "starters" in a medium use app, you won't know whose including what. A polluted Spring container is a real problem. That isn't the only problem, but it's one of the more prominent. You may say "well write cleaner code!" and I would reply that Spring is conducive to writing code that doesn't fit well with the framework, and that's mostly because you have to understand 10+ years of architecture decisions when you want to do anything beyond the basics (That's why we mostly don't reach for the "Spring" way to do things anymore, just the simplest way). All that is to say, there is a reason Spring development has been supported by Spring consultants.

For point two, It's very easy get started but it's very difficult to mature into a fully productive dev. The things juniors and mids struggle with the most is unpacking autowiring and how to resolve those issues, how to properly handle async behavior (especially with Spring fully embracing WebClient and Reactor now), and database connections.

But yeah, outside of all of that, very easy to use, sure.

Re: The best Go framework: no framework?

#105
Having no framework comes with having no documentation.

If you select a framework and work in the same scope as the framework intends to, then you can onboard new engineers much more easily by telling them: We are working as the framework defines, look into the documentation and you will understand the basic architecture of our software.

Of cause, devs can maintain their own documentation, but I guess this usually is something that is not done very well.

My personal experience: As soon as a company started their software without a framework, it became a huge mess. While onboarding, I observed very bad architectural decisions and even very severe security issues.

I'd say, only go with no framework, if you are experienced enough to technically create an own (good) framework. From my observations, going without a framework was usually a decision done by young engineers.

Re: The best Go framework: no framework?

#106
post #41
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…

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 familiar with Go. You don't have to trace something from XML to Java, and there is basically no magic (maybe the odd bit of Go reflection is the exception to the rule, but it's much less common than in Java/Spring and the "magic" is much less magical).

Re: The best Go framework: no framework?

#108
post #101
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 can be about as intrusive as the built in grpc server. This is just an, at best, outdated take.

On one level, it is not an outdated take. There is a LOT of old Java out there: out of date JDKs, out of date versions of frameworks. There is still a lot of Struts 1.1 out there.

I think our industry would look a lot different if more companies were keeping their Java apps up to date.

Re: The best Go framework: no framework?

#109
post #7

Been writing Go for my own pet projects and some production side projects for two years. Often resorted to "small libraries" like Chi, or SQL query builders. Since GitHub Copilot, I ditched SQL query builders as all the scanning and repetitive work is handled nearly immediately. I also ditched Chi and handle routing myself. Same for logging. The issue is spending time doing things that took one line before with a fra…

What does a typical handler look like in this scenario (url path params). I usually end up using Gorilla mux for this, but standard library for everything else.

I create a simple func for each handler to parse params. Most urls params are properly structured as /resources/{resourceID}/subresources/{subresourceID}.

So I can essentially create a map[string]string by splitting slashes and going 0 = key, 1 = value, 2 = key, 3 = value, etc.

If a handler uses a different structure like /resources/{resourceID}/{subresourceD}, I will have the func specifically handle that case.

Some ways may work better but this works for me and it's not magical, and I tend to touch that code once and never again so it's then out of the way, all in a file.

Re: The best Go framework: no framework?

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

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 coding and ignore everything else a framework offers, which has downstream effects on coding and construction. It’s not all about the code. The coding is actually the easy part

The only projects ppl pay us is for the ones that are so large and complicated that if you don’t use frameworks, you’re going to either die or go crazy

Post reply on HN