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'
211–220 of 481 posts
Re: Go Replaces Interface{} with 'Any'
#212This 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. An…
> I thought that using an empty interface to represent "any type" was kind of ingenious
It makes me a bit sad to read that. We all are on a journey to be become better developers every day. But things like that are like a distraction. They make you think you found a really cool and smart concept, but you actually didn't and it's essentially just a hack.
Not sure what the solution can be. But PL designers should be more clear about features that are just "hacks" and considered "bad" but necessary in practice due to certain constraints. Go's {} and nil-errorhandling are examples. Nulls (in any language) are another common example.
Re: Go Replaces Interface{} with 'Any'
#213Earlier quoted context omitted.
The Go code parsing libraries are quite good though. Not sure what else you could want re. code generation.
Basically macros, like in Rust, not like in C. Rust can do stuff like the serde serialization library while Go has to rely on reflection with its obvious performance drawbacks.
Go could do something similar if you're willing to run `go generate` as part of your build process. For most Go applications, the reflection overhead is a fine price to pay for convenience, just like GC is a fine price to pay for not having to deal with the borrow checker. Obviously, these tradeoffs don't hold for all programs, but Go has definitely found a niche.
Re: Go Replaces Interface{} with 'Any'
#214Earlier quoted context omitted.
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?
In C++ there could be 7 or 8 different ways go about implementing similar functionality. This is powerful in that it lets you do exactly what you want because each of those ways is subtly different and sometimes you need each one.
Go's proponents think it's okay to be a bit less powerful so that there is only 1 maybe 2 ways to do something. This makes code at different companies more similar.
It also mean that a new grad can join the team, read the code, copy it, modify it some, and it's pretty much right. A staff SWE and a new grad will right very similar code in Go. In C++ it's anyone's guess how similar their code will be.
Re: Go Replaces Interface{} with 'Any'
#215Earlier 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
Huge no to anything that will require .unwrap() noise everywhere in the codebase. I use Erlang, my code does not have ".unwrap().unwrap()"[1] anywhere.
[1] https://github.com/SeaQL/sea-orm/blob/64c54f8ad603df0c1d9da8...
Re: Go Replaces Interface{} with 'Any'
#216Re: Go Replaces Interface{} with 'Any'
#217Earlier 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…
Get your point, but I kind of like it. It tells some really important info, and they are hardly alone. Python 3.x was breaking change. Until they they stayed in 2.x versioning a long time. And we will never see a Python 4.x
Python also makes breaking changes in minor releases; 3.5 introduced async/await and 3.7 made them reserved keywords.
Re: Go Replaces Interface{} with 'Any'
#218Earlier quoted context omitted.
Yea, I am not really fan of 1000 line stack trace for an error in single line. I like Go's error handling better. Also it is clear you like error handling in Rust/Java etc which is fine. Exaggerating over how bad error handling in Go is hardly productive when a) many people do like it b) people can switch language when error handling primary concern over everything else.
How will you fix that bug in production when you can’t reproduce it and only has logs? Stacktraces are godsend.
Well as I said people do like stack traces. Hell, I work on language which just has exception stack traces as error handling. I find it hit and miss not godsend when fixing production issues.
Re: Go Replaces Interface{} with 'Any'
#219Earlier quoted context omitted.
Any language based on JS can't be safer than Go. The end result of TS is JS which is a dynamic language.
Ok, so if Go compiled to JS it would be a dynamic language? https://github.com/gopherjs/gopherjs
Ultimately everything ends up as machine code, which is untyped.
Re: Go Replaces Interface{} with 'Any'
#220Earlier 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…
doesn't matter how "big" of a change it is, it matters if it breaks anything. that's the whole point of semantic versioning.
also how is "big" even measured? meters? kilometers? it's immeasurable, which is why the rule is to update the version number based on what changes break existing code, because that can be measured