I wrote "It may be useful in some cases", "it" referring to Generics. So I guess we agree on this point.
Compare the default to github.com/stretchr/testify/assert and you will see what I mean
I know this lib (using it in the past), and I exactly know what you mean. But I still disagree on this point. Assertion reduce test code verbosity, but doesn't really improve readability. here is an example from one of my pet project. I do not think the usage of assertion will bring a lot of value here.
But the most important is that it is not considered idiomatic to do so in Go. Some articles on the subject here and here.
That's precisely the reason why I still use assertion in Javascript, Java or Ruby, event if I don't find them useful as much as I used to.
Thanks for your inputs they are indeed valuable
Thank you too :)
using the right tools for the right job
I definitely agree with that sentence. And my reaction is mainly drive by the will to show that Go may be a good choice for a web application. It is very opinionated and may look ugly, but is eventually very effective and productive in that use case.
With it's GC and embedded Runtime, Go is more closed to many web-backend plateform than it looks like on the first sight :).
I was talking about the readability of the error messages printed during assert failures. The default way is not very readable whereas this lib provides a nice view with a diff, which IMO is really useful to spot issues.
I would still be open to building web backends for microservices using Go, but for full-fledged real-world web apps how would you handle stuff like security, filters, etc, etc(say stuff provided by spring framework). I have to agree maybe I might be more open if I see a real example of that.
For example, I was thinking about doing a version of JHipster app in Go but then wasn't sure it's worth the effort
The first is to used the (very good) lib gorilla which provide a full featured http router with many security options (secured cookies, sessions, CSRF protection, etc...). Not the option I prefers, but a very convenient and common one. If you wish to support Go with JHispster, this is the way to follow I guess.
The second is to use the basic http router and to choose the lib you want to use (JsonWebToken, CSRF, etc ...) for security.
The http package is build in a way that make trivial to create filters (by chaining http.Handler or http.HandlerFunc).
I prefers using that way because I prefer to add explicitly security layers.
For SQL injection, the sql package provide automatically a protection against it, as long as you use parameterized requests with Exec() or Query().
You may notice that I am not against the use of dependencies :). Cryptographie and security are domains where I want to rely on a maintained, specialized libs.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I wrote "It may be useful in some cases", "it" referring to Generics. So I guess we agree on this point.
I know this lib (using it in the past), and I exactly know what you mean. But I still disagree on this point. Assertion reduce test code verbosity, but doesn't really improve readability. here is an example from one of my pet project. I do not think the usage of assertion will bring a lot of value here.
But the most important is that it is not considered idiomatic to do so in Go. Some articles on the subject here and here.
That's precisely the reason why I still use assertion in Javascript, Java or Ruby, event if I don't find them useful as much as I used to.
Thank you too :)
I definitely agree with that sentence. And my reaction is mainly drive by the will to show that Go may be a good choice for a web application. It is very opinionated and may look ugly, but is eventually very effective and productive in that use case.
With it's GC and embedded Runtime, Go is more closed to many web-backend plateform than it looks like on the first sight :).
I was talking about the readability of the error messages printed during assert failures. The default way is not very readable whereas this lib provides a nice view with a diff, which IMO is really useful to spot issues.
I would still be open to building web backends for microservices using Go, but for full-fledged real-world web apps how would you handle stuff like security, filters, etc, etc(say stuff provided by spring framework). I have to agree maybe I might be more open if I see a real example of that.
For example, I was thinking about doing a version of JHipster app in Go but then wasn't sure it's worth the effort
There is two possibilities here.
The first is to used the (very good) lib
gorillawhich provide a full featured http router with many security options (secured cookies, sessions, CSRF protection, etc...). Not the option I prefers, but a very convenient and common one. If you wish to support Go with JHispster, this is the way to follow I guess.The second is to use the basic http router and to choose the lib you want to use (JsonWebToken, CSRF, etc ...) for security.
The http package is build in a way that make trivial to create filters (by chaining
http.Handlerorhttp.HandlerFunc).I prefers using that way because I prefer to add explicitly security layers.
For SQL injection, the
sqlpackage provide automatically a protection against it, as long as you use parameterized requests withExec()orQuery().You may notice that I am not against the use of dependencies :). Cryptographie and security are domains where I want to rely on a maintained, specialized libs.