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.
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.
My previous job did a PHP -> go transition. I felt like it went well.
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).
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...
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.
Yep. That's exactly what I was talking about. You know that's what prepared statements do, right?
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.