HN Explorer

Ask HN: Considering using Golang for my main language for web development

9 points by ergo14 ↗ HN
Hi, I'm considering using Golang for my main language for web development, I'm trying to see if there is anything resembling Python's SQLAlchemy - basicly elliminating text query stitching (and to be clear I know SQL itself).

And a web framework that would resemble Pyramid web framework functionally wise.

I'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 "language standards" that are most used and supported well by community?

7 comments

[ 3.4 ms ] story [ 26.9 ms ] thread
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

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

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

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

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

[5] 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). 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

gRPC: Not really for webapps (and not only for Go) but a framework for building RPC microservices: 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/

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/

struct tags: 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...

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."