I’m amazed that people still say things like “de-accent” as if there was such a thing as “no accent”. You are asking for a button that makes his French accent more like your own. It’s a separate thing from native vs. non-native speakers - there are plenty of native English speakers with accents that you would also find challenging.
You are reading something into my comment that wasn't there in order to pick a boring fight. There is of course no such thing as no accent a priori, but there is such a thing as "accents understood by (vastly) more people" and "accents closer to the mean accent of native speakers". When I learn Russian, my English accent is not on the same footing as a Muscovite's; the intended notion of "de-accenting" the English accent on my Russian is obvious.
Consider responding to the substance of the comment instead.
> accents closer to the mean accent of native speakers
Notice that, for the case of English, most speakers are not native, by a huge margin! Native English speakers are a biased minority, and with a lot of variation within. Not sure that an "average native" accent is a useful concept at all. I, for one, tend to find most non-native English speakers vastly easier to understand than many native speakers.
> Notice that, for the case of English, most speakers are not native, by a huge margin!
I'm well aware, and this does not rebut any of my points.
> I, for one, tend to find most non-native English speakers vastly easier to understand than many native speakers.
That "many" native speakers in a language of hundreds of millions of speakers are hard to understand does not challenge the claim that a non-native accent brought closer to any native accent, much less the mean native accent, will for the large majority if listeners be easier rather than harder to understand.
... and then you run a script that depends on `/bin/bash` .. but uses a feature (e.g. coproc, associative arrays) from a version less than a decade old. And then you go and update your PATH and shebang lines to call out `/usr/bin/env bash` and hope things go right.
In France there is employee taxes and employer taxes. You discuss before employee taxes, but after employer taxes (which is about 50% of the salary before employee taxes). If you're on a French payroll the amount is written on your payslip, but most people don't even notice it.
At the end of the day it doesn't really matter if it's an employer tax or an employee tax, the employer spends some amount of money and the employee gets a portion home. But the discussion never includes employer taxes.
“After tax” in the US means after the employee pays their own share of various income taxes. The portion of those taxes paid by the employer are not discussed (in salary discussions).
Either way, the point stands - for cross-border salary discussions, you need to consider the “fully loaded” cost of an employee, not just net salary. You also have to consider non-cash benefits and costs (high US salaries offset by high health care costs, etc).
Once you go fully remote you don't really need employment contracts either - in Europe opening some sort of legal entity and invoicing your salary as an independent contractor will be more profitable and more flexible.
I have; last time when I was looking for a job, some employers (and mostly recruiters) asked me what I'd like to earn per month after taxes.
I'm sure there's some shuffling they would end up doing when it comes to wages, stock options (not really a thing), transportation, and other benefits.
I'd never discuss that with a recruiter, because that would involve a discussion about how I conduct my personal finances well beyond just the salary and other benefits... E.g. additional pension contributions I make, or investments I make would affect it.
I'm sure you have - but not after income taxes. All taxes that are taken before you get your gross (before income tax) pay, is typically what is quoted in Euerope.
E.g. My employer pays X1.25 for my "before tax" salary of X because there is 25% payroll taxes/fees.
I pay 35% taxes on that, so my net is 0.65x. Is X "before"or "after" taxes here? It's after payroll taxes and similar deductions, but before income taxes (which I pay myself).
As one data point, people never discus before-tax salaries in my home country (Croatia), it's always after-taxes and all other mandatory deductions. I believe the same holds true for at least several other EU countries from the region.
by "people never discuss" you mean the negotiation between the employee and employer is based on after tax salary, or do you mean casual conversations with friends? I haven't seen discussing after tax salary at all during interviewing process in the 4 countries I applied for jobs and got offers (Slovakia, Czechia, Switzerland, Denmark).
Officially, on the employment contract, the salary is shown before-tax, but after mandatory pension and healthcare deductions.
However, in the negotiations, in casual conversation, and when you're hearing someone talking about their salary in the media, it's always discussed after taxes. Most people have no idea how much tax (or health insurance) they're actually paying.
In Finland, I usually hear people talk about salaries before taxes and less often after taxes. For example my union has a yearly salary survey and publish results in before taxes salaries. But since it's so confusing, you usually see "brutto" ("gross", before taxes) and "netto" ("net", after taxes) being discussed when talking about salaries.
How do they know what your tax rate is? Especially in the context of "work from anywhere" as in OP, employees can have a wide variety of tax situations.
The tax rate is flat and there are no deductions. There are no local relative taxes (as in a percentage of your income), everything is in absolute values.
And if you're working from another country, then you're a fiscal resident in that country and you have to pay taxes there. But in that case you'd be a contractor or own a company, so that's a totally different story.
> Would you prefer your pilots to fly your plane with no AI assistance?
There is nothing that remotely resembles AI in the cockpit of any current airliner. All flight control logic including autopilot, autothrottle, TCAS & GPWS, ILS & autoland, and so on are based on simple feedback loops and programming techniques that go back decades.
Sure, but it needs to know that there are new messages. I don't think that's a separate permission on any (e.g.) ActivityPub/XMPP/IRC server implementation today.
On all XMPP server implementations I've worked with, the push notifications mechanism supports (and usually defaults to) not including any message body in the API call to the push server. Usually it's also possible to leave out the sender name/JID, e.g. with prosody's mod_cloud_notify.
> Because in golang everything is UTF-8. After all, Rob Pike authored both golang and utf-8.
That's a terrible reason. HTTP header values are not necessarily UTF-8, and an implementation that blindly assumes they are is broken.
> Now, what are the security implications of this? (beside the chunk thingy)
Many variations of the "chunk thingy" where values considered safe in one context may be unsafe in another context.
Like so many parts of Golang, this is a good example of how "good enough" engineering often really isn't good enough. HTTP is pretty thoroughly specified, and the HTTP stack included in a language should be thoroughly tested against that spec. If you can't achieve that, just leave it out of the stdlib!
> Actually, they are explicitly specified as ASCII
They are not, only new headers added after RFC 7320 are ASCII, pre-existing ones may contain high-bit characters which implementations compliant with 7230 version of HTTP/1.1 SHOULD not parse. They stopped short from making it a MUST so that applications compliant with RFC 2616 (where they were to be treated as ISO-8859-1!) was allowed. Or, more simply, they stopped themselves from making RFC 7230 describe new, incompatible HTTP/1.2.
Yes, but this simply means that header values are not (Go) strings, they're byte arrays. Many languages represent them this way, with a (fallible) function to get the string value iff the byte array contains valid UTF-8.
The whole "it would be more work" as a justification for not doing things properly is one of the roots of the more general issues with Go I alluded to in my post above.
1) Go string type is specified as a sequence of bytes. Full stop. Any encoding, binary blob, string does not care. Particular stdlib string functions _do_ care, expect UTF-8 encoding and document the fact. Other stdlib string function work with the sequence as a sequence.
3) Go specification requires UTF-8 in only one place: the encoding of Go source files string literals.
2) Pure ASCII is a subset of UTF-8, ie. pure ASCII _is_ valid UTF-8. There is _no_ more work and there are _no_ security problems when working with pure ASCII as UTF-8, because that's what it is.
