I will simply point out that go seems to be alone in this regard. All other languages that I know and have used have embraced the idea that it's OK to assemble various functionalities in a useful framework which one can deploy without too much effort.
On Monday, September 11, 2017 at 2:18:54 PM UTC+12, Shawn Milochik wrote: > > On Sun, Sep 10, 2017 at 10:05 PM, Tim Uckun <timu...@gmail.com > <javascript:>> wrote: > >> >> I understand the sentiment but I am really confused by this advice. Are >> you saying I should write everything myself? My own CSRF implementation, my >> own authentication scheme, my own rate limiter, my own jwt implementation, >> my own logger etc? If that's the case I'll be honest and say I won't build >> this thing in go. >> >> If that's not the case and it is OK to go to github, do some research, >> read all the readmes, and then try and assemble a pack of libs written by >> other people into my own framework well that too seems a little >> unreasonable to me. Surely somebody has done the work and already put >> together a solid stack which is known to be of decent quality and works >> well together. >> >> One last point. When you assemble parts together yourself the thing that >> is most likely to be painful is getting help. Many of the projects on >> github don't have mailing lists so you have to communicate via tickets >> which I find to be cumbersome. Some very popular projects I have looked at >> have over 100 open tickets most of which don't even have acknowledgements >> that the author read the thing. If you ask for help the answer will >> probably turn into a finger pointing exercise because the author may think >> it's some other part of the stack that's causing a problem. With a >> framework you only have one place to ask for help. >> >> > No, nobody is telling you to write your own CSRF, authentication, rate > limiting, etc. You can if you want to, or if you think it's a good use of > your time, or you're unhappy with existing implementations. > > No, nobody is telling you to assemble your own framework, either. That's > the whole point. Use *no* framework. Just write your code and plug in > bits as needed. That's the Go way. Embedding, not inheriting. > > Yes, assemble bits from other small projects. Wouldn't you rather have a > database driver from a database expert, an authentication system from a > security expert, and no restrictions regarding which you can mix and match? > > As for who you can complain to when things don't work, all I can say is > that if you're a programmer, you're responsible for your own code. If you > want someone else to be responsible for it, then hire someone to write it > for you. I don't say it this way to be offensive. It's the simple truth. > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
