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

161–170 of 185 posts

Re: The best Go framework: no framework?

#161

Post by za3faran »

Spiwux wrote: 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 echo what you're saying. What's ironic is that having worked at an employer that heavily uses golang, they ended up inventing their own dependency injection, app framework, web framework, etc. that are outright terrible, and you end up with the long stack traces that some people like to complain about in Spring or other similar frameworks.

So much money was wasted writing and maintaining those frameworks that was so flabbergasting.

Re: The best Go framework: no framework?

#162

Post by za3faran »

wing-_-nuts wrote: post #143
pkphilip wrote: post #93

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…

>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

Did they profile the system to find out where the bottlenecks are? What was their findings? And to which framework did they move?

Re: The best Go framework: no framework?

#163

Post by za3faran »

dopeboy wrote: post #135
davidkell wrote: post #19

Earlier quoted context omitted.

Agreed and well put. Lack of a decent Rails/Django option for JS/TS is part of the issue IMO, since that ecosystem is so popular atm. I also wonder if you have to get burned a few times rolling your own and that's just part of the journey :)

I’m really surprised there isn’t a solid batteries loaded framework in JS. There’s just no way I could use node + express over Rails / Django

Could you elaborate on some of the things you find express lacking? Asking because the team is evaluating using it.

Re: The best Go framework: no framework?

#164

Post by reducesuffering »

dopeboy wrote: post #135
davidkell wrote: post #19

Earlier quoted context omitted.

Agreed and well put. Lack of a decent Rails/Django option for JS/TS is part of the issue IMO, since that ecosystem is so popular atm. I also wonder if you have to get burned a few times rolling your own and that's just part of the journey :)

I’m really surprised there isn’t a solid batteries loaded framework in JS. There’s just no way I could use node + express over Rails / Django

Create T3 app https://github.com/t3-oss/create-t3-app

I was fairly new to "modern" web dev, starting a project, and went with Django because I had more Python experience than anything else. But I found templates very lackluster and poor to integrate with all the different JS ecosystem libraries people are creating to do very cool things on the frontend. Unfortunately, hooking React up to Django is a mess and most people doing this are still 5 years behind in React-land. Are you going to hybrid some template and some React? Are you going to containerize your django and react build system together?

Basically, I wanted a robust frontend ecosystem, well integrated to a simple backend (no Spring, Django-Rest-Framework monstrosities).

That led to React -> Next.js -> Typescript backend -> the rest of the niceties around it like Prisma (ORM-ish)

Create T3 App simplifies all the setup into a template and is extremely fast to start building features. No js build system setup, no python virtual envs. tRPC is an optional nicety.

Re: The best Go framework: no framework?

#166

Post by p2detar »

echelon wrote: post #128
berkes wrote: 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 actually addressed in the article:

> You may feel that building your services without a framework will take ages. Especially if you are coming from other programming languages. I understand that. I had the same feeling a couple of years ago when I started writing in Go. It was an unjustified fear. Not using a framework doesn’t mean that you will need to build everything yourself. There are many proven libraries that provide the functionality you need.

Re: The best Go framework: no framework?

#167

Post by majewsky »

cbrogliato wrote: post #138
greencheeses wrote: post #3

Go having a standard library that is so good for building simple services is what sets it aside from all the other languages that have come out in the last while in the same space. It has a great collection of community libraries but I so rarely need to fall back to them as I can usually cobble together whatever I need to pretty easily just using the standard library. It makes it easy to get started on a project as t…

Having such a large standard library to me smells like you can't build one as nice as that with the language. Since it missed generics until recently I can figure out why the STD library is that good and large and why there weren't that much framework. I've used Java before it had generics too.

I'm not sure I understand correctly but I'm assuming that this:

> Having such a large standard library to me smells like you can't build one as nice as that with the language.

means that you're implying that the Go stdlib is written in non-Go because Go would not be expressive enough. If so, that's a wrong assertion. The entire Go toolchain is Go, including the compiler, runtime and stdlib. If you happen to have Go installed, you can find the stdlib at /usr/lib/go/src.

Re: The best Go framework: no framework?

#168

Post by trinovantes »

ansc wrote: post #17
trinovantes wrote: post #11

Earlier quoted context omitted.

Isn't it just prepending "while(1);" to your responses? If that's all you need, it seems like a dependency overkill

I think this is the thing with (web) frameworks. Are you really going to remember that? And actually do it? And work around and build those other gnarly things for CSRF, SSRF and XSS? If you only need to serve happy-case HTTP, for sure you're better of without a framework. At least my experience without using a framework is that it's a tad annoying when you need the extras. And requires a lot deeper understanding of…

For security/safety sensitive tasks, you should be using checklists e.g. [1] so you don't need to remember. Pilots use pre-takeoff checklists to reduce chances of human error. Likewise, you shouldn't assume the framework will give you proper defaults.

[1] https://github.com/0xRadi/OWASP-Web-Checklist

Re: The best Go framework: no framework?

#169

Post by majewsky »

greencheeses wrote: post #27
euroderf wrote: post #16

Earlier quoted context omitted.

Agreed. But doesn't it seem sometimes as though some modest improvements here & there in the stdlib would have a big payoff in making it immensely more productive ?

I agree, there are some ergonomic improvements that could definitly be made, something like sqlx would be nice for example

What's the value of having sqlx in the stdlib? The only reason I could see is a social one, not a technical one (discoverability).

The Go devs did in the past include external libraries in the stdlib, the most significant one being "golang.org/x/context" moving to "context". This was a very important inclusion because it meant the stdlib could start offering context-aware APIs, and it was a signal to the rest of the ecosystem that the context API is stable forever and other packages can make their APIs context-aware without risk of future breakage. With sqlx, none of these issues arise: the main compatibility interfaces between different SQL libraries (particularly to the drivers providing support for different RDBMS) are already present in the stdlib.

Re: The best Go framework: no framework?

#170

Post by majewsky »

SergeAx wrote: post #160

> Python has Django and Flask, Ruby has Rails, C# has ASP.NET, Node has Express, and PHP has Symfony and Laravel. Go is different: there is no default framework. And this is the root of most problems described by author. If I start project on Python - I know that I can take Django and use it for at least 4 next years, spending one sprint a year tops to migrate to next LTS version. In Go only standard library currentl…

I'm maintaining about half a dozen microservices written in Go. In my experience, the Go community is very good about providing backwards compatibility.

In fact, I'm very strict about keeping on top of my dependencies because "spend a sprint to upgrade to the next version" is a process smell to me, no matter how seldomly it occurs. I have my Renovate bot set up to send PRs every Friday. Most of them are on "automerge on test success" at this point, then they soak in QA for the weekend and I send them to prod on Monday. The only trouble I can recall is with updating Kubernetes libs (let's not open that can of worms right now) and in some cases I have to manually intervene when libs upgrade from `interface{}` to using generics, but that's a refactoring that I gladly do.

Post reply on HN