SeirdyGo is spectacular in every way except the actual language itself
Hazel Cora@Seirdy LMAO what is this supposed to mean
@h top of the line:
- fuzzers
- linters
- formatter
- language server
- native cryptographic libraries (not just bindings)
- build speed
- portability (far better than most LLVM langs)
- property testing (literally in the stdlib)
- sanitizers
- HTTP protocols (conformant native libs for HTTP/2, HTTP/3)
- large ecosystem
- docs
- stability (the Go Compatibility Promise)
- a spec
- other usable (mediocre but still usable!) implementations
- dead-simple OS/arch cross-compilation
- green threads
Go has everything except a good language.
@Seirdy i see very few flaws with the language besides things like "i want ternary operators" and "i want try-catch" (slowly realising its for the best that we dont have try-catch though so i wouldnt actually want this to change) so i just cannot understand this take i think
Jack Jackson@h @Seirdy (Genuine question, not an attempt at a gotcha - you both are clearly working at a much higher level than I am) I'd love to know more about why you think it's good to have errors returned rather than thrown? To me, it seems incorrect both philosophically (the type of the representation of exceptional behaviour should be orthogonal to the return type of a function) and practically (it shouldn't be possible to forget to handle an exception) - I'd love to better understand the benefits!
Latte macchiato 
@scubbo @h @[email protected] Because in practice, most devs suck at handling thrown errors. They wrap the whole thing in a big try catch, have a general catch at the bottom and then just don't do anything with it.
Returning errors per function lets you do much more fine-grained error handling, or crash with a lot more info.
Returning errors per function lets you do much more fine-grained error handling, or crash with a lot more info.
@privateger 100% with you on the first paragraph - that's a bad practice, for sure, and I agree that it should be discouraged.
I need a bit more insight to understand the 2nd para, though. How does returning an error _let_ you do those things, in a way that you cannot (note - "cannot", not "don't, in practice") do with thrown exceptions?
(If the claim is actually "both approaches have equal maximal specificity, but explicit per-function error-handling promotes better practice", then I buy it!)
@scubbo This isn't a cannot thing, but it's never done. try catch just lets you be lazy, and that's what ends up being done.
I haven't seen a try catch used for a single function call basically ever, when that's really the error resolution you should be operating at most of the time.
I haven't seen a try catch used for a single function call basically ever, when that's really the error resolution you should be operating at most of the time.
@privateger Fair! In which case, I understand and agree with your claim. Thanks for clarifying! :)