C++, Java, JavaScript, Python, Ruby, Go, now all with popular and/or official type checkers which support generic.
The normie PL bar is rising, slowly but surely.
Go Replaces Interface{} with 'Any'
121–130 of 481 posts
Re: Go Replaces Interface{} with 'Any'
#122Earlier quoted context omitted.
Well it's better than most language with exceptions. People makes it a big deal, in reality it's not.
An exception has a stacktrace. This single piece of information is crucial when you debug and makes handling errors in Golang embarrassing. I rest my case.
Stack trace was part of a proposal to add to the error package but it didn't happen. You can use third party errors packages like https://github.com/pkg/errors which wrap errors with stack traces.
Re: Go Replaces Interface{} with 'Any'
#123Earlier quoted context omitted.
Typescript is stricter and safer while also being less obtrusive than Go
Any language based on JS can't be safer than Go. The end result of TS is JS which is a dynamic language.
The usual end result of Go is machine code, machine code is not safe to the degree you would consider Go to be safe. Yet you consider Go to be safe but not TS.
Re: Go Replaces Interface{} with 'Any'
#124Earlier 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…
It makes no sense to replace a meaningful and helpful criterion - whether it breaks code or not - by some purely subjective assessment of what's a "major change." That just leads to usual version creep, from "Go 2.2" to "Go 3.0", to "Go 4.0", to (inevitable) "Go 10", "Go 11", "Go 11 Pro", "Go 11 Ultimate Edition",...
It could be worse, they could start naming these "Go WXGA+", "Go i99900kf", and "Go for Women".
Re: Go Replaces Interface{} with 'Any'
#125Their code is full of things like: type fileOps []any // []T where T is (string | int64) Go does not have neither generics nor union types. So people have to do this kind of thing :( I feel sorry for them. Reminds of Java 4 (15 years ago or something) where code was full of this crap: List /* */ values; Map /* */ map; Some devs spent a whole week doing nothing other than removing those commented out generic type decl…
> I feel sorry for them. Oh good grief. There are 32,768 programming languages. People are free to pick the ones they want to use and nobody wants your pity.
[deleted]
Re: Go Replaces Interface{} with 'Any'
#126Earlier quoted context omitted.
I don't see why that wouldn't be possible to implement now that the generics are here.
Which is exactly why I said: > I cannot wait for the Result monad. Generics make this possible, and will be a huge improvement to Go's error handling. I'm not saying it will solve everything, but it's a huge step nonetheless.
I seem to have lost track of how the discussion reached that point, thanks for the clarification.
Re: Go Replaces Interface{} with 'Any'
#127Earlier quoted context omitted.
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.
Does not Interface{} work as well as Any? I mean, most languages have while-statements cause it is more clear what the intention is.
It does, but with generics coming down the pipe, I feel that "any" expresses intent somewhat better in certain circumstances. Or at least it ought to improve readability-at-a-glance.
I'd imagine you can continue using interface{} for the foreseeable future.
Re: Go Replaces Interface{} with 'Any'
#128This 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.
I’ve been doing a lot of rust programming recently, but how exactly is the Result monad better? I feel like I end up with nested match statements for chained results, but maybe I’m doing something wrong.
Re: Go Replaces Interface{} with 'Any'
#129Earlier 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.
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…
Sounds like you think this is some kind of "Web 2.0" situation, but that was just a marketing term.
Languages are software; they are dependencies of other software (the only unavoidable dependency!) and as such should absolutely be versioned.
Versioning isn't for marketing or providing easy ways for users to remember when features were released. It's a tool for change management. Exciting features often come with breaking changes, but not vice versa.
Re: Go Replaces Interface{} with 'Any'
#130Earlier quoted context omitted.
I cannot wait for the Result monad. The state of error handling in Go at the moment is embarrassing at best.
I’ve been doing a lot of rust programming recently, but how exactly is the Result monad better? I feel like I end up with nested match statements for chained results, but maybe I’m doing something wrong.
Rely more on the map/map_err/or_else/... methods for the Result type. You'll get something like (pseudocode):
may_fail_who_knows()
.map(use_value)
.map_err(some_error_processing)
.and_then(another_computation_which_can_fail)
.or_else(with_some_error_handling_that_can_rescue)
.unwrap_or(a_default_value)