gofmt -w -r 'interface{} -> any' src
Is this a real command? If so, I’m very impressed. Is there any equivalent for c++ and other languages?
Go Replaces Interface{} with 'Any'
201–210 of 481 posts
Re: Go Replaces Interface{} with 'Any'
#202Earlier quoted context omitted.
But why is it satire? It makes a lot of sense for projects that don't want to commit to a stable API.
For projects like React Native, which claim production-ready and are presumably quite stable in practice, you’re back to version numbers being meaningless, except with the added bonus it’s not even useful for marketing..
It's not meaningless -- the meaning is that there are bugs. That is why the version can indefinitely approach -- but never reach -- 1.
Re: Go Replaces Interface{} with 'Any'
#203Good, 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...
I’d kill for union types as well. … and pattern matching. Maybe just some extensions for `switch`. … and one of the `try` proposals. That having been said… I do appreciate that Go has gotten where it is today by being radically simple, and that a lot of extreme care needs to be done to add new features to the language. It’s hard to draw a firm line in the sand. I feel like all of these features would work great toget…
I agree. I don't understand why the designers wouldn't want the language to be expressive. Wouldn't it be better to have an expressive language with conventions than one that's as rigid as it is today?
Re: Go Replaces Interface{} with 'Any'
#204Earlier quoted context omitted.
Emulating sum types in languages without pattern matching is extremely awkward, to the point of being almost useless. type Result[T] struct { ok: *T err: error } Great, so how do you work with it? * You can have a `ok()` getter that returns `*T`. Now you you need an `if x != nil` * `isOk()` + `isErr()` * `unwrap() T`, which panics on errors * `split() (*T, err)` that splits into separate values, especially awkward si…
The Rust Result type has: - map / map_err - and_then / or_else - unwrap / unwrap_or And countless of other functions making it very practical to chain computations without having to pattern match anything. I do the same in Erlang/Elixir. In Golang, I need to check every function call, and if I want to know where an error come from, I need to wrap it in an errors.New() because no exceptions = no stacktrace
In general, you can replace pattern matching with a function that takes one function for each constructor of the sum type.
However, doing this kind of ... sucks.
Re: Go Replaces Interface{} with 'Any'
#205Earlier quoted context omitted.
How is generics not a big enough change to warrant 2.0? Edit: I’m impressed generics aren’t a breaking change! I thought this changed Interface{} to Any as a breaking change
In semantic versioning, going from 1.X to 2.X is only indicated when there are incompatible API changes. Adding generics doesn’t break compatibility with preexisting Go code, so it’s unnecessary to increment the major version.
I feel like this is perhaps a bit of a gap in semver tbh. Sometimes a purely additive change can be quite major, in the sense that it shifts the thing in such a fundamental way that you are unlikely to try to interoperate between before and after, and are likely to run into trouble if you do.
Basically, if 1.18 code is extremely unlikely to work against a 1.17 compiler, because a new (technically additive) feature is pervasively threaded through new code, I feel like it's hard to describe them as part of the same epoch.
I don't write enough go to know if that's true for generics, but it seems like it could become true fairly quickly from my experience with other languages.
Re: Go Replaces Interface{} with 'Any'
#206Earlier quoted context omitted.
That is also true of most languages. Java (and Javascript in its attempt to copy it) are about the only languages that actually promote using exceptions for errors, and in hindsight I think we can agree it was a poor design decision. That doesn't stop people from trying to overload exceptions in other languages, Go included, but in terms of what is idiomatic... However, the question was asking what is different about…
> Java (and Javascript in its attempt to copy it) are about the only languages that actually promote using exceptions for errors Python does. Ruby does. It's not just Java and JS. Go is very open about its approach being a departure. > And actually, many APIs in the wild do represent errors as integers. Many, many APIs in the wild are implemented in (or meant to be consumed from) C, which doesn't even have exceptions…
> Python does
And it's awful. I use EAFP locally (to avoid TOCTOU and the like) at low level interfaces but I don't let it bubble up out of a function scope, because it is a goto in all but name.
I've also been increasingly using the `result` library/data structure. It's incredibly liberating to return an error as an object you can compose into other functions, vs try/catch, which does not compose.
Yes I write python almost like rust, and it's great. Strong types, interfaces, immutable types. It looks nothing like "old school python" but also behaves nothing like it. Gone are the day of "oh it crashed again, fix one line and rerun".
Exceptions should be for exceptional circumstances, not errors.
Edit: I see this is controversial. What do you take objection to? Making your python look less dynamic and more like rust? Try it before you knock it. Python's my favorite language, but I do not agree that many of the common "pythonic" patterns are good at scale.
Re: Go Replaces Interface{} with 'Any'
#207I'm not sure I like this change. I liked interface{} since it just works out naturally from Go's relatively simple type system, and anyone could come to the conclusion without actually being told "use interface{} to represent any possible value" just by having an understanding of that type system. Adding what is simply a type alias, multiple words for the same underlying concept, to me just feels like jargon. I admir…
with generics you wind up with two parameter lists, and type parameters have metatypes. All type parameters need to have a metatype, and the metatype `any` comes up a lot. Once you start using generics you'll start to feel the pain of writing `interface{}` in those signatures, especially when you are dealing with functions like this one: func doSomething[X interface{}, Y Fooer[interface{}]](v X, src Y) error { } vers…
Does a personal (not language-wide)
type any = interface{}
Re: Go Replaces Interface{} with 'Any'
#208Earlier quoted context omitted.
In semantic versioning, going from 1.X to 2.X is only indicated when there are incompatible API changes. Adding generics doesn’t break compatibility with preexisting Go code, so it’s unnecessary to increment the major version.
I feel like this is perhaps a bit of a gap in semver tbh. Sometimes a purely additive change can be quite major, in the sense that it shifts the thing in such a fundamental way that you are unlikely to try to interoperate between before and after, and are likely to run into trouble if you do. Basically, if 1.18 code is extremely unlikely to work against a 1.17 compiler, because a new (technically additive) feature is…
This seems like it would apply to literally any new feature - new code won't compile on an old compiler. It isn't the purpose of semver though, semver is trying to help you upgrade old code safely.
Re: Go Replaces Interface{} with 'Any'
#209Earlier quoted context omitted.
Well there’s a joke somewhere. Less has my favorite version numbering system. Sequential. Latest stable release: Version 598 https://www.greenwoodsoftware.com/less/
"Tell the user nothing" is your favorite system? Especially, like, what if you release a bugfix for a significantly old version? Do you give it an up-to-date number? Do you not give it a number at all? (Also I see a 581.2 on that page.)
Upgrade
Re: Go Replaces Interface{} with 'Any'
#210Earlier quoted context omitted.
Yes, it's not restricted to generics. But the reason the alias was introduced is generics. Because they use interfaces to specify bounds (constraints) for type parameters (bounded polymorphism): [T fmt.Stringer], [T io.Reader], ... So an unbounded type parameter is [T interface{}], or [T any] when using the shorter alias. It's a type alias / predeclared identifier defined in the universe scope: type any = interface{}
Couldn't unbounded just be [T]? Why the extra typing?
With generics, the metatype of a type variable is an interface type. If you just had T, it’s grammatically incomplete because you don’t specify the metatype. I guess you could just assume the any type if it’s incomplete, but that’s an unnecessary inconsistency in the grammar.