It seems like you are trying to fit everything onto this one choice. This is never a good choice. One should chose technology or stack correcponding to the porblem needed to be solved. Not vice versa.
If you need a tool such as Django - you should use one and use Go (both here are for sake of example) for some small tasks, where it can give the most.
Building a new "fat" framework just because you like the langauge is kind of strange approach.
So in your opinion I should switch to a whole different language/stack?
Who said building a fat framework since I liked the language? That's your words no one else's.
Sometimes a fat framework is needed.. period. And if you need a fat framework it doesn't mean that you should switch to Ruby or Python, because in your opinion these are languages for building fat frameworks.
BTW: python programmer for more than a decade. I've been in need for both micro and fat framework in my career. I still don't get your argument.
>So in your opinion I should switch to a whole different language/stack?
In my opinion one should use appropriate tools when building a solution. Using a number of languages or tools that are appropriate for the task is not only normal, but actually gives you better results anytime of the day, not to mention freedom of choice, compared to when you are stuck with "one big thing"
>Who said building a fat framework since I liked the language? That's your words no one else's.
>Sometimes a fat framework is needed
Okay, so name some of the reasons, otherwise mine assumption is only logical. I, personally, can't see any reasons why would you need a fat framework that has to be written in Go and not in Python/Ruby/Java or something else. Seriously, why?
>BTW: python programmer for more than a decade. I've been in need for both micro and fat framework in my career. I still don't get your argument.
My argument is that if you need a fat framework - this does not mean it has to be in some specific language. You have something like a counter argument? Please share.
> My argument is that if you need a fat framework - this does not mean it has to be in some specific language. You have something like a counter argument? Please share.
I can't fathom how you can't think of counter arguments.
- Because a company invested in Go?
- Because they wouldn't want to have to maintain a lot of different technologies/languages, unless it's really necessary?
- Because a fat framework in Go is going to be lighter than a fat framework in python/ruby? (memory reqs, cpu, servers, etc)
- Because Go is easier to reason with/maintain in large codebases?
And still, right now I'd choose python, but I can't understand how someone would hold such strong opinions in such matters. Maybe I've seen too little in my career? Or have I seen too much, so as to not jump in such strong positions so easily? Genuinely curious and that's why I started this thread.
I hardly can imagine a company that had invested only in Go and will need fat Go gramework. Seriously.
>Because they wouldn't want to have to maintain a lot of different technologies/languages, unless it's really necessary?
Not a lot of, but a number - once again, pretty hard to imagine something serious going on here. And startups will hardly chose Go as their starting point for obvious reasons.
>Because a fat framework in Go is going to be lighter than a fat framework in python/ruby? (memory reqs, cpu, servers, etc)
Absolutely not necessary. You can build framework in C and had results that will make you sad compared to that of Python. But even if it is - most likely it will be more expensive and you will have to make a choice. But okay, let's say it has some point.
>Because Go is easier to reason with/maintain in large codebases?
How so? In comparison to Python, for example.
>I can't understand how someone would hold such strong opinions in such matters
Hey, I'm not saying people shouldn't write fat Go framework, or stop doing if they've started already. If stars are lit - it means there is someone who needs it. I just don't get why would you use something like Go for this.
>I hardly can imagine a company that had invested only in Go and will need fat Go gramework. Seriously.
I don't know how to reply to this because I really don't see what's hard to imagine, but ok.
> And startups will hardly chose Go as their starting point for obvious reasons.
Well that's obviously false, or you haven't been paying attention to HN, or job listings :P
> How so? In comparison to Python, for example.
Static typing. In the case where you'd like to counter that point, I'm sincerely sorry, I'm tired of arguing over that point. I'd prefer if we left it at that and say "we agree to disagree".
> Hey, I'm not saying people shouldn't write fat Go framework, or stop doing if they've started already. If stars are lit - it means there is someone who needs it. I just don't get why would you use something like Go for this.
Fair enough. Sometimes I just like to elicit responses in order to gain new perspective/POV etc.
It's not really all that controversial of an opinion to say that no one needs a fat framework in 2016. It's much easier and nicer and more maintainable to use a collection of small tools than one monolithic solution.
I think people choose frameworks because they _prefer_ them instead of _needing_ them. If you think you _need_ a framework you need to reevaluate your programming skills.
So if my language of choice is Go, you can somehow guarantee that I won't need a fat framework? How?