4 ms·
This is actually my first week using go (from years of C++/Swift/js/etc) and I’ve been very impressed with the module system and simplicity so far. I’d definite
by evanmoran 5y ago
This is actually my first week using go (from years of C++/Swift/js/etc) and I’ve been very impressed with the module system and simplicity so far. I’d definitely encourage others to try it if they haven’t.
As for generics, Go’s lack of function overloading and arg default values is really interesting. It ensures that a function is always easily found as it’s the only thing in the module with that name. I’ll be curious to see if generics are easier to follow without function overloading. It will still be only in one place, where as in C++ you could have hundreds of functions with the same name across many libraries and you just have to hope your ide knows which to step into.
- masklinn 5y ago> As for generics, Go’s lack of function overloading and arg default values is really interesting. It ensures that a function is always easily found as it’s the only thing in the module with that name. I’ll be curious to see if generics are easier to follow without function overloading. There are already a number of langages with generics and without overloading (or defaults). Haskell, ocaml, rust, …
- 4ad 5y agoTrue of OCaml and Rust (and many others), but Haskell certainly has overloaded functions through type classes. In fact, once OCaml gets implicit modules, this won't be true anymore of OCaml either.
- masklinn 5y ago> True of OCaml and Rust (and many others), but Haskell certainly has overloaded functions through type classes. That's no more overloading than Rust has through traits.
- 4ad 5y agoIt absolutely is, because class methods in Haskell are top level declarations. Not only this is not true in Rust, but it doesn't even matter as Rust doesn't have polymorphic values, only polymorphic types and functions. In Rust, unlike in Haskell or ML type inference stops at function boundary.