3 ms·

Question : Is there a possibility that when Go package management is launched there will be a good opinionated framework like rails for GO . Because for new le

Question : Is there a possibility that when Go package management is launched there will be a good opinionated framework like rails for GO . Because for new learners ORM , authentication etc things matter a lot. I know Go promotes use of native HTTP package instead of frameworks but it is a large barrier for newcomers and have risk of writing error-prone web applications.

mixedCase 10y ago
Doing ORMs and auth without knowing what you're doing imply a huge risk out of itself, which Go tries to avoid. If you have relational data the solution is not to use an ORM to half-abstract it away, it's to learn SQL. ORMs can be useful tools to avoid boilerplate, but they will show their ugly internals when SHTF, and those are always harder to understand than plain SQL. As for auth, it's very easy to add to any web application or HTTP API using one of the many middleware solutions out there.
- aikah 10y ago
  > Doing ORMs and auth without knowing what you're doing imply a huge risk out of itself, which Go tries to avoid. And implementing it yourself the wrong way is also a huge risk.
  - mixedCase 10y ago
    Exactly the point I explained. You have to learn how it's done rather than try to look for a way out. The solution is not to have a magic tool that allows you to poorly work around the problem until it doesn't.
thewhitetulip 10y ago
Jumping to a framework without understanding how internals work is a bad thing. Also, experience is everything, eventually you'll get a hang of it. It is not a barrier, you might like the intro book: http://github.com/thewhitetulip/web-dev-golang-anti-textbook/ http://github.com/thewhitetulip/web-dev-golang-anti-textbook... and https://github.com/astaxie/build-web-application-with-golang/ https://github.com/astaxie/build-web-application-with-golang...
randomdata 10y ago
I'd suggest no. If Rails is the right tool for the job, there is no reason to not use Rails. If Rails is not the right tool for the job, reimplementing Rails on top of Go isn't going to make it the right tool. It is possible that some future "killer app" will emerge out of the Go ecosystem like Rails did with Ruby, but the effort to build something like Rails to duplicate Rails is not a particularly good use of someone's time.

mixedCase 10y ago

Doing ORMs and auth without knowing what you're doing imply a huge risk out of itself, which Go tries to avoid. If you have relational data the solution is not to use an ORM to half-abstract it away, it's to learn SQL. ORMs can be useful tools to avoid boilerplate, but they will show their ugly internals when SHTF, and those are always harder to understand than plain SQL. As for auth, it's very easy to add to any web application or HTTP API using one of the many middleware solutions out there.

aikah 10y ago
> Doing ORMs and auth without knowing what you're doing imply a huge risk out of itself, which Go tries to avoid. And implementing it yourself the wrong way is also a huge risk.
- mixedCase 10y ago
  Exactly the point I explained. You have to learn how it's done rather than try to look for a way out. The solution is not to have a magic tool that allows you to poorly work around the problem until it doesn't.

thewhitetulip 10y ago

Jumping to a framework without understanding how internals work is a bad thing. Also, experience is everything, eventually you'll get a hang of it. It is not a barrier, you might like the intro book: http://github.com/thewhitetulip/web-dev-golang-anti-textbook/ http://github.com/thewhitetulip/web-dev-golang-anti-textbook... and https://github.com/astaxie/build-web-application-with-golang/ https://github.com/astaxie/build-web-application-with-golang...

randomdata 10y ago

I'd suggest no. If Rails is the right tool for the job, there is no reason to not use Rails. If Rails is not the right tool for the job, reimplementing Rails on top of Go isn't going to make it the right tool. It is possible that some future "killer app" will emerge out of the Go ecosystem like Rails did with Ruby, but the effort to build something like Rails to duplicate Rails is not a particularly good use of someone's time.