Slightly off-topic question. What are you using to do the rendering and validation of forms in a "Django like" way in Go? I have a half-backed system build using the ideas coming from Django but I wonder if something a bit more robust exists.
My impression is that more and more people are just submitting forms a JSON through an heavy weight app to an API end-point and less people are using forms "the old way". So, if some "old people" have some pointers for another "CGI old dev", I would really enjoy them!
Just start with the standard library and you will be OK, in Go there is rarely a _need_ for some kind of framework to get going as I assume it is in JS.
I work with go for years but never used a fw. At the beginning when i came from php, i looked for fw because that was how things were done. But once i let go of that idea and started making things by hand i never looked back. Go really does not need a framework. Sooner or later it starts to limit you. For example i used grpc a lot in the past but came to realize it was hindrance and now i just use proto files to define schemas and generate the structs but that's is all it does. Everything else is hand-made. I even moved away from SQL abstraction and just use sql and directly. Again, sooner or later there will be some limitation that will bother you and so it is just not worth it. And being able to tailor-made every part of the application for its desired purpose is priceless.
Same here. It doesn't work in Golang world. I stopped using ORMs (especially GORM), realized it's completely incompetence in generating SQL queries. It doesn't worth it, just another bounds.
The readme doesn't seem to mention or list what libraries this depends on, it has chi and jet at least based on the structs section.
Given this "framework" is predominantly a collection of other people's (usually apache/mit) work, where is the BOM/licence text including all of the dependencies?
And why has the author attempted to licence their likely sub 100 lines of glue code under the GPL?
I don't see the point in using something like this which is basically a prefilled go.mod with some other files with a pretty stock organization.
I've used Pagoda (https://github.com/mikestefanello/pagoda) in the past which makes a show of displaying its nature as a wrapper around a bunch of community libraries, and is documented as such. They also make effort to document the interfaces for each component so you could easily replace them with your own implementations to avoid getting stuck due to the "framework". This is my preferred approach for all of these "starters" now since using pagoda.
I suspect most library authors who are happy with others using their work, are probably somewhat okay with the standard file pointing to their original work as attribution.
classic hacker news comment. demean the work as if it’s beneath you. i know you know enough github to see this is more than 100 lines of glue code. why even comment if only to shit on someone’s work? want to share pagoda? submit a link for it
In the Python world, most docs give a couple of usage examples but no type information (at best it will usually tell you that an argument is “a file-like object” with no information about what “file-like” methods are required). Moreover, Sphinx just renders everything onto one giant page so you have no idea which class a given method belongs to without doing a bunch of error-prone scrolling (sqlalchemy was the worst because every class had the same method names).
I will take Go docs all day, every day over Python docs.
I’ll take the Go doc over Python documentation any day. Python docs are really worst in class, completely unreadable and useless when you want to do anything precise.
This having the GPL license is an interesting choice. If I understand licenses correctly (I am not a lawyer), integrating this into your code, will instantly cause your website's source code to become open source.
That seems like a non-starter for almost every major usage, to me.
IANAL. I think that your assessment is correct in the consequences but not in the letter: your source code does become GPL but if you don't distribute the binary and only use it on your servers nobody is entitled to ask you the source code. That would happen with the AGPL license.
Same thing if you make changes to Ghostly itself and don't distribute the binary. Those changes are GPL but you can keep them to you.
If you are working for customers and the IP of the software is yours but the servers are theirs, that is an act of distribution and the source code must be available. For sure customers can ask for it because binaries are distributed to them, maybe everyone else can ask it too. This is the same as GPL code on set top boxes or other devices.
If the contract states that the IP belongs to the customer, the source code is theirs but nobody else is entitled to ask for it because there is no distribution.
This is not the case for backend applications. The license you want to be aware of that does this to backend services is the AGPL. Which indeed for some is a non-starter.
The GPL is very clear when it states "For example, if you distribute copies of such a program, whether gratis or for a fee, you must pass on to the recipients the same freedoms that you received."
> The Free Software Foundation states that, without applying the linking exception, a program linked to GPL library code may only be distributed under a GPL-compatible license. This has not been explicitly tested in court, but linking violations have resulted in settlement.
So yes, what constitutes "copies of such a program" does include how it's been compiled/linked.
Go isn't polymorphic enough as a language to achieve something akin to JEE, Rails, Django or Laravel, so these "go frameworks" will have hard time encapsulating the complexity of underlying libraries they might use. All the former use either an IoC container, or their own flavor of "module loading". This is absolutely not practical in Go.
Of course, dependency injection is possible, explicitly, but can hardly be generalized an efficient way, so the plumbing will always be explicit, because the underlying lib types will always leak.
So it's not so much that there is no value in frameworks in Go, it just hard to write actual web frameworks in that language that would be useful.
My impression is that more and more people are just submitting forms a JSON through an heavy weight app to an API end-point and less people are using forms "the old way". So, if some "old people" have some pointers for another "CGI old dev", I would really enjoy them!