I love Go, I think it is the best language for backend development in 2022, but it is not without its issues. twitter: / benjamin41902 insiderviz: www.insiderviz...
I like error handling in go. It's one of the languages where devs cant abuse throwing and catching errors as a "goto" statement. Also, it sort of makes you deal with errors as soon as they appear.
Speaking of error handling, we can create a simple function check: func check(err error, msg string) { if err != nil { log.Fatalf("%s: %s", msg, err) } } and then instead of the normal if err == nil, we can just do result, err := doAction() check(err, "doAction went wrong") (you can delete the whole second argument thing and have just check(err) for more simplicity) However I still kinda like the way for example Rust does this, where I can just do .unwrap() and it segfaults on error, and if I want do do some error handling or default values, I can do something like .ok_or("my default string"). In Go I can't even put function calls as arguments, because if function A takes argument of type T and function B returns (T, error), then I can't do just A(B()), I have to do resB, err := B() A(resB) to achieve exactly the same. :(
I've been programming since I was 13 in 1983 - I've programmed in BASIC, C, C++, Java, Python, Javascript, Rust and Go - and Go is by far the best in so many ways. Its concurrency model is just so easy, no async/await keywords! I love programming in Go, code you wrote 6 months ago is easily readable. Try that with Rust!
if err := foo(); err != nil { return err } I am so used to this way of handling errors. It's very intuitive which method returns err and will you have to handle it.
I'm new to Go so I don't know if it's the right way to do it but I usually just declare a function that checks for errors & call it everywhere that could throw an error...
As a beginner go dev i spend lot of time is on changing the structure of the project. Even though things work i'm not sure it is the optimal way to do it. Other than that i really like go.
It took me a while to get an idea of how I liked to do things and tbh I still change my mind all the time. There is no one way to do things so just do what you think is good then learn from it when it inevitably is not perfect
For me I do a good core structure and when I implement some new bigger feature I have to overthink the structure anyway and make it better. The nice thing is: Refactoring is pretty easy and straight forward.
Not sure about error handling. For years, exceptions have been abused and wrongly used as flow control in most other languages. It is terrible and also not performant. This way you are forced to deal with errors immediately.
Anytime you have a use case that would have to do tons of loops/compute that would also benefit from concurrency. An example could be calculating the maximum value in 15 different CSVs at once, aggregations of that nature. Insiderviz is a good example
@@bmdavis419 I’m working on an app that calculates the stock value of a user’s portfolio every time their portfolio or the stock prices update. Do you think it’d be better building this in Express or Fiber?
@@ahuman32478 That sounds like a background worker type thing to me. If you are comfortable with it I would go with Fiber, but you could get away with express. (Although if you go with Express use Fastify instead)
I build an error.go file on package called helper: package helper func PanicErr(err error) { if err != nil { panic(err) } } And call it like this: err := someCode helper.PanicErr(err)
that is a pretty cool solution actually, personally I like throwing them all the way up to main() so that I can have one central way of error handling, but you could basically get that here by replacing panic
I like error handling in go. It's one of the languages where devs cant abuse throwing and catching errors as a "goto" statement. Also, it sort of makes you deal with errors as soon as they appear.
I had not thought about it that way, that's a good point
You should check out error handling in Rust, way better imo
@@HereIsZaneya but its rust...
Speaking of error handling, we can create a simple function check:
func check(err error, msg string) {
if err != nil {
log.Fatalf("%s: %s", msg, err)
}
}
and then instead of the normal if err == nil, we can just do
result, err := doAction()
check(err, "doAction went wrong")
(you can delete the whole second argument thing and have just check(err) for more simplicity)
However I still kinda like the way for example Rust does this, where I can just do .unwrap() and it segfaults on error, and if I want do do some error handling or default values, I can do something like .ok_or("my default string"). In Go I can't even put function calls as arguments, because if function A takes argument of type T and function B returns (T, error), then I can't do just A(B()), I have to do
resB, err := B()
A(resB)
to achieve exactly the same. :(
I've been programming since I was 13 in 1983 - I've programmed in BASIC, C, C++, Java, Python, Javascript, Rust and Go - and Go is by far the best in so many ways. Its concurrency model is just so easy, no async/await keywords! I love programming in Go, code you wrote 6 months ago is easily readable. Try that with Rust!
quite the praise!
if err := foo(); err != nil {
return err
}
I am so used to this way of handling errors. It's very intuitive which method returns err and will you have to handle it.
I'm new to Go so I don't know if it's the right way to do it but I usually just declare a function that checks for errors & call it everywhere that could throw an error...
Go is basically C for the web. If you code it right it’s not going to be the bottle neck.
Thanks for the videos, next time please make the text bigger. I’m watching this in bed and struggling to read what your coding lol
I realized as soon as I uploaded it that I forgot to zoom in, will make sure to do it next time!
I approve this message!
As a beginner go dev i spend lot of time is on changing the structure of the project. Even though things work i'm not sure it is the optimal way to do it. Other than that i really like go.
Honestly, just don't overthink it. If it works for you, then it's fine. There is no such thing as "perfect" structure.
It took me a while to get an idea of how I liked to do things and tbh I still change my mind all the time. There is no one way to do things so just do what you think is good then learn from it when it inevitably is not perfect
For me I do a good core structure and when I implement some new bigger feature I have to overthink the structure anyway and make it better.
The nice thing is: Refactoring is pretty easy and straight forward.
Not sure about error handling. For years, exceptions have been abused and wrongly used as flow control in most other languages. It is terrible and also not performant. This way you are forced to deal with errors immediately.
This is a very good point, idk the error handling is something I keep going back and forth on
Golang snippets, ier
error handling would be good to make like in Vlang, func() or { // here is code if error happened }
What would you consider to be a CPU-Intensive app use case for Go?
Anytime you have a use case that would have to do tons of loops/compute that would also benefit from concurrency. An example could be calculating the maximum value in 15 different CSVs at once, aggregations of that nature. Insiderviz is a good example
@@bmdavis419 I’m working on an app that calculates the stock value of a user’s portfolio every time their portfolio or the stock prices update. Do you think it’d be better building this in Express or Fiber?
@@ahuman32478 That sounds like a background worker type thing to me. If you are comfortable with it I would go with Fiber, but you could get away with express. (Although if you go with Express use Fastify instead)
@@bmdavis419 So would you consider this use case computationally intensive?
@@ahuman32478 Depends on the side of the data and the algorithms using, if u end up with n^3 stuff then for sure use Go
I build an error.go file on package called helper:
package helper
func PanicErr(err error) {
if err != nil {
panic(err)
}
}
And call it like this:
err := someCode
helper.PanicErr(err)
that is a pretty cool solution actually, personally I like throwing them all the way up to main() so that I can have one central way of error handling, but you could basically get that here by replacing panic