
Ask HN: Considering using Golang for my main language for web development - ergo14
Hi, I&#x27;m considering using Golang for my main language for web development, I&#x27;m trying to see if there is anything resembling Python&#x27;s SQLAlchemy - basicly elliminating text query stitching (and to be clear I know SQL itself).<p>And a web framework that would resemble Pyramid web framework functionally wise.<p>I&#x27;m also trying to wrap my head around the fact that there are tons of db drivers, when I looked last time 2 years ago I was completely unsure which one would be the right to use - are there some &quot;language standards&quot; that are most used and supported well by community?
======
programd
Gin [0] is a good place to start for Go web frameworks

Gorilla [1] is more of a toolkit, but very common and very useful

There's also Buffalo [2] for an opinionated kitchen sink included web
framework.

As for SQL ORMs, sqlx [3] and gorm [4] seem to be the most popular ones. But
really the `database/sql package` is probably all you need. As for drivers,
here's a list [5]

[0] [https://github.com/gin-gonic/gin](https://github.com/gin-gonic/gin)

[1] [http://www.gorillatoolkit.org/](http://www.gorillatoolkit.org/)

[2]
[https://github.com/gobuffalo/buffalo](https://github.com/gobuffalo/buffalo)

[3] [https://github.com/jmoiron/sqlx](https://github.com/jmoiron/sqlx)

[4] [https://github.com/jinzhu/gorm](https://github.com/jinzhu/gorm)

[5]
[https://github.com/golang/go/wiki/SQLDrivers](https://github.com/golang/go/wiki/SQLDrivers)

~~~
ergo14
I'm not sure if you adressed my "no string stitching" point.

~~~
imauld
ORM's are not as popular in Go as they are in Python. The closest I can think
of is
[gorm]([https://github.com/jinzhu/gorm](https://github.com/jinzhu/gorm)). If
you absolutely think you must have an ORM that's probably your best bet. Be
aware that it will come with some pretty significant performance penalties.
Even small applications will take noticeably longer to compile and run a bit
slower.I don't have exact numbers for this unfortunately. I also have a
feeling that K/V stores like Dynamo, etcd and Mongo are more popular in the Go
world than SQL DB's but that's just a feeling I get.

That being said, if you are building a web application with Go you shouldn't
think about it the way you think of building one in Python.I am primarily a
Python dev myself and it takes some readjustment to get in to the Go way of
doing things.Go really shines when building smaller, more focused API driven
applications. I'm sure it can be done and I'm sure folks are doing it but if
you are trying to build a sprawling Django/Pyramid webapp in Go you will
probably not enjoy it as much. Here are some packages (along with the
aforementioned gorm) I would recommend taking a look at:

Echo: A nice little HTTP framework with a focus on JSON API's.
[https://echo.labstack.com](https://echo.labstack.com)

gRPC: Not really for webapps (and not only for Go) but a framework for
building RPC microservices: [https://grpc.io/](https://grpc.io/)

net/http: A part of the standard library. The Go stdlib HTTP server is prod
ready out of the box. You can get quite far with only the stdlib in Go:
[https://golang.org/pkg/net/http/](https://golang.org/pkg/net/http/)

encoding/json: If you have used Marshmallow or the DRF in Python you can do
most of the serialization you can do with those right out of the box in Go
using struct tags and the stdlib json package:
[https://golang.org/pkg/encoding/json/](https://golang.org/pkg/encoding/json/)

struct tags:
[https://golang.org/ref/spec#Tag](https://golang.org/ref/spec#Tag)

~~~
ergo14
> Even small applications will take noticeably longer to compile and run a bit
> slower

But should I expect 3s longer compilation or 30s? I would still expect the
application to be faster than python though.

And yes I'm aware that I will need probably to sacrifice some niceness of
Pyramid/Python if I start doing "full" webapps in golang but thats a tradeoff
for speed and other features of the language. I'm willing to live with this as
long the work can be still carried out at reasonable pace.

~~~
imauld
I only tested it very quickly as part of a lightning talk. however after a
quick search I was able to find someone who did do some benchmark testing:

[https://github.com/jinzhu/gorm/issues/298#issuecomment-65747...](https://github.com/jinzhu/gorm/issues/298#issuecomment-65747130)

gorm didn't fare to well against the non-ORM options. The method in which
ORM's use to well be ORM's in Go is called reflection. It's generally
considered to be a performance hit and most devs I spoken to will try to avoid
using it if possible.Exactly how big of a performance hit it is depends on the
situation.IT performs more allocations than non-reflection code. So in the
case of an ORM where you may be performing these actions in loop (a query that
returns hundreds or thousands of results) that may be deeply nested (many
relations, user that has posts that have images that have tags and so on) it
could end up being a bottle neck. Additionally there was another detail that
really turned me off from gorm. Consider the following code:

    
    
        user := User{}
        db := getGormDB()
        db.Delete(user)
    

If you were to run that Go code, given an actual gorm DB connection, the gorm
ORM would delete every row in the user table.

EDIT: I just noticed those benchmarks are pretty old. It's very possible and
probably quite likely things have improved since then.

~~~
ergo14
If i would do `Session.query(UserCls).delete()` in SQLAlchemy I would also
delete all users in the table.

I don't know go syntax well enough to see a problem here, is it because the
User instance has no primary key yet? In this case I would expect gorm to emit
`delete from users where user.id is null`.

------
programd
BTW, for judging the popularity of a go package you can look at the bottom of
the godoc for the package and check how many other packages import it. I
generally pick the most popular one.

For example for the pq Postgres package "Package pq imports 31 packages
(graph) and is imported by 3749 packages." as opposed to the pgx package
"Package pgx imports 31 packages (graph) and is imported by 143 packages."

