IMO if you're coming to Go from Node.js, you're much better off spending the extra time learning `net/http` (which is much more idiomatic and will teach you a lot about the language itself) than clinging onto impedance-mismatched patterns from Node.js.
This project is full of `interface{}` (sacrificing type safety for cuteness and magic), has a very weird prefork system (which actually breaks Go's concurrency model) and doesn't even use godoc (which is one of the nicest developer productivity aspects of Go). I would say it can do more harm than good to people new to Go.
1. fmt.Sprintf("Why doesn't %s have %s?\n", language, feature)
2. fmt.Sprintf("Builds %s in %s\n", feature, language)
3. fmt.Sprintf("Realizes %s actually sucks in %s and there are some good reasons nobody built it in the first place\n", feature, language)
Generally I think it's awesome people go down this path because sometimes really cool things are built as a result, but when the project in question overlaps with on-boarding from another tool, its is rife for another beginner to adopt it and get it stuck in production just because they wanted a slightly quicker transition from their former toolchain.
I had this exact experience with Go. I'd ask myself, why is this not more like {{otherLanguage}} and I'd install a package to solve the problem I thought I had. Really, though, it turned out that most things I saw as problems with Go aren't really problems at all, and I just needed to explore the ecosystem a bit more.
In one of the issues, you can get a sense of the motivation behind the project:
> Fiber started as a personal project to be able to rewrite all my node apps into Go.
I tried to stick to the same workflow as Express by using interfaces, this is indeed not the Go standard.
But yeah, unless you want to do the same, I agree this project can definitely do more harm than good to new Gophers. It's awesome to do it as a personal experimentation and see if it can be done, but it's another thing to attempt to sell it to others as a good idea.
> IMO if you're coming to Go from Node.js, you're much better off spending the extra time learning `net/http` (which is much more idiomatic and will teach you a lot about the language itself) than clinging onto impedance-mismatched patterns from Node.js.
IMO even if you are using NodeJS, it's best spending some extra time actually learning the http module and only brings the pieces you really need, like a cookie parser, a body parser...
"URL routers" are convenient, but also highly overrated.
> This project is full of `interface{}` (sacrificing type safety for cuteness and magic), has a very weird prefork system (which actually breaks Go's concurrency model) and doesn't even use godoc (which is one of the nicest developer productivity aspects of Go). I would say it can do more harm than good to people new to Go.
Let's not however do a Martini 2.0. Let's keep criticism cordial this time instead of chasing away unorthodox library authors with public shaming. That episode was a black mark on the Go community. Not specifically talking about the parent comment however.
This is such a true statement.
Times and times again I always struggle to see the benefits of any "web framework" in Go. (Or any "framework" for that matter..)
Projects like these are traps for newcomers.
Still, I'm not denying that it probably was a big learning experience for the author. Kudos to him for diving in and giving it a go.
app.Get("/", func(w http.ResponseWriter, r *http.Request) {
w.Write([]byte("Hello World!"))
}) //chi
There are so many micro web frameworks in Go that follow almost exactly the same pattern. It's hard to see how Fiber is substantially different.
Fiber also uses the empty interface a lot in its code. For example, app.Get() just takes `args ...interface{}`. By contrast, Gin's app.GET() takes `relativePath string, handlers ...HandlerFunc`. You know what Gin is expecting you to pass in.
Personally, I would not approach Go from the same mindset as Node.js. It's great that people do, and explore that paradigm, but it's not my preference.
I write raw Go fronted by Chi when I need to write APIs in Go. I never write web applications in Go; it's usually a mix of things, and often a Laravel app consuming a Go backend.
I'm offering this commentary solely as a point of reference and not a condemnation or judgment of others' patterns.
There are no API docs for this project except for the name of the function on each function to make the linter happy and think there are docs. That's enough of a red flag that it's probably not worth digging in further for me. If they're not using the standard documentation mechanisms, what else aren't they doing?
This looks like..javascript. If you need pretty routing you may use gorilla mux. There are actually quite a few http routers written in idiomatic Go. Why would you use that node-like crap, except unless you try to do a 1:1 rewrite of a node app?
Maybe this can improve your development efficiency for the moment, especially for those who new have switched from Node.jS to Go. But you may not be able to use Go's patterns in many language paradigms, so you can not use some of the advantages of the Go ecosystem. On the contrary, you bring Node.js'. In a way, this may limit you.
Looks like a good learning exercise project but goes against the Go best practice principle of using standard libraries wherever possible since I don’t see any real benefit of this library over using the `net/http` package.
This is exactly why I would learn it. It's exactly how I've learned (in depth) ALL of the 10-15 various languages I know. Start with something that's familiar and work backwards.
I hate the bullshit elitist crap like "oh don't learn that, you can't code in Go until you've learned x,y,z". Everybody learns differently. I learned jQuery before learning JavaScript.
I wish the people on this thread would stop assuming everyone is clones of them.
This project is full of `interface{}` (sacrificing type safety for cuteness and magic), has a very weird prefork system (which actually breaks Go's concurrency model) and doesn't even use godoc (which is one of the nicest developer productivity aspects of Go). I would say it can do more harm than good to people new to Go.
1. fmt.Sprintf("Why doesn't %s have %s?\n", language, feature)
2. fmt.Sprintf("Builds %s in %s\n", feature, language)
3. fmt.Sprintf("Realizes %s actually sucks in %s and there are some good reasons nobody built it in the first place\n", feature, language)
Generally I think it's awesome people go down this path because sometimes really cool things are built as a result, but when the project in question overlaps with on-boarding from another tool, its is rife for another beginner to adopt it and get it stuck in production just because they wanted a slightly quicker transition from their former toolchain.
> Fiber started as a personal project to be able to rewrite all my node apps into Go. I tried to stick to the same workflow as Express by using interfaces, this is indeed not the Go standard.
But yeah, unless you want to do the same, I agree this project can definitely do more harm than good to new Gophers. It's awesome to do it as a personal experimentation and see if it can be done, but it's another thing to attempt to sell it to others as a good idea.
IMO even if you are using NodeJS, it's best spending some extra time actually learning the http module and only brings the pieces you really need, like a cookie parser, a body parser...
"URL routers" are convenient, but also highly overrated.
> This project is full of `interface{}` (sacrificing type safety for cuteness and magic), has a very weird prefork system (which actually breaks Go's concurrency model) and doesn't even use godoc (which is one of the nicest developer productivity aspects of Go). I would say it can do more harm than good to people new to Go.
Let's not however do a Martini 2.0. Let's keep criticism cordial this time instead of chasing away unorthodox library authors with public shaming. That episode was a black mark on the Go community. Not specifically talking about the parent comment however.
Projects like these are traps for newcomers.
Still, I'm not denying that it probably was a big learning experience for the author. Kudos to him for diving in and giving it a go.
> This project is full of `interface{}`
Oh boy.
app.Get("/", func(c * fiber.Ctx) { c.Send("Hello, World!") })
app.GET("/", func(c * gin.Context) { c.String(200, "Hello World!") })
app.GET("/", func(c echo.Context) error { return c.String(http.StatusOK, "Hello, World!") })
app.Get("/", func(ctx iris.Context) { ctx.Write("Hello World!") })
app.Get("/", func(w http.ResponseWriter, r *http.Request) { w.Write([]byte("Hello World!")) }) //chi
There are so many micro web frameworks in Go that follow almost exactly the same pattern. It's hard to see how Fiber is substantially different.
Fiber also uses the empty interface a lot in its code. For example, app.Get() just takes `args ...interface{}`. By contrast, Gin's app.GET() takes `relativePath string, handlers ...HandlerFunc`. You know what Gin is expecting you to pass in.
I write raw Go fronted by Chi when I need to write APIs in Go. I never write web applications in Go; it's usually a mix of things, and often a Laravel app consuming a Go backend.
I'm offering this commentary solely as a point of reference and not a condemnation or judgment of others' patterns.
Gin has 1000s of production users right now. Please evaluate carefully before choosing one or the other.
Please evaluate carefully before choosing any Go web framework.
I hate the bullshit elitist crap like "oh don't learn that, you can't code in Go until you've learned x,y,z". Everybody learns differently. I learned jQuery before learning JavaScript.
I wish the people on this thread would stop assuming everyone is clones of them.