8,261 karma · joined January 12, 2012
Pinging your personal server every time someone runs your CLI tool is not something people would expect or be happy to learn about after the fact.
I understand you're curious how many people are using your tool, but this isn't the way to go about it.
- HEADLINE: Please make system settings more accessible and consistent
- DESCRIPTION: I understand that system UI has been a bit volatile in recent years. The GUI has looked different almost every time I've installed a new Ubuntu, and when a big overhaul happens, it takes some time to flesh out all the stuff on the periphery. This sort of thing is unacceptable, however: https://twitter.com/Zikes/status/829882331959795712
I'm a bit of a "power user" yet I struggled to accomplish something as basic as adjusting my mouse pointer speed. It's just those sorts of oversights that prevent me from being able to recommend Linux to family and friends.
If the issues listed are largely the same issues faced by men, and if the issues have an equivalent impact on male engineer retention, then the answers are incomplete or we're asking the wrong women. Maybe we should ask female former engineers why they left the industry?
The only point I'm trying to make is the obvious one: men and women are different. It's a stupid point, taken at face value, but it's one that seems to get lost every time someone says "but men face those same issues" or "that doesn't seem like a gendered issue to me".
Taken individually, you'll find folks all over any given spectrum, but if we're going to address "Women in Tech" vs the implicit "Men in Tech" then we can't just say "well the two are exactly the same and therefore there's no discussion to be had."
Of course there's differences between men and women. Different values, different priorities, different sensitivities. Maybe there are issues in nursing and education which men are more sensitive towards, and that's why there's such a larger opposing gender disparity in those fields? That doesn't mean that either gender is necessarily "weaker", just "different".
If we want to help technical managers retain women, then it would be helpful to determine which issues women are generally more sensitive to, even if they're the same issues men have faced for however long but which have not driven them away from the industry.
The Go team wants generics. They acknowledge that generics would be a benefit to the language, and they have acknowledged that generics are by far the most-requested language feature from full-time Go developers. The only thing stopping them from implementing Generics is the inherent (purely technical) difficulty in providing it in a correct, performant, and type-safe manner.
The reason the Go team cannot look to Java, or Rust, or any other languages which provide generics and say "we will implement it exactly as they have" is because Go is as different from Java and Rust as Java is from Rust. Generics had to be individually implemented in each of those languages, and it was a fairly massive undertaking to do so, and there are a lot of folks that say that in Java's case in particular it was implemented poorly but now that it's implemented they're stuck with it.
Like yourself I'm not an expert on generics, either, but everything I've read in regards to generics in Go has lead me to the above conclusion. I trust the Go core developers to implement generics when they have a suitable plan, and I will gladly use them when they are made available, but in the meantime I intend to enjoy all of the great features of the Go language which are available today.
It's something I hear often, though. That Go is intended to be a "modern" language, with the definition of "modern" being that the opportunity that a blank slate provides allows for the application of the best features and learnings of the languages of the past.
If there is a way to incorporate the best features of Haskell and Rust while maintaining Go's current simplicity and ease of use, then it should be incorporated. To that end, the Go core developers have expressed an intent to implement Generics, however they want to do so in a way that does not (significantly) negatively effect the language's simplicity or compile times.
Excepting that, we all have to accept that languages have their pros and cons, and we are each responsible for weighing those pros and cons against our personal preferences and values.
My browsing history is about to go up for sale. My emails are fair game for the US government with no warrant. My ISP is free to double-charge for peering, driving my Netflix subscription costs up. My mobile operator is streaming certain services without it counting against my data, while services I want to use still do. I have to pay ridiculous amounts of money to my ISP for a decent connection, despite the government giving telecoms huge subsidies (our own tax dollars) in exchange for building nationwide fiber, most of which went straight to the company's own coffers with no repercussions.[1]
If there was at least some back-and-forth, I would see your point, but as it stands I only see one failure after another.
I just don't see how we can win. Not without some seriously strong top-down consumer protection laws. Net neutrality needs to solidify into law, and get some serious teeth. And I'm talking Amendment-level protections, not something the next chump-in-chief can come along and pull the rug out from under like they're doing with health care right now.
If you break a rule of the Mao game you get a 24h ban, but nobody knows what the rules are.
It's true. The earliest "computers" were overwhelmingly women.
https://en.wikipedia.org/wiki/Human_computer#Wartime_computi...
An interesting thing about git, if there's an executable somewhere in your $PATH and it starts with git-, then it becomes a "git command". So in my case, I named it git-make-remote.sh, and I can execute it via "git make-remote myreponame" and it will SSH to my private git server and create the associated remote repo.
In the first case, a clot dislodged and traveled through my heart about an hour after I arrived at the hospital. I had debated waiting until morning as I wasn't sure an ER visit was necessary, but if I had waited any longer I likely would not have survived.