Earlier quoted context omitted.
The further problem is the resulting community. Interviewing for Go devs is going to become a pain.
> Interviewing for Go devs is going to become a pain Might I ask why?
Wheat from chaff.
Buffalo – MVC Web Framework for Go
31–40 of 46 posts
Re: Buffalo – MVC Web Framework for Go
#32Earlier quoted context omitted.
Nothing can be omakase in Go. The language disallow it, unless you completely opt out of its type system. But then, what's the point of using a statically typed language? Go is built in a way that forbids writing abstractions. When I say forbid it really does forbid it. Even C is more expressive. Buffalo isn't a framework, unless a router + few bells and whistles is now considered "framework".
Go is built in a way that forbids writing abstractions. There are lots of abstractions in Go - e.g. structs, interfaces, goroutines, channels. It may not have all the abstractions you're used to (e.g. inheritance, generics), and might still be lacking in areas, but your statement is extreme hyperbole and not useful. As to whether something is a framework or not, why is this important to you?
Not op, but a framework vs toolkit is important to me. I like the gorilla toolkit because I can easily take parts or leave them or create them. I've not investigated buffalo, but the term framework instantly gives me a bad taste in my mouth. When I think of a framework, I think "our way or they highway" and the very moment you need to do something a bit different than what the framework expects or assumes, you are in for a world of hurt.
Re: Buffalo – MVC Web Framework for Go
#33It tries to install webpack globally which it can't because I'm not running it with sudo and I have it installed already anyway. I see I can skip adding webpack to the app but can I just skip the installation part?
Re: Buffalo – MVC Web Framework for Go
#34Sounds like Buffalo is omakase?
Explanation on "omakase"? I haven't heard that term before and Google only provides sushi restaurants nearby...
Re: Buffalo – MVC Web Framework for Go
#35Sounds like Buffalo is omakase?
Explanation on "omakase"? I haven't heard that term before and Google only provides sushi restaurants nearby...
Was a reference to this post: http://david.heinemeierhansson.com/2012/rails-is-omakase.htm... where Rails is described as a curated set of defaults/components/tools/options.
Re: Buffalo – MVC Web Framework for Go
#36Love the JQuery + Webpack defaults!
The main issue I ran into when trying to develop a web app with Go was debugging. Web apps are multi-tier systems, and Go doesn't give you stack traces when something goes wrong, which is something I don't have the patience for when there are plenty of good and mature languages to use that do have stack traces. I know a common response to this is, "just practice better system design," I'm not one of those people who believes that I need to define an API for every internal piece of code. I just want to be able to find an error quickly and move on. Does Buffalo have a solution to this? I really like it so far.
Re: Buffalo – MVC Web Framework for Go
#37Go is such an easy language as it is, these kinds of frameworks just encourage amateur developers to skirt by with minimal understanding of what they're really doing. An MVC framework sounds like a great personal hacking project for fun, but I would beware of advertising anything like it for professional use.
What's so wrong with getting productive faster. Learning takes time. It is not very hard to write Go web apps with the standard library, but it may be more convenient to use a framework for the sake of time.
It is an assumption that amateurs will defer learning due to the framework. It also seems as though there is another assumption that all the people using this framework are somehow amateurs. It is convenient to be able to write a quick program using a framework and then being able to scale that project as it grows.
Re: Buffalo – MVC Web Framework for Go
#38Earlier quoted context omitted.
> Interviewing for Go devs is going to become a pain Might I ask why?
Wheat from chaff.
I am sorry, I still didn't get your concern. It is easy in my opinion to identify the person writing Go code. Look at their Github profile! (I am not a recruiter, so I don't know how effective that really is, but Github profile does reflect a person's contributions to FOSS and if the person is a FOSS contributors, look at their repos or their other PRs or their projects)
Re: Buffalo – MVC Web Framework for Go
#39Earlier quoted context omitted.
> with minimal understanding of what they're really doing In my opinion, this is very dangerous. It is always better to understand the inner workings and then write an app, otherwise you just feel you have accomplished something when, in reality, it was just the framework you used and you didn't learn. I am saying this out of experience, when I used to use Django, I didn't understand the difference between GET vs POS…
Good points. And btw, Thanks for those links to your works in Go.
You are welcome :-)
the response struck a chord with me because a few years ago, I was just like the author suggested, someone who didn't know how to build a webapp and tried Django etc. Thus, I strongly that we need to understand the basics first.
Re: Buffalo – MVC Web Framework for Go
#40Earlier quoted context omitted.
Depending on how micro your microservice is and if it really is high volume (not sure what high volume means to you) then I would recommend just stick with the standard library to start and grabbing other libs as you need. I wrote a simple internal microservice handling ~400k req/s at peak with no framework and it works great. I can see the appeal of the framework in getting something up and running really fast with…
We know that standard library is enough But there is always need for a framework if you do the same thing over and over again. The consensus in the GO community seems to be that you create from scratch every-time the same handlers, utilities etc. And practically we have ended up with everyone having their own in-house framework. There is nothing wrong with not wanting to create the same helpers every time or not want…
Saying that the standard library is all you need is
like saying that you don't need the standard library
either, Go's Keywords are all you need.