Give zoomers a break. Most people have terminal baby duck syndrome and will sacrifice anything for convenience, regardless of age.
Give zoomers a break. Most people have terminal baby duck syndrome and will sacrifice anything for convenience, regardless of age.
some context: “pogo” is a brand of frozen corn dogs which is for some reason also a cultural staple
that person is an embarrassment. thinks it’s OK to be a reactionary so long as you pick safe targets. block and move on. or if you absolutely have to punch up or sideways, try to be funny jfc
and hexbear mods this means you too. do better
To clarify, enculé means “someone who gets fucked in the ass” and has its roots in homophobia but nowadays that’s not really part of the intent.
Never figured out what “de ta race” is supposed to mean though. Maybe “you’re a poor representative of your race”?
It’s archaic but I love “raclure de bidet”. Comparing someone to the stuff you would scrape off of a bidet where all sorts of people have washed their taint. Short and loaded with contempt.
“Gibier de potence” is great too. Means “game for the gallow”, with the term “game” using in the hunting sense. Basically someone you think should be executed.
Also “chien sale”, dirty/unclean dog, which for a reason is a stand-in for “asshole”.
You can, if you want, opt into warnings causing your build to fail. This is commonly done in larger projects. If your merge request builds with warnings, it does not get merged.
In other words, it’s not a bad idea to want to flag unused variables and prevent them from ending up in source control. It’s a bad idea for the compiler to also pretend it’s a linter, and for this behaviour to be forced on, which ironically breaks the Unix philosophy principle of doing one thing and doing it well.
Mind you, this is an extremely minor pain point, but frankly this is like most Go design choices wherein the idea isn’t bad, but there exists a much better way to solve the problem.
If only there was some way the compiler could detect unused variable declarations, and may be emit some sort of “warning”, which would be sort of like an “error”, but wouldn’t cause the build to fail, and could be treated as an error in CI pipelines
The language was designed to be as simple as possible, as to not confuse the developers at Google. I know this sounds like something I made up in bad faith, but it’s really not.
The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt. – Rob Pike
"It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical. – Rob Pike
The infamous if err != nil
blocks are a consequence of building the language around tuples (as opposed to, say, sum types like in Rust) and treating errors as values like in C. Rob Pike attempts to explain why it’s not a big deal here.
DRY means Do Repeat Yourself, when the alternative is cooking up some awful OOP abstraction