Grover Norquist, prominent conservative voice and head of Americans For Tax Reform has talked about the danger of government provided filing services, namely that he believes it leads ultimately to increased taxes.
The idea is that if the govt is saying how much you made, how much you owe, and just giving you a place to click "OK", it's on the tax payer to do the math to disagree, and the govt has incentive to find you owe more. And, taxes are less visible and easier, so if taxes go up or policies change, all the americans just confirming and hitting "Pay" aren't going to notice or be mad.
Or, something like that.
Daycare was an anti-perk for Google, practically speaking.
It was a huge waiting list to have a chance, and a small fraction got to use it, so most parents just got to be somewhat frustrated by it.
Lots of perks aren't widely used, but mostly by choice; a perk I could potentially use is still a perk, and it feels good to have that option.
Pushing toward remote work or asking someone to work on a different campus also makes the on-prem daycare a bit weird.
But yeah, a company day care that has enough spots to serve most interested parents would be a pretty nice perk. But, I think for most parents, a daycare near home is much better, especially those not working from office every day.
It's a misquote of the common idiom "let them eat cake"
> "Let them eat cake" is the traditional translation of the French phrase "Qu'ils mangent de la brioche", said to have been spoken in the 18th century by "a great princess" upon being told that the peasants had no bread. The French phrase mentions brioche, a bread enriched with butter and eggs, considered a luxury food. The quote is taken to reflect either the princess's frivolous disregard for the starving peasants or her poor understanding of their plight.
If they brought in some trustworthy skeptical folks with some tools and enough background to know what compelling nothing looks like, and they came out saying, "Oh man. oh wow. I'm trying to come up with another explanation, but it really seems like they have it."
I'd start taking it seriously.
"Guy who seems trustworthy said it's real and he saw the proof" is so very normal, for aliens, ghosts, various religious phenomena.
"Someone was convinced" isn't compelling to me.
"The specific trustworthy non-believers who were given access to the evidence were convinced" would shake me.
That moves it from "might be a delusion or hoax" to "if it's a hoax/fraud, it's a very good one".
Although, "specific physical / recorded evidence made publicly available for study" would be even better if the evidence is strong. Once you're at "if it's a hoax/fraud, the perpetrator has advanced science we don't" it's a world-changing thing; maybe it's not an alien, but whatever it is it's amazing.
Nothing remotely close to that will ever happen, because the people who care about this don't care. In the same way that you want extraordinary evidence to back up these extraordinary claims, they are prepared to disregard any and all evidence to the contrary in order to continue believing all of those same claims.
If you haven't, I recommend watching the YT minidoc "In Search of a Flat Earth" by Folding Ideas. It's not about the aliens, it's not about the earth being flat, it's about the conspiracy and who is behind it. If you dig deep enough, it's always rooted in some racist or antisemitic world view.
I'm healthy and enjoy a good walk, but I wouldn't really want to bring luggage a mile from an airport, especially not if the weather isn't nice; it seems rare for foot traffic out of airports to be particularly easy.
I walk nearly a mile (1.2km) just to get to the nearest bus stop (that buses come to often) from my airport. I only travel with a backpack though. You're right in that they don't have sidewalks though out of the airport area.
Yes, the output always feels to me like a reasonably clever and informed person just bullshitting; as someone prone, it's familiar.
But, good-sounding shallow thinking is still pretty dang useful.
I've been on teams responsible for components written in more niche, powerful languages by previous employees who were deep in that particular language community.
The author was really smart, the code was good.
It was a big headache.
First off, different build setup, different runtime, couldn't use most of our standard libs, so it was an island.
It being in a language most people didn't know well meant it mostly only got updated as necessary; we certainly had people who could read the code and make tweaks with some comfort, but it was mostly just tweaks because nobody had the depth to really engage with the high level design idioms.
It being a niche lang/community, it moved fast, so after a year or so our tool was apparently using deprecated practices; in our supported languages, teams did large-scale fixup across repos for new versions, but this being a special lang/toolchain, it was on us.
Eventually, I believe it got rewritten, somewhat simpler, in one of our supported languages, and it was fine.
Maybe this is a success story: someone made a useful tool in a weird language and we used it successfully for at least a year. Maybe it wouldn't have been made or would've been worse or more expensive if they'd been forced to write it in a supported language. Maybe it would've needed to be rewritten anyway.
My view is a simple one; as one of the leads responsible for it, it was a special case bit of code, something people tried to avoid touching. Nothing about it required a niche language technically, so the added difficulty of working around that was friction and risk. It wasn't that people couldn't learn the language; they could, we had lang PhDs. It's just better if you can keep people where they have existing expertise, and spend your learning points on solving problems users care about.
I don't think "avoid otherwise-unused languages for secondary tools" is the same as "avoid less common languages for your main product". Every software developer at your company will likely work on your main product for a non-trivial amount of time. Any software developer who can't figure out a new language in a trivial amount of time isn't worth hiring. Thus, everyone you hire will eventually be competent in the language of your main product.
In contrast, for secondary products, there's a good chance most developers will never work on it at all, and of those who do a significant fraction will spend only a trivial amount of time. Adding the overhead of working in a new language to that balance is significant.
Therefore, the ideal is "Choose the best language for your main product, then write all supporting software either in that language, or a widely-used lingua franca like Python".
I think it may be an uncomfortable truth for many language enthusiasts that with a decent compiler/runtime and a reasonably skilled team, you can write very good software reasonably efficiently in even a mediocre language.
Language design absolutely matters in terms of what can be expressed efficiently, what classes of mistakes are hard to make, what performance you can expect in normal code, but rough memory safety, some static typing, and basic abstraction gives you a lot of the value there, and you can close a lot of the remaining gap in language capability with some discipline and process.
Naturally, ideally we'd still only use perfect languages, and not allow errors that could be avoided or suboptimal code, but not all PL power is free and personal taste/experience isn't irrelevant, so I'm not too surprised that some people prefer a tool that to me seems worse, because empirically it often works out quite well.
It is not all the sudden as far as I can tell.
There's a long history of Go hate, and it makes sense to me.
Go is a new(ish) and fairly popular language, which already guarantees some level of hate.
More substantially, it is an implicit argument against most things language enthusiasts like about programming languages; it's lack of static features and dynamic capability, it's non-focus on optimality in any domain, there's no attempt at uniform elegance or a motivating theory, it's just a kinda mundane procedural language that tries to solve some problems C enthusiasts had while avoiding the things that bugged them about Java and C++ (to oversimplify).
A language such as that succeeding socially and practically is borderline offensive to folks who love clever language and runtime design, who love things that can push the boundaries of performance or verifiability.
Something so apparently mundane and poorly thought getting traction is a regression in the world of software engineering, supported by a Big Evil Corp that many folks dislike.
I've also personally seen a social meta-effect of this, where in a particular space all of the language aficionados would make a point of dumping on Go whenever Go was discussed (or even when a dig at Go could be shoe-horned into another discussion), and at a certain point there are only negative discussions of it, and the snobbery (justified or not) is a form of social bonding.
Of course, there are loads of legitimate criticism to be applied to the language design, the runtime, the rollout, the marketing, the framings of the authors, but there's a persistence, a snarl, to some of the critics that seems to me to go beyond an observation of the real issues. For reasons listed above, some people seem to take hating Go quite personally.
What exactly is novel about Go? The only thing that comes to mind is go routines, but it is not integrated well in the language for several reasons, and concurrency is just a very hard problem. Otherwise it is the exact same thing as the litany of basic managed languages.
Why should a language be novel? If you have to hang something on the wall, are you going to discard screws and plugs because they've been around for quite some time?
Go is good enough. It has some short-comings. I'd like to see non-nullable types, even though I haven't had a memfault in ages. But it's easy to write it, runs fast, is memory efficient, and runs practically everywhere without a fuss. For normal software, that's such a big plus. I'd hate to have to go back to Java.
Languages have advantages and disadvantages, aside from being novel. Java is a memory hog in comparison to Go; Go is probably a bit faster in execution. The "eco system" for Go is pretty good, tooling too; I'm sure Java has a larger set of libraries and frameworks to choose from, but less easy to integrate. Idk about the current state, but Eclipse and Netbeans were so unpleasant when I did Java.
“Hogging” memory correlates with better throughput in case of GCd languages, and Java really shines on this front, it is not an accident that it is the numero uno choice for big backend services. Performance is also not really in favor of Go besides basic examples where value types can help. Any bigger example, and heap allocation won’t be avoidable and Java’s GCs are the state of the art to a huge degree.
And the final point, why reinvent the wheel each time? Go recreates a bunch of tooling, ecosystem that already existed.
A lot of people are treating it as an opportunity to port ___ to Go and put it on their résumés, which would be less compelling if you could easily reuse the original ___. We went through the same thing with “pure Java,” but those rewrites were at least improving memory safety and (often) error handling over C and C++.
