Oh, and I'd like to know how many 10 year old kids should be reading about them on a daily basis? I bet that really helps settle their minds when they go to school the next day!
>In your estimation, how much graphic violence should my operating system show me on a routine basis?
I think it's simple: the amount that maximizes the OS vendor's profits.
If you don't like this, you're free to choose a different OS vendor, or use a free OS, of which many variants exist.
Personally, I applaud Microsoft for doing their fiduciary duty and maximizing profits, even if that means pissing off their users who refuse to abandon the platform.
I have never needed generics in Go, and I've probably been using it since 2017. I've never even once had to resort to any interface{} trickery to express what I want, and I've written Go programs for Fortune 50 companies, as well as complex personal projects such as AST parsers/code generators.
I'm pretty disappointed to see generics introduced into the language and every example I've seen feels completely unreadable to me compared to pre-generics implementations.
To be clear, it has never been the case that the Golang authors were 100% against generics. It has always been their position that the implementation needed to be good enough to make the trade-offs worthwhile. I just don't think they chose the right trade-offs.
> I've never even once had to resort to any interface{} trickery to express what I want, and I've written Go programs for Fortune 50 companies, as well as complex personal projects such as AST parsers/code generators.
That's pretty surprising to me. Have you never had to implement marshalers for unknown types and such? I have had to implement things like json.Marshal and json.Unmarshal for different encodings dozens of times in my Go tenure. I have had to use reflection a lot. I have had to deserialize into map[string]interface{} to handle ambiguous situations at runtime a lot. Have you never even had to wrap or build your own Printf equivalents that accept interface{}? No loggers? No custom containers? None of that which operates on unknown types?
I see use of interface{} all over the vast majority of Go projects. I think your experience may be atypical.
It's entirely possible that, through some strange quirks of circumstance, I've managed to avoid every problem space that would make me wish for generics.
In spite of that, it's unlikely that I've written implementations where using interface{} would be easier to read and reason about than not using interface{}. And the experience of the author whose blog post we're commenting on tracks with mine: "In my 5+ years working in Go, I can probably count on one hand the number of times that I felt like I really needed generics." I can too, just without using any fingers :-)
I feel the similar way, though I wouldn't be so brave to say I didn't ever use interface{}. I think we all work around slices and maps being the only generic containers and don't know we do. I think everyone will find that while they didn't need generics, they will help them when using utility libraries. Java 1.4 people thought the same.
I expect well-curated libraries to come about that will really simplify some otherwise difficult problems for people (e.g. task/object pooling). I'm even toying with a futures impl at https://github.com/cretz/fut, but I wouldn't use it in place of channels in most cases.
Yes. It would be short-sighted to dismiss them out of hand, and it's possible that generics will provide a level of expressiveness and readability I haven't anticipated yet. I'm fairly bearish on it for now.
> I have had to deserialize into map[string]interface{} to handle ambiguous situations at runtime a lot.
Something I worry about is if I'm getting too jaded. You really think things are different elsewhere, but then you see that we all eat the same shit sandwhich.
That code would never have to be written if someone just used their brain before switching their integer IDs to string GUIDs. Bless your soul but I wish we didn't have to resort to such things. Some things code can't fix.
> as well as complex personal projects such as AST parsers/code generators.
Funny you say that because for me that's the one use case I have for generics.
(edit: why the hell am I getting downvoted for posting a fact? I wasn't offensive, argumentative, etc. Just citing one example I've run into where generics would help me personally)
There are areas where they will help, and be pretty transparent to the user, lots of places in the stdlib, one trivial example: math.Max(a,b) could take any numeric instead of just float64, sort could be neater etc.
Perhaps a Go 2 if they ever get there could be a generic std lib rewrite, largely transparent to the end user, with some minor incompatibilities allowed and lots of stuff rewritten behind the scenes. They could remove a few ugly corners in the stdlib naming specific types by using generics, add a few more container types perhaps, deprecate some old stuff and move it out.
The os package makes use of a *File struct rather than an interface. The authors acknowledged this was a mistake but it's some of the oldest code in Go and Go's backwards compatibility guarantee has meant that they cannot fix that.
Since I author a $SHELL written in Go, being able to add in my own *File methods would have allowed me to add in some cool features. But I've found workarounds in most cases. It's just not as clean code as it could have been.
And what I'm saying is that interface was created after os.File was created and after go 1.0 was released thus that change now cannot happen without breaking the backward compatibility guarantee. Hence my point about go v2.0
Is this one better? It does run and doesn't rely on casting (not sure why GP's source took that route, it was lossy and kind of dumb). I suspect the compilation problem was because of a change in the syntax between when that was created and today.
Why not? You later seem to think that this would require reflection - but that makes it apparent you don't understand how generics work in a language. They're used at compile time - to avoid runtime checking.
You certainly might use them to write a facade which made life easier for consumers of the math pkg and accept floats,ints or uints even if behind the scenes it splits into different implementations.
Most Zoomers have already accepted that they are not going to have children or live very long.
I think following their example is the best one can do on an individual level. It’s baby’s first civilization and it’s over. Acceptance at least allows one some dignity.
What problem is this solving? NYC doesn't have a problem with people either not being able to drive or not knowing where they're going. We have workable (for an American definition of workable) mass transit and several livery services including taxis and Uber.
We're trying to get rid of cars here. Congestion pricing, the widening of pedestrian and biking thoroughfares, just to name two initiatives. We don't need more cars, regardless whether or not they're being human-driven or not.
I agree. Public transportation in the US is great if we use 1950s standards. It’s falling behind because politicians don’t have a long enough cycle to see the fruits of their labor.
NYC needs to up it's biking game. It's getting there but still a long ways away. Plus riding a citi bike is like a life-or-death experience half the time.
Less a "late response" and more the start of keeping a promise made by Jobs in 2010 to make FaceTime an cross-platform product supported by open standards, that was hampered by various legal I/P battles: https://www.imore.com/wheres-facetime-android
It supports many more kinds of secure data than passwords and credit cards. It has specific entry types for bank accounts, passports, reward programs, software licenses, and so on.
It also has lots of built in analysis tools for determining:
- which of your passwords are reused, weak, or present in online password dumps
- what websites can have 2FA enabled on them
As well as the ability to store entire documents in vaults.
Been using 1Password since 2008 and it's the only software of its kind I recommend to anyone on any platform.
Depends on who is defining the term, and in case of law, jurisdiction. Some places define both parties as guilty of adultery. Some only do so contingent on whether it was the man that was married, or the woman (e.g. Utah).
Morally, it is fairly unambiguous. If the unmarried partner knew they were banging a married person, they are just as responsible.
> Morally, it is fairly unambiguous. If the unmarried partner knew they were banging a married person, they are just as responsible.
Perhaps that's your moral view, but it does not represent everyone else's morals, so I don't know why you're claiming it to be "unambiguous". There's plenty of people who would say that the unmarried person in an affair shares less of the blame than the married person in the affair. For starters, the married person breaks a contract, whereas the unmarried person does not have a contract to break.
> but it does not represent everyone else's morals
Yes, I'm sure you can find at least one person who doesn't agree. Maybe yourself. But how much do you want to bet that if you asked this question to 100 people, better than 90 of them would agree?
> For starters, the married person breaks a contract, whereas the unmarried person does not have a contract to break
I said moral, not legal. A few people only define right & wrong based on what they can legally get away with, I understand.
> But how much do you want to bet that if you asked this question to 100 people, better than 90 of them would agree
I would guess that more than 50 of those 100 people would agree with me that the married person shares more of the blame than the unmarried person.
Anyway, even if you're somehow better than me at guessing what other people think about moral questions, to the point where so much as 90% of people agree with you on this one, is that "unambiguous" in your mind? I would think "unambiguous" is something like 99,99% or more.
> I said moral, not legal.
I was also referring to a moral contract, not a legal one. Most people who are in a marriage have an agreement between each other that they shall not mess with other people (not a legally enforceable contract, but an agreement nonetheless). If you dedicate yourself to one person, and then you go and betray them behind their back, you're breaking a certain moral code. That's my opinion. If you think that the married and the unmarried person share equal blame, I guess you don't see anything wrong with breaking that contract? If committing adultery is just as bad as committing adultery PLUS breaking a contract, then clearly in your mind breaking a contract is not bad?
You're confusing Joel/StackOverflow for Jeff Atwood, who posted on the forums while designing Discourse.
Atwood was lambasted for not understanding the SA forums culture before making assertions about it, and for being seen as wanting to ignore the necessary role that human moderation plays in maintaining strong communities.
