Gregory's Server@12 heh, I know this is rhetorical, but I actually can take a pretty reasonable stab about where that aversion comes from if you'd like. :p
|
17 comments
 @12 So it comes out of a combination of type theory, a counter-culture reaction to Java, some thoughts out of structured concurrency, and Rob Pike et al's desire to "simplify" the language by pushing complexity onto the developer who is writing the code. It works a bit like this: When you call a function it will have a return value with an associated types. Errors are just another kind of type, so if your program has a type `T` then with the exception it becomes `T | IllegalArgumentException`  @hrefna our brain learned: ``` @12 Try-catch blocks evolved from how these errors often cluster and how we want to intercept them and wanting to avoid eight million if-else blocks. That's the plus side. The downside is that the error can come from anywhere in the block of code and anywhere in that block of code's call stack. It may have weird handling requirements (like Interrupts) or may be a nop, or it may never happen in reality. @hrefna we've found ChatGPT helpful, yes, we know, in figuring out golang withot fighting with tutorial sites. We're like, ok, show us how to do this. And from that, we can see how it does the thing and do the thing ourself like @12 I actually like the AI tools for this sort of thing, personally. Sometimes they can help illustrate something that is difficult to see otherwise. I've used bard to learn cypher and a few other things like that because while its coding is atrocious it can often help with the things no one talks about. @hrefna right! And like tutorial sites are like, here is this simplified thing that you don't want to learn. We learn best by seeing how others do it. Sidenote: good gods software *engineers* are scary. build systems and test cases and dependency management and release tagging and shit, where we're from you're lucky if you get a `cc -o dothething -I./src/common -I./src/thinglib thinglib_core.c thinglib_tui.c dothething.c dothething_plugins.c` @hrefna we're a software hacker in the 1980s unix sense. It plays right hell with our atempt to get a job, too @hrefna yeeeesh. We feel like as a kid we learned like a weird bastardised combination of C and Python? and that has just absolutely stuck with us, and then we learned C#......... of the terrible projects we created in C# we hall not speak @12 My first language was hypertalk, which is a bizarre language but also a very cool one. It's _really_ hard to shake early paradigms with languages. I'm generally of the view that languages are easy, but learning the ecosystem is difficult and learning paradigms is difficult I've seen programmers with decades of experience segfault entirely when running into a different paradigm. So you aren't alone in that, and in this case they picked up none of the things that makes that patternโฆ work. @hrefna yeah, the paradigm we learned was... very C-style. Very very C. Not that we can hack it in C; the only thing we ever wrote in C were some truly dirty Linux kernel hacks @12 But in go you: a) Lack generics So you end up with code that is extremely verbose and contains a lot of if-else-if-else-if-else calls. Which even for someone who prefers to avoid try-catch blocks in languages with good semantics for it makes me _really_ twitchy ^^;; @12 Oh, and one more note on this, in the languages with operator overloading this becomes downright _clean_. It becomes something like: RunSomething >>| do_something_with_result >>| do_another_thing >>= deal_with_errors |> add_callback Now it can even be concurrent and still nice and clean, with no changes to the code. Which is why a lot of people like this pattern, but it does involve a different way of thinking, and I'd argue its absence from go is keenly felt. |
@hrefna fucking please. There are two few languages that we can get our head around, and golang is, almost, one of them. except for that bit.