I Want Off Mr. Golang's Wild Ride

Post by terminaljunkid » Fri, Feb 28, 2020, 5:53 PM UTC

typon wrote: post #51

I don't understand why you would create a statically typed language but not actually take advantage of types, instead typing everything with generic types like string. Why make the user pay for complexity in types but not actually deliver their promise? This is the problem with C and Go doesn't really solve it either

Post by hinkley » Fri, Feb 28, 2020, 5:55 PM UTC

dilap wrote: post #23

If you imagine a spectrum of languages from sloppy-but-"easy" to precise-but-"hard", with something like Python or Ruby way off on the left and something like Rust way off on the right, Go is sitting somewhere in the middle. And so if what you're craving is absolute precision and maximal avoidance of errors or incorrect behavior, then Go is not going to be your jam. I sympathize w/ that. That said, these specific com…

Post by throwaway894345 » Fri, Feb 28, 2020, 5:58 PM UTC

whateveracct wrote: post #77

Here's an example of why Go's simplicity is complicated: Say I want to take a uuid.UUID [1] and use it as my id type for some database structs. At first, I just use naked UUIDs as the struct field types, but as my project grows, I find that it would be nice to give them all unique types to both avoid mixups and to make all my query functions clearer as to which id they are using. type DogId uuid.UUID type CatId uuid.…

Post by Macha » Fri, Feb 28, 2020, 6:00 PM UTC

jsjddbbwj wrote: post #112

blattimwind wrote: post #109

Earlier quoted context omitted.

Strongly typed: >>> "foo" + 3.141 TypeError: can only concatenate str (not "float") to str >>> object() + 3.141 TypeError: unsupported operand type(s) for +: 'object' and 'float' Weakly typed: > "foo" + 3.141 "foo3.141" > Object() + 3.141 "[object Object]3.141" > [] + {} "[object Object]" > {} + [] 0

a = 3 a = 'abc' There goes your strength, Samson. Just because there's something worse, that doesn't make python strongly typed

    fn main() {
       let x = 1;
       let x = "foo";
    }

Post by AnimalMuppet » Fri, Feb 28, 2020, 6:01 PM UTC

Karunamon wrote: post #107

Seenso wrote: post #103

Earlier quoted context omitted.

> Well you should handle the error in the first place. That's like saying you should just write bug-free code in the first place.

Go goes out of its way to ensure you handle the error. You have to do something with that err return, otherwise it's a compile error. If you're just throwing it away without checking, we've gone from the mere mistakes everyday developers make to irresponsibility. There's a reason most go code is littered with "if err != nil" on nearly all function calls.