They say Go is the language of the web. Of course, with Google backing it up it sounds very objective! But is it as good as they say? I can think ...
For further actions, you may consider blocking this person and/or reporting abuse
Are you seriously trying to frame the lack of proper exception handling as a plus?
It's OK to advocate a language or platform. But this argument deters from the power of the other arguments.
I did read your comment a bit late, as i am investigating if i wanted to used Go for something in 2024. I have to agree that i found this and some other things againts Go. Yes Go forces to catch everything (maybe that force is good for some developers) but i like to have both. I catch if i know and expect and know how to handle a certain error. The rest is for error's that should not have occurred at all and break total functionallity that the user is interested in and should be fixed. Also the stack methode give the dev the generic chance to find the path in the application that caused the error. This is specially handy when you got a massive application that calls some functions from a million places, and that function can fail like 1 in 1000 times when called from one of those million. Try to figure out what caused that situation you do not want for that function instead of making a bandaid on the point where the error occurs (thats too late and could have caused things like data corruption in big businnes applications). I will still skip Go for my use cases even still in 2024. Not saying that it is a bad language but it depends on what you are building.
I'm sorry I'm not sure I'm following.
What is a proper exception handling in your opinion?
Go and Rust have a similar way of handling errors:
(T,error)andResult<T, E>.JavaScript, C++, Python and others do the
try{}catch{}finally{}andtry...except...finally, which causes the issues I mentioned in the post and aren't enforced in any way.I mean sure it definitely fades in comparison to Windows'98 server argument, but otherwise looks legit :-)
So I'm a Java guy. But the Go approach isn't new or novel. We've used it in C, Objective-C and many other languages. There are reasons people came to the conclusion that exceptions are the way to Go.
The error response approach works great in a 5 line demo app. You open one or two files and yes you have an error right there and don't need to catch. That's OK for simple use case which again might be fine for Go as it's meant to replace C more than its meant to replace Java.
Exception handling shines when you have multiple, complex operations and 3rd party API calls. Handling the error for every call becomes a noisy affair of testing every call or wrapping everything you can. In Java we can just move that error handling up the stack. The user doesn't care that method X or Y failed. They care that that the operation as a whole failed which is why we have generic handling.
The developer gets a stack that pinpoints the error for our use case. Java also has checked exceptions which enforces error handling. I think people hate that feature because it was over used in some cases, but it's a wonderful feature that works well for most cases.
Try/catch approach works great in a demo app. But in a big codebase it's easy to forget what command throws and what doesn't. Catching up the stack seems like a great idea till the point you decide that some errors need to be handled in a different way and you start wrapping calls in yet another try/catch. Eventually you end up with the system where you have no idea where exactly an exception would be caught or silenced. There is a reason people came up with explicit error handling. It gives you not only freedom to choose how to handle it (perform early return, accumulate all the errors in a batch or ignore it), but enforces handling it close to the source. This allows you to make changes to the code in isolation, regardless of where you you've decided to catch errors.
That's a nice reuse of my statements ;-)
Unfortunately this isn't correct.
Try catch came after explicitly returning an error code and response by reference. Java solved the problem of remembering what is thrown by adding checked exceptions. Pretty much every framework has generic fallback error handling so nothing is lost. Instrumentation, diagnostic and debuggers all support exception handling very well and make working with it super trivial.
Large code bases often added "fake" try/catch semantics to languages that had no business doing this e.g. C and C++ before it became part of the language. In C++ it always sucked because it needs a GC to work and yet it was added because the value is so obviously apparent.
Try/catch maps to hardware capabilities very well and can be handled very efficiently without adding multiple branch statements. Don't say "the optimizer will remove this"... It can't do that as well.
The sarcastic humor in this post is wonderful XD. I am learning go NOW!!
Glad you liked it!
There are great resources but my favourite is gobyexample.com/ if you're looking for pointers
Thanks!
The thing is, you can't win them all.
To advocate something that's not in the core (like Spring) is for me to giggle about.
The Gophers amongst the readers will know: we have all batteries included for our task.
I think, Valeria wrote this not to troll, but to let you think about certain stuff.
If Go happens to miss a feature from another language, it's probably because the community doesn't need it. It not a language made by hoarders, it just a tool to get things done in a very precise and strict way.
It's not a pi***ing contest, it just like it is: an opinion ;-)
Thanks Valeria for this unique glimpse into your brain: me likes :-)
Thank you!
Nope, certainly not trolling.
And I'm glad you liked it :-)
Indeed I've often had the Rust vs Go debate and done research on it.
Rust is more for systems programming (where you care about optimizing a game or hardware or dealing with bytes). writing something high level ends up being verbose. And Rust is notoriously difficult to learn - esp using a 3rd new paradigm for memory management. But it is supposed to be easier than writing or learning C or C++ or at least has more safeguards to prevent you from writing code which is unsafe for memory. C and C++ can be performance but they can also be slow and wasteful if you them wrong
While Go is meant more for high level programming like Python or JS. Go is known for being much easier to learn than Rust.
The speed is similar for both. The fastest depends on the article you read and the article it was tested against.
Exactly!
At this point I'm collecting languages like Pokémons. You gotta have them all! 😜
Each one has a niche and you never know what kind of wild project you'll be building next.
Got me lol, fun post!
The title is totally misleading.. :)
The article is great except for the "u" in favorite. :/ Whatever, Go is fine, but Rust is definitely better.
Thank you for the feedback!
Both spellings favorite and favourite are correct. I'm more inclined to use the British version, e.g. favourite colour, as opposed to American favorite color.
Absolutely, Rust is better in many things, yet it's significantly more complicated, especially when it comes to web services.
It was just a joke 🤣. I like Rust because of its speed + efficiency. Go arrays are so weird.
I was about to scold you and i saw the irony tag 😁
😎