After generics (coming soon), a proper sum type and then I'll shut up.
Go Replaces Interface{} with 'Any'
61–70 of 481 posts
Re: Go Replaces Interface{} with 'Any'
#62This is fantastic. It'll make Go feel much less weird. eg from the diff: []interface{}{1, 2.0, "hi"} -> []any{1, 2.0, "hi"} Now that Go is going to have generics, all we need is sugar syntax for early return on error -- like more modern languages such as Rust and Zig have -- and Go may finally be pleasant to program in!
It's definitely more streamlined, but my concern would be that newcomers might not understand that it's just an alias. Learning Go really reframed my concept of what an interface is, and I thought that using an empty interface to represent "any type" was kind of ingenious, and helps reinforce its ethos.
An empty interface can represent any type because every type inherently implements an interface with no methods. And that's what Go is all about -- implicitly implementing interfaces.
If a newbie hops into Go and just starts using "any" I think they might assume it's a magic type that's at the base of everything, missing out on the fact that they're still taking advantage of interfaces.
Re: Go Replaces Interface{} with 'Any'
#63This is fantastic. It'll make Go feel much less weird. eg from the diff: []interface{}{1, 2.0, "hi"} -> []any{1, 2.0, "hi"} Now that Go is going to have generics, all we need is sugar syntax for early return on error -- like more modern languages such as Rust and Zig have -- and Go may finally be pleasant to program in!
I cannot wait for the Result monad. The state of error handling in Go at the moment is embarrassing at best.
Well it's better than most language with exceptions.
People makes it a big deal, in reality it's not.
Re: Go Replaces Interface{} with 'Any'
#64Re: Go Replaces Interface{} with 'Any'
#65Their code is full of things like:
type fileOps []any // []T where T is (string | int64)
Reminds of Java 4 (15 years ago or something) where code was full of this crap:
List /* */ values;
Map /* */ map;
Re: Go Replaces Interface{} with 'Any'
#66Earlier quoted context omitted.
Sure, but semantic versioning really is the wrong kind of versioning to use for a language. The major version should represent major language changes, not whether its a breaking change or not, semantic versioning isn't somehow magically a "good" way to version. It's useful for libraries / dependencies where you are dealing with many different libraries and just want to know you can upgrade without having to deal with…
In Java people regularly refer to a particular JDK version as a Java 17 or Java 11, even though they actually refer to versions 1.17 and 1.11, respectively[0]. In Clojure land they just say 1.x, even when large new features are added. I like this because it emphasizes the community's commitment backwards compatibility, which I greatly value. I've spent a good deal of time writing Javascript, where library developers…
> In Java people regularly refer to a particular JDK version as a Java 17 or Java 11, even though they actually refer to versions 1.17 and 1.8, respectively.
17 -> 1.17, 11 -> 1.8, this is bothering me way to much for no good reason.
Re: Go Replaces Interface{} with 'Any'
#67Like it! Now, can they continue to add more “useless” improvements like while-loops and so on.
Doesn't 'for' work as 'while' if you only give it a condition in go? I haven't written much, so correct me if I'm wrong.
Re: Go Replaces Interface{} with 'Any'
#68After generics (coming soon), a proper sum type and then I'll shut up.
same :) maybe also relax rules a bit to allow type elision for structs in function calls to get python like keyword args. foo("blah", {option1: true}) would work better than functional options people use now.
Re: Go Replaces Interface{} with 'Any'
#69Re: Go Replaces Interface{} with 'Any'
#70Good, now we just need the ability to declare function parameters and return values non-nullable (Forbid passing nil into a function, and declare a function will never return nil).
That would get rid of the "panic: runtime error: invalid memory address or nil pointer dereference" errors.
https://wakatime.com/blog/48-go-desperately-needs-nil-safe-t...