Golang Error Handling Is Better Than You Think!

► Join my Discord community for free education 👉 / discord
► Become a Patreon for exclusive tutorials👉 / anthonygg_
► Follow me on Twitter 👉 / anthdm
► Follow me on GitHub 👉 github.com/anthdm
In this Golang tutorial, I will show you that Golang's error handling is better than you think it is.
#golang

[@anthonygg_]

► Join my Discord community for free education 👉 discord.com/invite/bDy8t4b3Rz ► Become a Patreon for exclusive tutorials 👉 www.patreon.com/anthonygg_ Thanks for watching

[@badrbadr3793]

"if you like try-catch, you're dead inside and you don't realize it" That was the funniest shit i heard today lol

[@manfrombritain6816]

this is why i watch this channel 😂😂

[@muhammadfahad3483]

Learning code + jokes

[@goocarry_dailyroutine]

What a dangerous mix of pure programming experience and smth like standup comedy, best content I ever seen))

[@weironiottan7166]

Lol😂 this guy cracks me up, love it

[@hvaghani]

try-catch exception feels like something unexpected happened and everything is in panic mode until someone catches it. But in case of golang, it is smooth and peaceful. No need to panic if something didn't go as you expected. Go lang's error handling really changed my perspective about "it is really bad" vs "it's okay if it didn't work". For example, index out of the range is really bad, it should not have happened vs oh I couldn't write to the file because the file didn't exist. In other languages, both are treated as the same.

[@soyitiel]

Exactly. Even the fact of calling errors _exceptions_ hurts our ability to handle them corrently, treating them as if they were impossible to happen since they are just the exception to the rule, when in reality they are inescapable, just another of life's certainties

[@jed271]

People hating about golang's error handling are 99% coming from programming language that uses try catch

[@nefrace]

Came to Golang a half year ago from Python and JS and I actually like this way of error handling.

[@MarcelRiegler]

Or they know that try catch isn't the only alternative to error handling. Rust has the best error handling I have ever seen.

[@Rakstawr]

​@MarcelRiegler agreed, the optional is one of the features that I have heard the most requested

[@arminlinzbauer]

Wouldn't say I hate about them, but I was confused until I saw this video.

[@ninthsun]

@@MarcelRiegler indeed. Especially the idea of removing "null" from programming makes the program so much clear and error-less.

[@PandaMoniumHUN]

It's not about pattern matching, but about having the option to easily throw the error up to the caller. A lot of the times when you receive an error you'll just immediately return it because you do not want to handle it locally (it's the case for most libraries, let the user of your library decide what to do about the error). In that case your program is going to be full of "if err != nil { return err }" clauses. It's even worse if you call methods in your error recovery code that can also throw errors, because you'll even end up embedding error recovery clauses. In Rust you just put a "?" at the end of the line and in case of an error/none result you'll automatically throw it up, no need to spell it out in the code. Not only that but a proper Result/Error type allows you to do optional chaining, map to a different thing, etc. Having these dumb error values without proper error typing or even stack traces (which is critical for production applications), I don't see how this is better than any of the other alternatives.

[@bionichound3725]

This sums it perfectly. I stopped watching shortly after he claims he’s a programming god with billions of hours of code over hundreds of programming languages. I’m not opposed to verbose error handling, but go’s lack of macros make it such that cascading errors up the callers is such an annoyance (think of a web server that has a generic error handler middleware). You can still implement the monadic style chaining in go, but because it’s not a macro it won’t benefit from short circuiting when an error occurs. All in all, go’s error handling is fine. It’s not the worst (I prefer it over Python), but it’s not the best (rust is much better)

[@anthonygg_]

You the man

[@viktorshinkevich3169]

Chaining the successful path is the money here. Rust ? is just a sugar, but ability to focus and declare successful flow of execution makes it much easier to reason about the code. Anyone can create an Option type in Go using generics, but how to create a proper chaining without sum types? Rust Enum is where Rust is a killer from my perspective.

[@viktorshinkevich3169]

@@bionichound3725 > You can still implement the monadic style chaining in go How can you do that?

[@angeloceccato]

Go handling is better than exceptions, but zig, swift, rust also the elvis operator for early returns in kotlin are less verbose and noisy than "if err != nill { return err }" the Happy Path of function is ofuscated by each trivial error i don't want handle but propagate out. When i want propely handle the error "err!=nill" is ok. Then the nil handling in go is another topic...

[@ericng8807]

as long as it's not try-catch 👌

[@grise123]

i learned to love this, i love the explicity of things on golang , no tricks or some hacky things for me is good

[@athinodorossgouromallis7134]

Antony o have been working with java and JavaScript and started about 2 months ago to learn golang and then I stumbled on your videos because I had an idea a bit like Hollywood as an extreme scenario that fully takes advantage of goroutines in a microservice level. So hearing about errors being bad I kinda expected it to be bad trying to learn by building something with substance. Now starting to code a bit more I think the error handling is just great. Not only it forces us to deal with pants that have shit on like response grownups or ignore shit on pants... but also is so flexible that you can easily write "ensure" methods that can best handle that type of error and can be applied using interfaces. Thanks for voicing how I feel on the topic

[@minskiypeterburg3575]

I think the ugly part is not that functions return error values, but that you always have to check if err != nil even when you just want to propagate error to the caller, in rust you can just use ? operator to say if there is an error then return it if not give me the actual return value, it would be nice if golang had something like this, so you can stop writing if err != nil {return err}

[@minskiypeterburg3575]

I don't even know rust well enough, but I understand what ? means and it's great when you don't want to handle error, like when you functions just reads a file, you open it and get file not found error, you don't care so you write ? to return it to the caller, let him handle this situation

[@remyclarke4020]

The problem with his form of error handing is that you could access the value even though there is a error. Other than that, it works, and is far better than random sentinel values. Opinionated, but overall great video.

[@gabrielseibeldev]

UserJustShitTheirPants cracked me up

[@anthonygg_]

😅

[@dranon0o]

When you want to return value + error, you can also do var foo string var err error if foo, err = bar(); err != nil { } I took the habit within my funcs to declare the vars before BUT only when I already figured what i wanted or have to do, so as a small "refactoring" Useful for big functions that call others

[@nodidog]

You can only use foo within the error handling block though - it isn't shared with the surrounding scope! So only really suitable for when you plan to discard foo

[@insert-name1500]

"What do you expect?" Had me rolling!!!

[@ryanleemartin7758]

Love the content! In Rust, the ? is pretty incredible though. It does one thing, returns early on error. It's one of my favorite features of the lang. Having said that, I'm very interested in getting into Go.

[@jittudwivedi6667]

I have been programming in golang for almost a year and i feel error handling in go is the best i am feeling i am having control over those error ,i never liked try catch

[@enriquellerena4779]

II like the rust way of hand long the error with the .or_else(). Very small and concise for what i want to do

[@user-nw7jo5xw9x]

1. by default, go encourage gopher to ignore all errors (forget the if err!= nil won't trigger any warning). I wish golang to do the reverse and always ask for gophers to handle errors or explicitly ignore it. 2. chaining error to have a "call stack" is not obvious. eg: you have a call b call c call d, and d returned err, you wanted to handle in a, and you want that b, c enrich more info to the original err

[@user-nw7jo5xw9x]

knowing that some third-party linter will give warning for none handling errors, some non standard lib will help to chain errors together..

[@a-yon_n]

I wrote something for me to automatically deal with errors in Golang, it goes like this: res, err := goext.Try(func () int { val1 := goext.Ok(dep1()) val2 := goext.Ok(dep2()) return val1 + val2 })

[@silverhairs]

6:11 - 7:55. I love these examples

[@user-uj7kc4fy2q]

I think handling errors immediatly in every logical step and level is a vast contribution to the program stability. I am using PHP framework and it's common thing here to catch in common error handler something unexpected from framework's core with 20-lines backtrace log and it's difficult to understand what caused the error - it's like figuring out what happened at my home when I was at the office

[@Aedaeum]

The best analogy I've ever seen in a programming tutorial, hands down. Laughed my damn ass off 🤣🤣

[@cryptobarbos]

I came from writing C# code for 8 years but for some reasons I like this approach for error handling, especially it's very convenient when we decorate couple of functions and return error type which allows you to deal with different kind of error at one place (for logging or showing response to user)

[@daviddragomir9156]

I cloned ur vscode setup but how I can put the numbers? Also relative numbers

[@baxiry.]

This is the first time I hear an opinion stemming from experience unaffected by propaganda By the way: I'm seeing other languages trying to imitate Go's error handling. Especially Typescript and JavaScript.

[@GiovanniDiSanto]

I would like to start saying that I have seen the full video and I agree with most you are saying. I found the simplicity in which Go handles errors both effective and clear, especially when you have to properly handle an error or add information to the context before propagating it. It is way more readable that the try/catch statement when you want to recover from an error and let the program "fix" what happened. What most people do not like is the error propagation when you are not interested in: handling it where it occurred or adding extra information to the context. When just propagating the error is pure boilerplate "if err != nil {return err}", we should generally add extra information with fmt.Errorf but this is not always the case. Of course, if the application does not have a lot of logic layers this is okay, but for some type of applications layers are inevitable to properly segregate responsibilities. A common example is a rest api service which is usually composed by few layers: repository, service, controllers etc. If an error happens in the repository the application logic needs to propagate it till it reaches the handler where the appropriate status code and body can be returned. Like you, I think the "return" keyword should be preserved when propagating because it makes clear the flow is exiting the function... I would just add a little bit of syntactic sugar when purely propagating with not extra information context. I am not a language expert but I suppose a new keyword or something equivalent could be added... even something along the lines of: "res, (return err) := MyFunc() or res, (return err != nil) := MyFunc()" would make a lot of people happier and more or less preserve the identity of the language. This is just an example, I am pretty sure the smart engineers working on Go can come up with something way better than this. Lastly just a constructive criticism, I think you are a great KZbinr but things like "If you do not see this, I am sorry for you guys" or "trust me because I have way more experience than you'll ever have" are not really effective when trying to justify your position about something... people generally expect something more elaborated than that. Just my 2 cents, of course.

[@anthonygg_]

Thank you for this amazing comment. I 100% agree with this. You make a lot of sense.

[@marl3x]

11:44 love it, and I completely agree, sometimes I think languages try to solve problems that don't exist that make it harder for everyone else to understand them. Go's "plain stupid code" is really nice. What I do not like is the implicit contract with the developer, that you need to handle the error. If you have a "Result" type you need to unwrap it, and the error handling will happen right there, where the call happened, and you can be sure you are doing it correctly. In Go you have an optional error that you SHOULD handle, but are not required to, otherwise you can easily fuck up because of the concept of zero values, and in my opinion that's really dangerous. In my app I've now had a few spots where I've implemented the error handling wrong. Luckily I cought my mistake, but I don't like that this is even possible, and when you begin to add gourotines with asynchronous error handling into the mix, it gets even worse.

[@ralphlorenzo9473]

🙌 thx for you work

[@anthonygg_]

Thank you

[@bnessmind]

Halfway this tutorial and I never knew you could relate programming algorithms with a user farting and shitting. This is amazing.

[@denisprogman]

I've got so much laugh )) thanks man!🤣 moreover it's useful info!

[@wwnnbb9482]

for tl dw: dude would show you how to write func Foo() error {}; func Bar() error {}; for 20 minutes

[@anthonygg_]

When are you going to make more than 50k a year? Let that sink in little boy

[@manfromeridani]

At first, the Golang way of handling errors didn't fit my preferences. Now, I fall in love with Golang 😂

[@definitelynotrohan]

cool video!

[@arminlinzbauer]

I literally asked a Golang colleague about this a month ago, and he couldn't really explain. Thanks for the great video!

[@nX-]

I think that only the "err != nil" is a bit redudant. An unwrap feature for the error would make things much more readable and smaller. This would be enough and readable: "if err := Foo() { return err }"

[@ninthsun]

The question has to be changed. I think people are fine with error handling in Golang but feel tedious and descriptive for duplicated syntax sugars of all those if statements. As I started programming TS, I really love the way how Rust and Go and some other young programming languages handle error. The problem with JS/TS is you propagate error with "throw" and expect someone handles that error magically. As a result, the code might look clean and nice, but the way how error is handled is so complicated or maybe miss some important exceptions as they are handled by common error handlers in the upper stack. So, it's kind of trade-off. If you want some short code with minimal duplication. Then you'll have to abstract everything in a fear of code duplication. However, if you embrace some code duplication, the code may look bit dirty, but it's so much clear and less prone to unhandled exceptions.

[@transaphonic]

Haha I've been saying this Philosophy for years... So glad not everyone is just jumping on the latest bandwagon... You rock👍

[@MesheeKnight]

I dont miss the try, catch, finallt, try, catch time. clear, simple, explicite. This is the way of the Golandorians.

[@anthonygg_]

Golandorians 🤣

[@nanonkay5669]

The Golanders

[@viktorshinkevich3169]

4:23 result by itself solves nothing and as you said tuple (value, err) makes the job done even better. But what result gives is ability to declare a successful path as it should be and deal with errors separately.

[@anthonygg_]

I can agree

[@lilzin69]

go error handling is ok.. but i think go should learn a little with zig or rust code like this, I think, will be nice: value := try foo() // returns the error if foo() fail or value := foo() catch err { // do something with the error }

[@vitiok78]

I personally think that exception based error handling is a nightmare. It leads to smelly code. Sometimes you just don't know where that exception is handled. You MUST deal with errors right there where it happened. You'll become ten times better developer if you do that. I even want a compiler option to disable the ability to omit errors entirely)

[@ArielCacha]

The Golang approach is not bad, but I think it needs some syntactic sugar to make the code easier to read. When you read those if-err statements, the function ends up being in the middle of the sentence, making it take longer to scan and understand what's being done there. And when you read a lot of code like this, you start feeling tired much more quickly than with other languages.

[@weebney]

I’m pretty sure this is an intentional language design “feature.” Thinking about it, they could have easily added the ternary operator to make the error handling idiom extremely short. In Go, though, you see `err := ` and immediately know you have a function with side effects that is being intentionally treated differently for a reason. You really should have to look hard at the line to see what the function is doing- there would be no error handling attached if that wasn’t the case. I can only imagine that this has saved more than a few asses.

[@snatvb]

bad is that we have nil if you wanna return tuple with error, you may get nil, you never sure that there is real value worse when it's numbers, there will be 0 - it may leads to UB

[@myounus96]

"I am training you guys to have a longer attention span" 😂

[@PatMaddox]

Rust’s ? suffix takes 2 seconds to get - once someone explains it (and if you have enough experience with other languages, you may grok it off the bat). So it may seem small, but your point is well-taken: anyone who has ever shipped code can look at golang error handling and immediately understand it, no explanation required. That does seem to be one of go’s big selling points: you can take pretty much anyone off the street and they can implement a functional change pretty quickly. Whether they’ll do it well is a different story…

[@garciajero]

6 months ago a programmer of your experience could be returning generics already more than int,error...

[@AK-vx4dy]

@16:11 Most important is to have *CLEAR* signal that you *SHOULD* check error condition or use some *VISIBLE* and/or *HARD* or *UGLY* way to skip this check: _ := Foo() in GO or .unwrap() in Rust. People who say it is wrong, are exceptions and try/catch fans... wich are literaly *GOTO* in disguse... Maybe it is not beautiful but definietly not bad design or wrong. Maybe one day GO will have some "shorcut" for this idiom or people will use some library.

[@arminlinzbauer]

At my college, the professor actually tried to convince us, that a function should only ever have a single point of exit, meaning we should only ever have one code path return execution context back to the parent function. In his opinion, early returns / guard clauses were of the devil and should be avoided at all cost. He would even deduct points for not following this in exams. He would much rather have us write deeply nested spaghetti code littered with dozens of "if x then ret := y else ret := z" statements. To this very day I simply cannot believe how stupid this "advice" is and how many poor students might actually still be following this rule to this day. Thinking about this makes me wanna cry. Out in anger. I hope that prof frequently has his sleeves slipping down and getting wet while washing his hands.

[@germantoenglish898]

If he just farted I wouldn't be too worried, but if he shits I will try to catch it in a diaper.

[@Ross96D]

Have u see Zig error handling?

[@Convictedization]

Is this targeted against rust?

[@donnacasterr6223]

Returning error is only superior to Try Catch in some cases. Rust, Vlang, Zig all have far superior ways of handling errors where you can easily decide to deal with it our bubble it up to the caller.

[@enfy1337]

lmao "User just shit their pants. that's problematic!" Thank god programmers don't have to actually deal with this kind of problematic error :)

[@cangurdal9264]

I checked my playback speed. I thought it was at 1.50x

[@webstradev]

Great Video! Great Topic!

[@Cruzylife]

this made me laugh so much

[@paulfrischknecht3999]

hilarious 😂

[@osagie6862]

Shit, Fart 😂 love your content.

[@thejuanpa88]

this is still a very bad way to handle errors imho, there is literally no reason for not having a one liner for error-returning functions handling

[@anthonygg_]

I agree on that

[@codecoffee8363]

I think you will talk about error type, error wrap, error codes 😂😅

[@3ckortreat]

is it scottish accent or belgium?

[@juraev0056]

Informative function names

[@anthonygg_]

Im trying to be expressive

[@datguy4104]

I don't remember who it was but his argument against something like JS error handling is that you have no idea what could even throw and error and don't even know innately where to use try/catch... Go might be "annoying", but it teaches programmers to be wary of errors in the first place and makes it plain as day what's happening. It's boring but great.

[@anthonygg_]

Amen

[@avid459]

What he is basically saying is, 'My way or the Highway'. Go community in general is exactly like this. 200k+ devs are exactly the devs who don't like Golangs verbosity. func A(){ doA()? doB()? doC()? } what they are fighting for is human time to learn a codebase which is getting higher as the amount of code only increases, I learnt the ? operator in the first hour of leaning rust, I can quickly scan the three lines and know what the function is doing, now if you sprinkle go's error handling, you know the above function will look like. People hate Go codebases as 40% of the code is just error handling.

[@anthonygg_]

200k+? That looks like my yearly salary

[@AaronHeld]

I have over 25 years of programming experience at both Fortune 50s and Unicorn startups. I have personally mentored 100s of software engineers and led countless in house training sessions. Never in my life have I seen domain event error handling expressed so elegantly. I am updating my slides today and adding a relieveGas() function to demonstrate how we operationalize laptop code and get it ready for real use. Handling the domain events of Farted and Shitted is brilliant. We can even expand the context because handling a domain even of Shitted for a baby should be a very different process then handling that even for an adult. The analogy is brilliant and accessible.

[@anthonygg_]

Thanks you so much

[@thingsiplay]

If you want proof a point, never say others don't understand just because they have a different opinion than you. Yes, there are some people who don't know what they are talking, but on the same time, there are people who know what they are talking. I will learn and build my own opinion AND respect others opinions.

[@anthonygg_]

You have a point here.

[@thingsiplay]

@@anthonygg_ 1 month later and I am currently learning Go, diving into the errors a bit. The error handling could be better, coming from Rust, but it is not as bad as people told me. In fact I already did error handling in Python in a similar way with multiple return values! I like this control, but it could be improved.

[@moistness482]

Anyone who thinks go's error handling is tedious clearly hasn't tried rust. p.s. nothing is as tedious as finding out a random function from a library can throw and you don't even know it until it happens.

[@anthonygg_]

Exact. Rust people think their error handling is better, but they just call unwrap() on everything

[@androth1502]

everything is tedious in rust. odin does better error handling.

[@freeplayer2183]

this guy is the fucking goat

[@ThePandaGuitar]

Lmfao 🤣 love this

[@AK-vx4dy]

@13:12 It is not bad... it syntatcit sugar for almost the same lines you had before.... @13:15 Oh man...... ? in Rust have nothing in common with ? in JavaScript !!! In rurst it propagates error up in JavaScript it handles undefinded/null values "silently" @13:54 No one will understand := if not programing in go 24/7 :) (or have someting to do with pascal in some way) :D

[@esra_erimez]

3:40 🤣

[@Arunnn241]

I don't think golang has bad error handling. I think something to reduce the amount of keystrokes would be nice tho. Someone should make a vscode extension

[@iggermanable]

Copilot helps a lot with that)

[@tomasnevoral9246]

I like golang but it would be nice to have similar like rust error handling

[@NoxyYT]

Just ? operator to propagate error would have been great, it doesn't even need options/results.

[@TB-tv2zf]

Well at least try/catch catches "panics", whereas I absolute hate Go's recover.

[@iamworstgamer]

i used to hate it but i began to appreciate the genius of it because it really forces you to decouple your code

[@aar021]

Do not mind it at all. I like Rust’s better. You should learn Rust. You may like it. I love both. Thank you for the video.

[@vitorhmtts]

yeah, this is better than try cath because at least errors are values, you return and should at least explictly ignore them... but there are better ways to handle them too, like the rust approach

[@vitorhmtts]

to clarify (because what you said about rust is wrong): the Result type is an Enum, not a Struct. it means the Result is an Ok OR an Err, so you CAN'T use the other value and explicitly ignore the error, as you can do in golang. if the return is the Return::Err variant, the Ok value simply doesn't exist, it isn't "nil" or "None", it doesn't exist. you HAVE TO handle the error or panic your program.

[@anthonygg_]

Agreed, my bad

[@airkami]

No thumbs up for you and I definitely won’t leave a comment!

[@sjakievankooten]

You sound very Belgian. Am I right? 😅

[@anthonygg_]

Yes born and raised

[@ignoreyour6326]

What is easier to read: func foo() throws IOException { read(); write(...); ... } or: func bar() { _, err := tead() if (...) { return err;} _, err := ... if (...) { ...} } Exceptions, when implemented correctly lets you focus on the code, not the error handling aspect.

[@Jason-xw2md]

yes, exceptions are very good at helping you focus on if a nested function call in some library, or unfamiliar part of the codebase you are using throws an error. Hope it has good documentation! If it doesn't, you can always just wrap everything in try catch, and have "error handling"(printing out an error, very useful)

[@rolandinnamorato1953]

Very convincing. Go is for tired (of bullshit) programmers

[@gabrielseibeldev]

Hey, what's that editor theme? Good take on errors 🫡

[@anthonygg_]

Gruvbox and some vscode settings. There on my github

[@rekram1519]

It’s just so idiomatic idk why people hate on it

[@P3PPING]

The thing I love about go is that the different between a Junior and s Senior isnt the "cool syntax" they use, but the smart way they solve the problem. Go says that language choice matters so much that we designed it not to matter.

[@RockTheCage55]

I have to disagree I love go but the error handling isn’t the cleanest. try/catch/finally (TCF) is the cleanest. Go error handling reminds me back in the old days of MFC/win32 api calls & having to inspect HResult (yuck). TCF forces you to deal with and errors..if you want to throw them away you can but if you don’t they will bubble up & your program will crash with & unhandled error exception & IMO this is the way it should be. My errors are generally handled in either middleware or put in with AOP. That’s why 99% of new languages use TCF

[@sirnawaz]

Pretty bad justification! Why don't you look at Rust and the operator `?` and there are so many other functionalities on Result and Option that simplifies the code.

[@Dethas1991]

I hate try-catch, there's always problem with it...

[@jianxue283]

There are so many "666"s here. 🤣 I'm genuinely curious, are you familiar with the significance of "666" in Chinese culture?

[@lmtr0]

Who can read this? 😅 People that have 10+ more hours than I will ever have should as i read it very well LMAO

[@muhamadrafipamungkas4465]

I don't know if you're serious about bragging your YoE (4:35) into this argument and 10x your viewer will ever have, defending a subjective opinion (4:15), but that makes you sound much less credible.

[@anthonygg_]

Take it with a grain of salt. No need to take everything I say serious.

[@muhamadrafipamungkas4465]

@@anthonygg_ I see, would rewatch again with a table spoon of salt

[@aslkdjfzxcv9779]

i had to lookup when i heard, "userjustfarted." 🤣 thought maybe it was your accent. no. it wasn't your accent. 😁

[@anthonygg_]

In 2023 its hard to get peoples attention. I try to be creative 😇

[@peculiar-coding-endeavours]

Errors as values is the way to go for sure. People like to laugh at GOTO statements, but then happily mess up control flow in their programs with throwing around exception throwing. On the scale of predictability at the cost of verbosity vs nondeterministic behavior while being able to easily throw exceptions, I'll err on the side of robustness any day of the week.

[@anthonygg_]

Amen

[@peculiar-coding-endeavours]

@@anthonygg_ No need to reply, cause it's none of my business, but am I right to detect some Dutch accent there? More specifically the Flemish flavor?

[@anthonygg_]

@@peculiar-coding-endeavours Jup :)

[@peculiar-coding-endeavours]

@@anthonygg_ Takes one to know one ;-) goed bezig

[@anthonygg_]

@@peculiar-coding-endeavours merci bruur

[@airkami]

With all due respect, please figure out how to not pick up your breathing on the microphone. The listening will flow more smoothly

[@stanislavus]

boost

[@MaybeBL1TZ]

for anyone who didn't like error handling in Golang he's clearly a low value programer period.

[@mlntdrv]

So in short, back to error handling C-style. I can see why people dislike it.

[@AK-vx4dy]

Somewhat "shitty" examples 🤣

so basicly there are no error handling, just a bunch of if statements and multiple return values all over the code :D and you say its better than try-catch, and its readable :D better error handling is one of the most requested feature in go, everyone knows its a piece of sh..t...

[@NotSomethingIsNothing]

I like your other videos, but I don't agree with this opinion. I think opinions are fine but you should not just hate something without understanding why it's done or how it's handled. You just hated on Typescript/Javascript "?." If you are not sure how it's used learn about it before shitting on it. "?" is a optional accessor, and is handled by people writing the code, if needed, since it's optional. People writing TS/JS handle so much optional stuff that may or maynot exist because of the environment it runs on, try catch error handling is required. If else just bloats the code they ship to the users using their websites and makes development painful. If you think your way of error handling is the better one then you are not as experienced as you say. Every ecosystem/language has a way to write code depending on how the output is used or where it runs, you are as much irritable as someone who says try-catch is better way to handle errors. No-offence, I like your go-videos but don't state your opinions as facts.

[@anthonygg_]

Fair enough

[@hoax-777]

L