Hacker News new | past | comments | ask | show | jobs | submit login

The reason I love Go is that every time I pull it out, I write a small amount of it and it runs beautifully. For example my company has a critical micro-service implemented in ~300 lines of Go, it's been running for six months now without a single hiccup, highly performant, very sexy.

The reason I will almost never use Go for web apps is because interaction with databases is limited (almost entirely) to raw queries. Maybe I'm spoiled by the likes of Active Record, Sequelize, Mini-mongo, Sql-alchemy, etc, but it's a huge drop in efficiency to spin my own SQL.

The point to take away here is that Go, more so then many other languages IMO, has its strengths and weaknesses. If you use Go in one of it's weaker use-cases you're gonna have a bad time. If you use Go for one of it's strengths you're gonna have a great time.

See you guys and gals in n weeks when we need to rehash the pros and cons of Golang again.




> The reason I will almost never use Go for web apps is because interaction with databases is limited > but it's a huge drop in efficiency to spin my own SQL.

Sorry, I have to disagree. I come from PHP, where when you sneeze an ORM appears. I actually am a DBA also. I am very familiar with SQL and I love writing out raw SQL.

I don't see this as a limiting feature. It doesn't affect me at all.

There are ORMs for Go as well. But I don't know how good they are. YMMV!

Last point. I have shipped into production a web app using GIN framework. I ported from PHP to Go. I didn't feel I was losing anything.

Go is amazing. It hasn't let me down yet. I doubt it will.


What are these ORMs you are speaking of? Only usable ORM i've seen for PHP is Doctrine.


Any framework has their own. Yii implements active record, I've been working with that for a few years now and I really love the paradigm.


I enjoyed using gin at first, but eventually felt the need to rip it out and replace it with mostly the stdlib. :(

My previous job did a PHP -> go transition. I felt like it went well.


> I come from PHP, where when you sneeze an ORM appears.

YMMD.


The reason I will almost never use Go for web apps is because interaction with databases is limited (almost entirely) to raw queries. Maybe I'm spoiled by the likes of Active Record, Sequelize, Mini-mongo, Sql-alchemy, etc, but it's a huge drop in efficiency to spin my own SQL.

There are plenty of ORMs and query builders available for golang, many of which have a very similar interface to AR. I personally use a query builder and let structs be in charge of reconstituting themselves from the db rows returned, and am quite happy with that tradeoff, in fact I prefer it to having objects magically instantiated behind the scenes as in AR. There's no need to restrict yourself to raw sql if you prefer a query builder of some kind or even an ORM (if you don't mind using reflection).


Exactly. I love how every release of Go, or Rust, mainly those two, turns into so much rehashing...it hurts.

Little discussion about the release changes happens...a simple google search will return all the discussions of pros and cons you would ever want to read in a life time...


> Maybe I'm spoiled by the likes of [...] Sequelize

Sequelize was a huge drop in efficiency for me any my team. As soon as you go outside of the typical select-where statements, it completely falls apart. I spent hours manipulating that horrible "almost-SQL" syntax to get it to spit out the query I wanted, and often I would just give up and fall back to using a raw query. Yeah, it's great that you can use raw queries when you need, but I soon realized that I almost always wanted to use them.

I switched to KnexJS which has syntax that is practically one-to-one with SQL and have had very few problems since then. Generated queries are much more predictable and easy to write, and it forces you to improve your SQL skills. I view that as a good thing.



I've had nothing but great experiences with gorm.


Just build yourself some simple mappers with hand written queries, and you've got better performing code than any ORM will ever give you. Honestly, the biggest problem I find with most webapps performance I've worked is on caused by terrible queries written by the ORM.


How different are people :) I personally prefer raw db queries as more flexible and performant way :) "Typing is not the bottleneck" (c) GeePawHill


As long as you don't want your queries parameterized/precompiled and inputs escaped, rolling your own SQL by hand should work.


Do you really think I use non-escaped queries? :) Really funny :) Read about prepared statements.


> "queries parameterized/precompiled and inputs escaped"

Yep. That's exactly what I was talking about. You know that's what prepared statements do, right?


Yes, I know, and I use them in raw queries.


That is also my issue with Go for web apps.

Doing things a bit lower level with beautiful standard libraries is OK. In subjects like html parsing, templating, routing or intercepting requests it has a meaning. You learn dynamics more down to the metal. However raw sql and value mapping with NullString etc. doesn't give the same joy. Maybe a higher level standard or additional x package can solve this problem.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: