[midrus]

The Go hype is as bad as the frontend hype in my opinion.

If you're replacing Django with Go then either you never needed Django, or you have no idea what you're getting into.

At a previous job backend team decided to replace rails "because monolith slow ruby not fun anymore" with Go. Three years later they were still reimplementing things rails gives you since day 1. I've seen abominations as doing migrations as SQL scripts ran by cobbled together bash scripts because "as we don't have orms then orms are bad".

No need to say now they're about 4 years in and the one still running the business and making all the money is the monolith, not all the Go microservices around it.

Go is a replacement for c/c++, maybe java and for building infrastructure probably.

If you're using it for doing CRUD forms, you're using it wrong.

[Abishek_Muthian]

GP (BiteCode_dev) made a valuable comment for how we can build a easily deployable python application with

>web framework, db, caching, task queues, static file serving, which can handle around 100k visitor each day without a sweat.

i.e. with 4-5 large dependencies of frameworks, libraries, software etc.

In Go you can off the bat reduce those dependencies to 1 or 2, even completely eliminate them, you get deployable package and async for free with faster development cycle and lesser headaches of managing dependencies in the long run.

[readlikeasloth]

Out of curiosity: what features from Ruby are they reimplenting? I have no experience in Ruby but in a few other languages and framworks. And having encountered something missing yet when writing Go web services.

[midrus]

I've not even mentioned Ruby.

Rails. Features of rails.This is exactly the problem...people focus so much on the language they forget the ecosystem they're in, and the ecosystems matters a lot more than the syntax or the performance.

[midrus]

> And having encountered something missing yet when writing Go web services

How do you do form validations, translations, database access, migrations, email sending, background jobs that don't die on a deployment, user authentication, file uploads, caching, etc?

Of course all of this can be done, you just need to take 100 decisions and tie together 256 libraries many of them probably abandoned in a few years from now.

If you don't need any of that, then just what I said before: ok, you never needed rails from the get go.