4 ms·

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 l

by q3k 7y ago

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.

tmpz22 7y ago
Beginner's rite of passage: 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.
- ascales 7y ago
  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.
alharith 7y ago
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.
nevir 7y ago
Ironically, express came to Node from Ruby's Sinatra much the same way.
throw_m239339 7y ago
> 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.
deleted 7y ago
[deleted]
JyB 7y ago
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. > This project is full of `interface{}` Oh boy.

by q3k 7y ago

tmpz22 7y ago

Beginner's rite of passage: 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.

ascales 7y ago
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.

alharith 7y ago

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.

nevir 7y ago

Ironically, express came to Node from Ruby's Sinatra much the same way.

throw_m239339 7y ago

> 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.

deleted 7y ago

[deleted]

JyB 7y ago

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. > This project is full of `interface{}` Oh boy.