Recently stumbled upon your videos Robby and I have to say you've got great content! I've tasked myself with learning a new language and chose Go and your videos have been super helpful to get me started. Definitely looking forward to anything else you drop on RU-vid. :)
please create more Golang videos. I reallly like the way you jus open the docs and figure out like normal dev and make mistakes. It helps us to procastinate less over random errors.
I was looking for a replacement for NodeJS and was checking out Rust frameworks for a whole day (rocket, actix..) and was scared off 14 minutes in here and I'm convinced to give Fiber a shot, thanks for the rapid fire examples, good stuff
Hey! Have you eventually stick with Fiber or did you find something else? I'm looking in the direction of Go and its ecosystem to figure out good alts to NodeJS too. I also wish if Rust wasn't that cryptic...
The first video I watched from your channel I saw you explaining go stuff using Gyn. then I watched the second and there you were using fiber... so I questioning about why he changed the tool? and here the third one you explained. thank you a lot for this! btw I will change too your points are well explained. :)
Heyy, very useful. Thanks for this video. I was just looking sth similar to Nestjs. Fiber looks nice. How about creating some thematic videos? Config management, authentication etc. in Fiber app?
Good video. I loved fiber, but my go to now is always chi cause they follow the standard library which make it easier to plug lot of other library. But yes fiber perf is crazy, I used it in one production project and its day and night vs old node server.
Question : how useful is a benchmark, if the publisher does not provide informations to fully reproduce (re-run) the tests ? Especially for a web app framework, it is probably thé easiest performance tests kind to reproduce. And you know, when thé publisher tests his own product and Comes to thee conclusion his own product is thé best on thé market, .... It sounds like Africa newspapers
Nice!! Which one is the most common way to deploy a Golang project? I am used to deploy projects with Docker because I worked many years with Java, so I am not sure which are the standards in Golang
Golang and Docker is a dream team - well, Docker is written In Go, so no wonder. I have also been using podman for smaller deployments or even Go apps running as systemd services. Since you only have one binary, it is pretty easy to deploy and run Go in a container or as a service.
One of the things that's been a real bummer for me is the lack of any kind of feature like gin's c.Abort() in fiber's context. There's a good chance I'm just stupid, but I'm writing uglier code because of it; having to explicit error handling in the main route handler function instead of just throwing a immediate response if the error occurs in a child function :(
Use middlewsres, period. I'm not fan of such pattern as coming from symfony stack but frameworks do provide different mechanisms to handle critical errors in different ways. Fiber using middlewares to pass on layers of the stack, it has builtin Recover middleare to handle panics and any other errors. Regardless of language, concepts of error handling remain almost the same across languages as they tend to copy each other and become homogenous after a few years. Learn concepts, not code - it helps understand why such design pattern was utilised there.
Great video. BTW in framework benchmark you forgot to search aspnetcore (which was the original reason you landed on page) which is number 7 so faster than fiber as well. So .NET is quite faster than Go.
In Fiber you can use this to return data and status code in one line: c.JSONWithStatus(user, fiber.StatusOK) which is equivalent of: c.Status(fiber.StatusOK) c.JSON(user)
Because in fact Express, Fiber or Gin aren’t real frameworks but libraries, you can use them inside your own framework or infrastructure. Laravel is a real framework that comes with everything you need to develop a website, so naturally, it has to provide full documentation, but we don't do that in libraries.
