Earlier quoted context omitted.
It's similar when online editors try to be clever and replace a straight " with a fancy one (like in Word), really annoying.
That's why Powershell actually recognizes those fancy quotes and treats those as normal quotes.
Expectations for generics in Go 1.18
181–190 of 209 posts
Re: Expectations for generics in Go 1.18
#182Earlier quoted context omitted.
Often the people that expressed that opinion are different people then for example the person you responded to here. Please remember that this is a forum of a very big group of participants with varying points of view and resulting opinions. Even if he was previously a person that said golang doesnt need generics, I struggle with your point of view. It seems you're of the opinion that nobody should be allowed to... c…
You're arguing for charitable interpretations of statements by people who claimed Go didn't need generics or even that Go was better without them, saying that one should be able to change ones opinion without being called dumb. I fully agree. Similarly, a charitable interpretation of what kubb wrote would be that they are referring to those who might have been dishonest in their defense of Go's lack of generics, whic…
Re: Expectations for generics in Go 1.18
#183I'm glad that all the blog posts written by the apologetes and zealots, claiming that Go doesn't need generics and how they will actually be a detriment to the language, are archived somewhere in the wayback machines, so that they can't gaslight us into believing that they weren't just being silly for all this time.
This attitude/mindset seems so petty and disappointing. Feels to me like gotcha journalism or something.
True, but not as disappointing as the attitude of the go language creators and maintainers.
Re: Expectations for generics in Go 1.18
#184Earlier quoted context omitted.
I wrote a comment here pushing back somewhat on the idea that Rust has much better error handling ergonomics (not correctness, where it clearly wins, but ergonomics) but thought better of it; debating Go vs. Rust is about the least productive thing we can do on HN.
I like what Chris Lattner said about language design in Lex Fridman podcast, that you know when you're doing something right because it "feels" right. Rust has a bunch of syntactic sugar which gets critised in many languages, but to me things like error returns with ? "feels" right. Love Go as well, and the error handling makes a lot of sense in concept but it just doesn't "feel" nice to look at or use. I like there'…
Absolutely false. When you write the really groundbreaking and important software "feels right" is absolutely not what you should be experiencing.
The correct mode you should be in is "holy fuck how did I get here, and can I come out in one piece"?
(A: no, you can't, but the new you will be a better you.)
Re: Expectations for generics in Go 1.18
#185Earlier quoted context omitted.
In 10 years a new word may become fashionable. Better to keep technical terms the same.
It's not about fashion, it's about cultural identity. I take it you don't see a problem with master/slave either? Just do a find and replace, refactoring is easy and trying to argue on the internet about it is tiring.
> trying to argue on the internet about it is tiring.
… exactly.
Re: Expectations for generics in Go 1.18
#186Earlier quoted context omitted.
This attitude/mindset seems so petty and disappointing. Feels to me like gotcha journalism or something.
> This attitude/mindset seems so petty and disappointing. True, but not as disappointing as the attitude of the go language creators and maintainers.
I'm pretty sure none of the Go language creators or maintainers has a negative attitude towards generics.
Re: Expectations for generics in Go 1.18
#187Earlier quoted context omitted.
You're right. I maintain a very large code base in a private repo and a successful open source project. Generics will allow me to clean up a lot of code duplication internally, but given that Go modules are distributed as source code, this would force everyone to use Go 1.18. My plan is to not use generics for quite a while, as it's pointless to have two separate implementations, one for 1.18 and one for < 1.18, whic…
Upgrading to the latest release of the Go toolchains is generally a painless experience; the Go team has a good track record of enforcing backward compatibility. Hopefully this means that you can assume other users will be able to use code targeting new features of go 1.18 in pretty much the same time window it takes for other releases to supplant old ones, and make this feature not unlike previous (minor) language f…
Hacking on some projects or experiments is one thing, but say you're providing code for the automotive industry or the payment card industry; you're in for a world of regulatory hurt.
Re: Expectations for generics in Go 1.18
#188Earlier quoted context omitted.
Don't you need sum types/sufficiently powerful enums for Result though? Which, in a way, makes it a language feature.
You’re confusing the chicken for the egg. Sum types are a powerful language feature, but they’re also a general language feature, they don’t exist for the sole purpose of creating a Result type (and indeed a number of languages have had the former and lacked the latter).
Re: Expectations for generics in Go 1.18
#189Earlier quoted context omitted.
AFAIR, Zig has an open issue on how to pass additional context with errors, such as e.g. row & col where a syntax error happened.
To clarify I thin parent means syntax error I'm the sense of "I'm parsing a (code) file at runtime and there's a syntax error", not a language syntax error. I mean there's nothing stopping you in zig from creating a rich "error" struct and returning a union of the struct with whatever you would have done otherwise. You only lose the error return trace.
Thus Rust's std::result::Result where the E in Err(E) is anything that implements the std::result::Error trait.
Rust got this right. It satisfies most use cases with the least possible noise and accommodates the weird ones easily, and does it in a std:: codified manner where no one has to wonder whether or not there is anything stopping them.
Re: Expectations for generics in Go 1.18
#190Earlier quoted context omitted.
On the question of "what's this?": type ImmutableTreeListᐸElementTᐳ struct "If you look closely, those aren't angle brackets, they're characters from the Canadian Aboriginal Syllabics block, which are allowed in Go identifiers. From Go's perspective, that's just one long identifier." Simultaneously amusing and disturbing. Is there an award for which one might nominate this person?
> oh my god Definitely the correct response. Also, > c++ allows 0-width spaces in variable names. Where's your god now? Nowhere. We have strayed maximal distance from god's light and are currently in orbit around Satan.