Live data from Hacker News

The best Go framework: no framework?

threedots.tech

81–90 of 185 posts

Re: The best Go framework: no framework?

#81
post #76
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…

"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." In Go, not necessarily, because net/http actually is what many languages would call a "minimalist framework". There's a sense in which pretty much everyone here is right. You do need a framework in the general sense; you can't expect t…

Well said. The 'no big framework' thing works for Go because the Go standard library defines a common way for dealing with HTTP. The difficulty, then, is identifying 3rd party packages that play well with the rest of the ecosystem.

You can see the opposite in projects like Echo, Gin, Beego, etc., that eschew the standard library to various degrees and try to build the kitchen sink themselves. Sometimes this works! Echo is very popular, despite having nonstandard handlers and context. An absolute Go newbie is probably going to have an easier time using it than trying to pick out the best collection of libraries themselves.

I would love to see more 'blessed stack' collections that tie together good libraries such as this one: https://github.com/mikestefanello/pagoda

Re: The best Go framework: no framework?

#82

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 are great (sometimes), but pay attention to who is giving you this advice.

Re: The best Go framework: no framework?

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

[deleted]

Re: The best Go framework: no framework?

#84
post #53
post #33

Earlier quoted context omitted.

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'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 does, exactly.

I agree Spring Boot brings a lot to the table (Spring Security alone, for example), but at the cost of significant downsides.

I see the benefit for larger and more diverse teams, but personally I would choose lighter-weight frameworks and libraries, even if at the cost of having to do more plumbing myself.

Re: The best Go framework: no framework?

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

Twirp (by TwitchTV) is a good gRPC alternative. It’s significantly lighter and easier to use.

Better than an alternative is Connect, which is gRPC but also supports gRPC-Web and the lighter weight Connect protocol (which seems inspired by Twirp) https://buf.build/blog/connect-a-better-grpc I like it because it solves most of my complaints about using gRPC from Go without giving up on gRPC.

Re: The best Go framework: no framework?

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

> 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 wrote a longer post on that[1], which got a lot of discussion on HN. Most of it too in the line of "lol, I use a framework because I don't want to write it all myself", completely missing the crucial first paragraph in which I carefully tried to explain the difference and explain that re-using code != using a framework.

[1] https://news.ycombinator.com/item?id=33185010

Re: The best Go framework: no framework?

#87
OP doesn't ask the question that would have saved a somewhat straw-man general position on frameworks: Why is it that Go lacks the familiar 'widely adopted framework'?

OP could have written about the two different types of code reuse and why one lends itself better to Go: Libraries vs Frameworks.

Java has magical frameworks because we have a magical JVM and first class (as in baked into the language) metadata utilities at the language level. Java can define & load new objects at runtime. Loose coupling? My god, this is as loose as it gets. In Go, you'll need composition of processes to accomplish the same thing.

Code reuse at Go happens at the library and networked-but-loosely-coupled component levels. This covers a lot of territory but not things that are, in effect, 'containers of components'. If you are in component oriented code sharing territory, Go is the wrong language. With Go, a framework can't do all the magical stuff the other kids' FWs do, but you get most of the pain of using frameworks. It is a language issue.

in general: Partially realized abstractions place greater demands on the language and its runtime capabilities than do partially realized composition (e.g. apis).

Re: The best Go framework: no framework?

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

I’ll vouch for chi here as well: if I’m building a Go web service and I really need to go one step above http.ServeMux, it’s the only library I consistently reach for.

Re: The best Go framework: no framework?

#89
> The easiest way is to start by putting everything into one file. You can start simple, defer some decisions, and evolve your project with time.

This is something that most even senior developers don’t grok. Default so called project starter scripts of the node world don’t help either.

The more structure you build before you know wth you’re doing, the more difficult you’ll make life for yourself down the line when you inevitably have to refactor code.

Re: The best Go framework: no framework?

#90
There's something to say for getting in the habit of delivering microprojects with minimal dependencies and tooling.

I do most of my Python work with PyCharm on a Windows machine, frequently with poetry as a dependency manager, but lately I was writing a script for burning DTS-audio CDs in a single step on my Linux server (has the optical drive) and made the decision to only use the Python standard library and do it all in a single file I edit with vim. The result is 150 lines of code that spin like a top.

I went through a phase of doing all the problems on HackerRank and learned to love "single-file Java" and discovered that you can do almost anything in a single file except declare a public class (if it is all in one package, default access is all you need.) It's not the usual way I do things but I like Java a lot more knowing I can write simple programs without maven, an IDE and all of that.

Post reply on HN