Hacker News Reader

Comment by codegeek | Hacker News Reader

What I love about Go is its simplicity and no framework dependency. Go is popular because it has no dominating framework. Nothing wrong with frameworks when it fits the use case but I feel that we have become over dependent on framework and Go brings that freshness about just using standard libraries to create something decent with some decent battle tested 3rd party libraries.

I personally love "library over framework" mindset and I found Go to do that best.

Also, whether you want to build a web app or cli tool, Go wins there (for me at least). And I work a lot with PHP and .NET as well and love all 3 overall.

Not to mention how easy was it for someone like me who never wrote Go before to get up and running with it quickly. Oh did I mention that I personally love the explicit error handling which gets a lot of hate (Never understood why). I can do if err != nil all day.

A big Go fan.

View on HN

I like Go for this reason as well. In Python I found the Flask framework to be suitably unobtrusive enough to be nice to use (never liked Django), but deploying python is a hassle. Go is much better in that area. The error handling never bothered me either.

I think if Go shipped better support for auth/sessions in the standard library more people would use it. Having to write that code yourself (actually not very hard, but intimidating if you've never done it before) deters people and ironically the ease of creating Go packages makes it unclear which you should use if you're not going to implement it yourself.

My main gripe about go is that it's decent for the middle and late stages and really really bad to start with. You'll spend way too much time rewriting stuff you literally get for free by running "rails new" or "bundle add devise"

I love using Go for personal projects, but I keep finding myself recreating the same redis-based session storage logic, authentication, admin vs public routes, etc. Really does burn time in the beginning, even though it's fun to write the code.

There is definitely space for an opinionated set of libraries and boiler plate code for golang projects like this.

Having said that, I’d bet that the go community consensus is that you build one out yourself and reuse it. So most times I end up copy and pasting the same logic rather than recreating.

100% this. I have a set of commonly-used code in a repository we use at work. AuthN/AuthZ, code specific to our infrastructure/architecture, common http middlewares, error types, DB wrapper, API clients, OpenAPI Server generation, etc.

However, my personal projects have a different set of code I reuse (more CLI- and tool-heavy focus), and I'm sure other environments would have an entirely different set of reused code.

On the opinionated library side of things, I did follow LiveBud for a while, and Go-Micro but haven't really sat well with the experiences from those, given how they lock you in to different aspects of your stack.

Some great points about the downsides of Go. Btw I was a Flask junkie in early days.

I am a Django apologist because I grew up with Django. So with that being said, I'm not out to convert you but I am genuinely curious what you don't like about it. Promise I won't refute anything I just like to try to understand where it turned off folks.

I don't like flask because it seems just easy enough to be really productive in the beginning but you eventually need most of the things Django gives you. So I would rather pick up Django Rest Framework or Django Ninja than Flask or Fast API. In those cases I jump straight to Go and use it instead because the same library decisions on the Go side give me a lot more lift on the operations end (easy to deploy, predictable performance into thousands of requests per second if built correctly).

I have to learn an entite framework and if I want to stray away from what it wants the magic makes it hard.

For one, I so migrations with raw SQL onto the server, I just don't trust it any other way and I dislike ORMs, I even dislike query builders.

But for a big framework like Django you can't remove those batteries easily and you have already strayed away from the narrow paved road.

If I'm spinning up an API endpoint for my existing stack, I'm picking flask ( well no I'm picking go because WSGI is a pain in the... to deploy ) purely because I don't need auth + rate limiting + an orm and all that. I need endpoints exposed to do what I need, literally the rest is already handled by my API gateway and it will be tied into our existing management dashboard.

Django may be great to spin up a quick project but I found I needed to stary for the paved road pretty quickly so I rather picked a different tool...

This doesn't apply to everybody either, for aome Django is the correct solution.

It's opinionated in a way I dislike. I don't actually have anything against opinionated software--tailwind is very opinionated about how you should write CSS but I like it because it matches up with how my mind works. But I find Django very jarring. I can't point to a specific thing about Django, it's more that if I were to design a framework from scratch it would look nothing like Django, so I experience a lot of friction trying to shape my ideas about how to build an application into Django's way of doing it. I have the same problem with Rails as well.

I agree with you that Django provides most things that an application will eventually need, and if I were managing a team that was starting a project from scratch I think Django would be a reasonable choice, but aesthetically something about it irritates me.

I'm curious in what sense you find Python difficult to deploy? My company has tons of Python APIs internally and we never have much trouble with them. They are all pretty lightly used services so it it something about doing it on a larger scale?

There is a world of difference between having to install python, libraries (some of them may require C-based libs and compiling, therefore also install gcc), then configure wsgi, hope it doesn't clash with other python versions or have docker and containers... or just generating a fat binary in go.

Forcing something like WSGI and distributed computing is the biggest thing architecturally.

I'm currently moving 4 python microservices into a single go binary. The only reason they were ever microservices was because of WSGI and how that model works.

In any conventional language those are just different threads in the same monolith but I didn't have that choice. So instead of deploying a single binary I had to deploy microservices and a gateway and a reverse proxy and a redis instance, for an internal tool that sees maybe 5 users...

It was the wrong tool for the job.

I don’t see why WSGI would enforce any of that. Just sounds like someone jumped the microservices hype train…. You can as easily fit it in one python program as in one go binary.

I can keep an effective in memory store of data and expect it to even be the same in memory store of data? When a wsgi server is spawning multiple processes?

Or kick of long running backend tasks in a other thread?

These are things that python forces you to do in a distributed manner. Partly because of the gil and partly because those pesky cloud native best practices don't apply outside of the cloud...

And well if I'm going to have to reimplment an http server not ontop of wsgi how about just using a different language that doesn't have those same fundamental problems for the use case...

There's things I would happily use python for. A webserver just isn't one of them.

I mean it takes 10 lines of code to have a webserver running in golang, the language is build for it.

Deploying a Go application: copy executable to server, done.

Deploying a Python application: 1) Install python globally (oof) 2) figure out which venv system to use 3) copy project to server 4) install project to venv 5) figure out how to run it inside the venv so that it'll find the correct package versions from there instead of using the global ones.

Yea. I have worked with Python and Ruby just a little to know that deployments are a pain with those 2. Go is a breeze. You do need to setup systemd etc to run the binary but thats it.

> (actually not very hard, but intimidating if you've never done it before)

These stuff are never really hard, but you will make countless vulnerabilities that way. The most important job of a good framework is cutting down significantly on the possible to get wrong use cases, exposing you to already safe APIs.

Reply on news.ycombinator.com