Hacker Newsnew | past | comments | ask | show | jobs | submit | MichaelGG's commentslogin

What's wrong with them having preference for people of a similar race? What's wrong for looking at the source countries of many of these immigrants and saying no thanks? No one's in a hurry to make sure lots of whites have positions in Mexico or China.

Japan has a low birthrate but doesn't accept losing their ethnic makeup is a good solution.


What's wrong with them having preference for people of a similar race? What's wrong for looking at the source countries of many of these immigrants and saying no thanks? No one's in a hurry to make sure lots of whites have positions in Mexico or China.

Well history suggests some answers to that question, even ignoring the ethical dimensions. If you choose to ignore almost all of those answers and the ethics in favor of purely selfish arguments, then realize that eventually people who look like you will be on the losing side of this equation.

Japan has a low birthrate but doesn't accept losing their ethnic makeup is a good solution.

Ok, but they don’t have a solution, period. When they figure out one that works, you might have a point?


>Well history suggests some answers to that question

Such as? American Natives arguably fared rather poorly with immigration. What other examples did you have in mind? Other countries don't seem keen on immigration. Is South Africa encouraging Europeans to come over? Mexico and a lot of Latam have difficult immigration laws. Hell I ended having to pay a few thousand dollars to have my Canadian daughter leave Guatemala because she overstayed her visa despite her mother being a citizen. Imagine the outrage if the US started applying fines to be able to leave!

>but they don’t have a solution, period.

Isn't it automation plus very very limited purpose-specific visas?


A non-American can not tell Americans what should be the their immigration policy but will always point out the fact that the immigration policy is racist and mostly formulated by minority of white conservatives. Whether it is good or bad is a separate issues. For example every American company is happy to employ non-Americans it is mostly no-skin-in-the-game bible belt politicians creating problems for them.

> Imagine the outrage if the US started applying fines to be able to leave!

Will ask my employer to pay for it every-time I leave USA for India. American shareholders will pay for it. At the moment my employer pays me competitive salary and also spends around $10k per 3 year in visa renewals. Harassment of immigrants gets passed down to American public as reduced shareholder value.


There is no value judgement in whatever I have typed. I have just stated what I have experienced. Also, it is not the Chinese or Indians who are suffering in the long run. Chinese-American and Indian-Americans are at top everywhere in USA and their home countries will be substantially better in next 20 years compared to what they are today.

The racial hatred of white conservatives only hurts them on the long run as government continues to use immigration laws, anti-terrorism laws etc. to gain more power, regulate more and engage in trade wars that destroy American wealth.


I agree with your first 2 paragraphs. The problem is that people can be convinced that there is an issue where there is none, then resort to violence on weak grounds. It is easy to get people riled up on spurious reasons. I was about to bring up BLM but see you did so:

>considering what they’re protesting, I think BLM has been remarkably NON-violent

Last year only 20 unarmed black people were shot and killed by police vs 30 whites. So far this year the numbers are 8 and 11. Counting all police shootings last year, whites are 457 of them, blacks 223. About twice the number of whites have been shot by police. https://www.washingtonpost.com/graphics/national/police-shoo...

So yes blacks are killed at a higher rate per population. But what about by actual violence? When looking at violence, blacks and whites commit about the same number of homicides despite population differences. Homicide is the most fair stat we have. If we use lesser crimes [like drug possession or other violence], we will see blacks overrepresented due to higher policing and a biased justice system. In fact, as minority areas of cities have a low solve rate, going by homicides may understate the racial difference in crime in favour of blacks.

It sort of looks like, if you want to get racial about it, whites are the ones killed too much by police. And if you look at the numbers for Hispanics, it is even worse. (But that might be an artifact of how race/ethnicity/Hispanic is reported.[1])

Yet that does not stop perception. There was an ad on TV a while back with a black mother having "The Talk"[2] with her teenage daughter about getting stopped by cops and not wanting her killed. Well, let's see: in 2017 one unarmed female black person was shot by police, and that was when a SWAT team raided her and her bf's place. Such ads that portray this as an issue are simple fear mongering. 2018, so far that number is 0. An ad about how to hide in case of lightning storms would be more realistic. Or simply more training about driving. Or avoiding pools. Or practically anything else in the world.

Try it out: Go ask around and see what your friends and others think the true rate is of unarmed people being killed. Ask them what difference in numbers they think exist for black vs white, and ask them about the flip side of civilian violence. My guess is you'll first get some incredibly high statement about how this is just happening non-stop, then when you reveal the numbers you'll get some other excuse about how it is not about the numbers anyways but some other general racial problem.

1: I'm using https://ucr.fbi.gov/crime-in-the-u.s/2014/crime-in-the-u.s.-... for a quick view of homicide stats. The numbers could be off by 2x and it would not change the point much.

2: Found it: https://youtu.be/3s20ePvTaME?t=21 "This is not you about getting a ticket, this is about you coming home" to which the girl says "I'm going to be OK....right?" Obviously a dramatization but if you're somehow implying to your teenage girl that cops are going to pull you over and you'll not "come home", you're the problem.


The problem with police violence is that they fundamentally do not see the murders of unarmed people as a problem. On Netflix's Flint Town, there is an episode where the Flint officers watch the video of a woman in the car with her husband who was shot beside her. None of the officers in the room questioned the obviously emotional police officer, rather clearly there was something to hide because the woman was too calm.

In a situation like that, where one group feels the shooting of unarmed people is justified the absolute numbers are not the whole picture.


Applies to software too. Standards need to be strongly defined with no leeway. Parsing should be tight and leave no room for creativity. (Text protocols like HTTP I'm looking at you!) Anything that deviates should be rejected by reference implementations instead of trying to be "robust" by accepting junk.


"Standards need to be strongly defined with no leeway."

Actually, I think there should be leeway - but only in one direction.

Specifically, I am thinking of the suggestion: "be conservative in what you send and liberal in what you receive".


I think that this is what the parent was arguing about: Being liberal about what you receive often leads to every different implementation handing the undefined cases in their own particular way, which leads to incompatibilities or one of the implementation becoming the de-facto standard.


Liberal in what you receive should only apply for human user interfaces.

If you apply the rule on machine to machine interfaces it eventually leads to all applications having to be bug-for-bug compatible with the most popular implementation. (Internet explorer 6 usually being the prime example of this)


SEC can "fix" HFT instantly by allowing more decimals. There's no good reason to only have 0.01/0.001 increments. Making it so granular forces speed over accurate pricing. Make it 8 decimals and the speed advantage goes away.


No, it just moves the race from getting the first order at the +0.01/-0.01 band placed to getting the first order priced .00000001 better than the top placed before a liquidity-taking order comes in.

There is no really easy way to "get rid of HFT", and it's unclear whether we actually want to do that. Equity trading is very cheap & efficient w/ tiny spreads on everything remotely liquid. Pretty much the only people who get hurt by HFT are big institutional investors (hedge funds, etc) that used to be able to move big blocks of stock without affecting the price as much as they now do. If anything - the pricing is better now. If you own a truckload of oranges and you hear that someone is going around frantically buying up all the oranges at every store, do you not feel like you should consider raising the price of your oranges?


I'm unsure how it doesn't fix the speed advantage. Anyone can get in front by bidding a millionth cent more. You can keep doing that until the price starts mattering, right?

I'm not against HFT at all. But having such granular pricing doesn't do anyone favours. More decimals would reduce spreads as well as silencing HFT critics and maybe make trading a bit more accessible without as much high end systems. But the spread reduction is valuable alone.


Who has Tether defrauded? I agree Tether may have just issued without backing, but they don't promise being able to withdraw. So who is actually being harmed? And why is it unfixable? What if Coinbase promised to completely cover any usdt shortfall?


I think the criticism from the regulators has to do with the fact that you cannot create something representing a dollar without approval from regulators and without requiring anyone to do KYC - effectively circumventing all KYC/AML systems in place in the traditional financial system.


It's bizarre. I tossed the book away in disgust because it's crazy pseudoscience....and it still worked.


At this point, it's unlikely he or any other artist will release more music in the 1900s or even the 2000-2017 period.


If it'll let me play YouTube audio on my Sonos it'd be a great feature. Otherwise I'm not quite getting the value.

Workaround for this is to buy an HDMI splitter and send the audio to a sound system then use Chromecast, but Sonos is just so convenient.


Some things are just wrong. I've implemented SIP, a horrible standard. Lots of compatibility issues just from their insistence on a "human friendly" text format alone.

At any rate there's lots of things you just have to ignore, drop, reject, and otherwise muck about with in order to run a sane network. These standards are not written with software experience. They're written much in a vacuum and out of touch. This varies widely across RFCs so it might not apply to RFCs you like.

Example of a MUST for SIP and HTTP: line folding and comments in headers. Apart from being crap for performance (so much for being able to zero-copy a header value as just a pointer+len) there's zero legitimate use for these "features" of the syntax. Simply rejecting such messages is in your best interest as a network operator.


Fast checking is really useful in things like HTTP/SIP parsing. Rust should expose such a function as well seeing as their strings must be UTF-8 validated. Though it's even faster if you can just avoid utf8 strings and work only on a few known ASCII bytes, it means you might push garbage further down the line.


> Rust should expose such a function as well seeing as their strings must be UTF-8 validated.

That's more or less what std::str::from_utf8 is: it runs UTF8 validation on the input slice, and just casts it to an &str if it's valid: https://doc.rust-lang.org/src/core/str/mod.rs.html#332-335

from_utf8_unchecked nothing more than an unsafe (c-style) cast: https://doc.rust-lang.org/src/core/str/mod.rs.html#437 and so should be a no-op at runtime.


I meant Rust should have a SIMD optimised version that assumes mostly ASCII. I'm guessing there is a trade-off involved depending on the content of the string.


The linked implementation assumes mostly ASCII. It doesn't use SIMD. SIMD in Rust is a work in progress - the next version (1.27) will stabilize x86-64-specific SIMD intrinsics. There's an rfc (https://github.com/rust-lang/rfcs/pull/2366) for portable SIMD types.


simd support in Rust was only recently accepted and is being implemented so it currently relies on the vectorisation abilities on the compiler (it might get revisited soon-ish I guess).

As for the assumption of mostly-ascii, the validation function has a "striding" fast path for ascii which checks 2 words at a time (so 128 bits per iteration on 64b platforms) until it finds a non-ascii byte: https://doc.rust-lang.org/src/core/str/mod.rs.html#1541


std::str::from_bytes is that API.

Rust’s current implementation of full validation: https://github.com/rust-lang/rust/blob/2a3f5367a23a769a068c3...

I have a vague feeling there’s an even faster path for probably-ASCII out there, but I can’t immediately recall where and am going to bed. Doubtless someone else will answer before I get up.

The core team will be amenable to replacing this algorithm with something faster presuming it’s still correct.


Given the new simd features, it's probably time to revisit that now


There is probably a trade-off depending on the content of the string, right? So the API probably needs a general-purpose and a "this should be all ASCII" version?


I don't know if it really makes a lot of sense to have such a specialized version of a method in the standard library. Effectively from_str and from_str_mostlyascii would be functionally identical except for a small performance difference depending on the encoding of the string data which wouldn't matter in 99% of programs.

Having that as a 3rd party crate would make complete sense however.


If there's a canonical, obvious, and low maintenance way to do something that there's a common need for, then there's no reason it shouldn't be in std. If it needs to be hacked at and redesigned every few years, then yeah, leave it out.


That's not really the Rust way, for instance things like timekeeping and random number generation are delegated to external crates. Given how trivial it is to add dependencies thanks to cargo it's not really an issue in practice, even if I do think that they go a bit overboard at times (time really ought to be in std IMO, especially since there's already a rather useless std::time module).


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: