| ▲ | stouset a day ago |
| Without fail, every single person I’ve seen rave about go’s error handling compares it only to exceptions as if that’s the only alternative. On the flip side I have yet to find a person who’s familiar with sum types (e.g., Maybe, Option, Result) that finds the golang approach even remotely acceptable. |
|
| ▲ | OtomotO a day ago | parent | next [-] |
| Here, you've found me. I don't LIKE it, but it's acceptable. I have been working with Rust since 2015 (albeit not professionally, but a lot of side projects) and love it. But I also dabbled into go the last couple of months and while it has its warts, I see it as another tool in the tool-belt with different trade-offs. Error handling is weird, but it's working, so shrug |
| |
| ▲ | cnity a day ago | parent [-] | | Sorry, balanced opinions are not welcome in discussions about favourite programming languages. |
|
|
| ▲ | clausecker a day ago | parent | prev | next [-] |
| I dislike sum-type based error handling. It is annoying syntactically and only really doable with lots of high-level combinators, which in turn hinder debuggability. |
| |
| ▲ | alper 8 hours ago | parent | next [-] | | I'm dealing with Rust based error handling now and nesting `match` statements is not exactly very happy. Or having to pull in `anyhow` and dealing with its awful awful documentation. | |
| ▲ | lionkor a day ago | parent | prev [-] | | Have you tried the approach that Zig has, or the approach that Rust has? They are easy to debug and do not use any crazy stuff, just simple syntax like `try x()` (Zig) or `x()?` (Rust) | | |
|
|
| ▲ | devjab a day ago | parent | prev | next [-] |
| I think it’s because Go is an alternative to Java and C# more so than an alternative to Rust. It is for me at least. As I said, Rust isn’t seeing any form of real world adoption in my region while Go is. Go isn’t replacing C/C++ or even Python though, it’s replacing Typescript, C# and Java. Now, there are a lot of good reasons as to why Go shouldn’t be doing that, a lot of them listed in the article, but that’s still what is happening. As I pointed out I think Rust does it better with its types error handling. That isn’t too relevant for me though as Rust will probably never seem any form of adoption in my part of the world. I think Zig may have a better chance considering how interoperable it is with C, but around here the C++ folks are simply sticking with C++. |
| |
| ▲ | zozbot234 a day ago | parent [-] | | > Now, there are a lot of good reasons as to why Go shouldn’t be doing that I disagree. Typescript, C# and Java are terrible languages (as are Python/Ruby/etc. in other ways). Golang is bad by OP's standards but there's nothing wrong with it gaining ground on those languages. Besides it's also easier to convert a codebase to Rust from Golang than Typescript or C#/Java. | | |
| ▲ | high_na_euv 6 hours ago | parent | next [-] | | C# is the best designed lang out of the top10 most popular langs | |
| ▲ | devjab a day ago | parent | prev | next [-] | | It was meant more as an observation than my opinion. I would pick Go over Java/C# any day of the week, but it’s not like talented JVM engineers won’t run in circles around you as far as performance goes. I’d frankly pick Python for most things though. It’s a terrible language, everyone knows it’s terrible but it gets things done and everyone can work with it. I view performance issues a little different than most people though. To me hitting the wall where you can no longer “make do” with C/Zig replacements of Python bottlenecks means you’ve made it. The vast majority of software projects will never be successful enough to get there. | |
| ▲ | neonsunset a day ago | parent | prev [-] | | Rust and C# have far more overlap than Go could ever hope for. Go is limited (and convoluted sometimes due to "solutions" devised to cope with it) so it is easily expressible in languages with better type systems and concurrency primitives. |
|
|
|
| ▲ | DanielHB a day ago | parent | prev | next [-] |
| You hit the main gripe I have with Go, its types system is so basic. I get people raving type-correctness of Go when they come from Python but the type system in Go is simply pre-historic by modern day standards. |
| |
| ▲ | masklinn a day ago | parent | next [-] | | Go’s type system is not even impressive compared to python’s. | | |
| ▲ | orwin a day ago | parent | next [-] | | Do you have a pydantic equivalent in go? Also modern typing in python is starting to be OK to be honest (well, if you consider typescript typing OK), so it isn't really a knock on Go :) | | | |
| ▲ | DanielHB a day ago | parent | prev [-] | | Well I was comparing to python codebases before they added type annotations | | |
| ▲ | Yoric a day ago | parent [-] | | Which, sadly, is still the case of too many dependencies. While I much prefer Python as a language, Go wins against Python by having a fresher ecosystem, with a higher baseline for type safety. Still pretty low with respect to Rust or mypy/pyright with highest settings, but much better than any of the Python frameworks I've had to deal with. |
|
| |
| ▲ | yyyfb a day ago | parent | prev [-] | | I feel that the future for Python people who want type safety will eventually be TypeScript on nodejs. Go was intended as an alternative to C++. It seems that in reaction to the ungodly complexity of C++, the creators wanted to avoid adding language features as hard as possible. If the user could work around it with a little extra verbosity, it'd be ok. I feel they removed too much and maybe not the right things. |
|
|
| ▲ | eska a day ago | parent | prev | next [-] |
| That’s to be expected since it is marketed towards beginner and casual programmers. |
| |
| ▲ | Cthulhu_ a day ago | parent [-] | | I don't agree that that's what it's marketed towards, but it was designed with those in mind. That said, experienced developers can enjoy it too, as code is just a means to an end and code complexity or cleverness does not make for good software in the broader sense of the word. It's a Google solution to Google scale problems, e.g. codebases with millions of lines of code worked on by thousands of developers. Problems that few people that have an Opinion on Go will ever encounter. |
|
|
| ▲ | euroderf a day ago | parent | prev [-] |
| FWIW... WebAssembly has Option and Result, and adapters for Go. |
| |
| ▲ | cnity a day ago | parent [-] | | What do you mean by this? WebAssembly is a low level bytecode which only defines low level types. WebAssembly doesn't "have" types any more than x86 "has" types right? Or have I missed something? | | |
|
