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

One of the issues is conflation of IT jobs and High Tech jobs. Those making laws don't understand the difference -- they are all "computer jobs" to them. IT does not require immigrant labor. Companies such as Infosys and Tata don't need to be operating in the US. There are plenty of US workers available to do the job.

But High Tech is different. High Tech needs the best in the world, not the best in the US. The US leads the world in tech not because the best ideas were all American but because the best people in the world immigrated to the US. Stopping this will be ruinous to American prosperity.

The seminal research paper that kicked off the AI revolution (titled "Attention is all you need") was written by 2 Indians, 1 German, 1 British Canadian, 1 Pole, 1 Ukrainian, and 2 US born people. These people came to America, worked together and changed the world as we know it. Why would we want to stop it? Has this immigration undercut Americans? Far from it. These immigrants are the lifeblood of the tech industry, and their innovations create jobs.


I think everyone (or virtually everyone) is OK with actual world-leading researchers coming to the US. But what we don't want is the labor market flooded with foreign "talent". The system is designed to try to get the researchers and noteworthy people, but corrupt people have found ways around all of it. There are paper mills, degree mills, cheating rings, etc. Plus firms that exist solely to funnel foreigners into the US for a fee.

There is always an economic argument to be made for importing the cheapest or allegedly "best" labor, but it's mostly about saving money even if it means destroying domestic workers. It sounds better when we're talking about a scientist instead of a construction worker or meat packer, but it's kind of the same problem. There are many cases of American workers being forced to train H1-B replacements, or being blatantly discriminated against for being, shall we say, obviously American.

If foreign researchers are able to prove themselves abroad and contribute as you say, I assume they can continue doing that in most cases without coming to the US to take jobs. If immigrants are such a great resource, why are poor countries not trying harder to keep those people from leaving? Why doesn't China import a bunch of Indians for IT work, or vice versa?


Agree with your first two paragraphs, disagree with the last.

> If foreign researchers are able to prove themselves abroad and contribute as you say, I assume they can continue doing that in most cases without coming to the US to take jobs.

They can't prove themselves abroad. Consider the example of "Attention is all you need" paper. That paper came into existence thanks to talented people from around the world coming together in one place and then collaborating. It would not have happened if the contributors stayed in their own countries.

> If immigrants are such a great resource, why are poor countries not trying harder to keep those people from leaving?

They are. See here: https://www.reuters.com/world/asia-pacific/china-restricts-o...

> Why doesn't China import a bunch of Indians for IT work, or vice versa?

They are trying. See here: https://www.nytimes.com/2025/10/14/world/asia/china-stem-vis...


>They can't prove themselves abroad. Consider the example of "Attention is all you need" paper. That paper came into existence thanks to talented people from around the world coming together in one place and then collaborating. It would not have happened if the contributors stayed in their own countries.

I think this is a stretch, especially now that we have the internet. I also wouldn't be opposed to non-immigrant research visas, perhaps a specialized type of H1-B visa (since most of these people are not independently wealthy). But what I don't want is any random foreigner who has their name on some academic papers to be considered top talent. There are paper mills that crank these people out (putting their names on papers without any involvement), and besides that most research is just not that good. Why would we want a bunch of mediocre foreign researchers to come and take jobs away from mediocre American researchers? As we know, getting jobs in academia is very difficult as-is.

You got me on China trying to stop talent from leaving. It's an authoritarian country though. You can't even travel around freely inside the country lol! I threw China in there because a lot of H1-Bs and students are actually Chinese, but China is not where most of them come from.

You also got me on China allegedly trying to get talent to move to China. Their people seem to have had a predictable reaction. That's really something, considering that they can get in trouble for criticizing their government. I guess they thought it was worth the risk, because doing nothing would screw them even harder.


> I think this is a stretch, especially now that we have the internet.

We disagree on your first paragraph, agree on the rest.


I'm surprised you can't find something to agree with in the first paragraph. I feel compelled to restate and clarify points I glossed over, to see which one you disagree with:

1. Foreign researchers can communicate with colleagues fairly well over the internet (in real time, even). Physical presence is not required to do academic research, at least in mathematics or CS.

2. Degree mills, fake credentials, paper mills, etc. exist to get names on stuff for a fee. This is used to game the immigration system.

3. Many US degree programs are used as a vector for immigration more than education, and people who immigrate this way usually try to meet the minimum requirements to stay in the US and do little beyond that.

4. Even when it comes to research, most research just isn't that good and doesn't contribute that much to society.

5. Getting jobs in academia is difficult.

6. Immigration lowers wages due to the basic laws of economics.

7. Given the fact that we have mediocre researchers in abundance, such that they can't find work in academia, there is negligible societal benefit to importing mediocre foreign researchers en masse. Additionally, this is devastating to the local labor market.

8. All other things equal (to the extent it is reasonable to determine), a country should try to ensure that native citizens get priority in hiring, rather than importing replacements.

If you disagree with #8, perhaps you should consider who is going to be willing to spill their blood and give up their treasure to defend a country that undermines them at every turn.


where do satya and sunder fall in that spectrum. sundar started out as regular project manager and satya as lowly engineer. neither of them were world leading researchers.

Tesla should take inspiration from this and at least bring back the physical gear shifter and the turn signal stalks.


Agreed about the signal stalk. Correct me if I'm wrong, but the last I've seen the signal stalk is back in Teslas, at least in Model Y, but I believe in newer Model 3s as well.

But "gear shifter"? It doesn't really require a stalk.

When you start, you select either D or R. Not a big deal.

And when you stop, I think most (all?) EVs even automatically go to P and apply parking brakes when you stop.

I think that already covers 99% of driving for 99% of people.


Tesla is the one that started this and cost who knows how many lives. They are the ones who thought it would be great to re-invent the wheel and then when the moron execs at the other companies saw the hype they had to copy it.


The execs probably got promotions for it considering the money saved. The real morons are the customers buying these cars. Brand loyalists don't buy based on logical reasoning.


What would the gear shifter even do though?


Put it in drive, neutral, park, or reverse. Same as an automatic.


Same as what it did in the original Tesla cars. They only removed the stalks recently.


Are Experian, Transunion and Equifax included in the one-click deletion?


They don't let you delete credit history data unless it's incorrect. But you can freeze it.


> that tends to get in the way of complex error handling.

Agree. In Java, Streams allow you to process collections in a functional style. This feature enables concise, expressive data manipulation with operations like map, filter, and reduce.

Some people point out that Java's checked exceptions spoil the simplicity and elegance of Streams by forcing you to handle exceptions.

But that's not a reason to not have checked exceptions, it is a reason to not do functional style composition when methods can throw exceptions. Streams was invented for collections, which tend not to throw exceptions. If proper error handling is important don't do Streams.


The Java streams are cool and I like them, but they're not a replacement for a functional type system or a functional language.

`map` is a lot more than a fancy for-loop for lists and arrays; it's about abstracting away the entire idea of context. Java streams aren't a substitute for what you have in Haskell.


Yes, they are really a poor emulation of scala which makes it a bit more usable.


How is this different from using a small aperture size?

When you reduce aperture size the depth of field increases. So for example when you use f/16 pretty much everything from a few feet to infinity is in focus.


Very small apertures reduce image quality due to diffraction, which this avoids

Last page in the paper has a comparison between their approach and f/32 https://imaging.cs.cmu.edu/svaf/static/pdfs/Spatially_Varyin...


Is that actually true? I do astrophotography through an f/10 telescope and its focus is very sensitive. I use a focuser that moves the camera 0.04 microns per step.

Not doubting you, just asking to understand. Astrophotography doesn't always behave the same as terrestrial photography


in addition to aperture, percieved depth of field greatly depends on:

- focal length (wider is deeper)

- crop factor (higher is deeper)

- subject distance (farther is deeper)

compared to your telescope, any terrestrial photography is likely at the opposite extremes, and at a disadvantage everywhere but subject distance.

but, focus is most mechanically sensitive near infinity. adjustment creates an asymptotically larger change in the focal plane as infinity is approached.

in a point-and-shoot camera with a wide lens at f16, "infinity" basically means across the street.



You don't need a large framework to build a maintainable, efficient web app. Here's an example: https://github.com/wisercoder/eureka/tree/master/webapp

It uses two 500-line libraries:

This 500-line lib lets you use TSX syntax without React: https://github.com/wisercoder/uibuilder

This 500-line lib implements MVC routing: https://github.com/wisercoder/mvc-router


This is a better article if you are interested in the history of Pivot Tables: https://qz.com/1903322/why-pivot-tables-are-the-spreadsheets...


Discussed here:

The pivot table, the spreadsheet's most powerful tool (2020) - https://news.ycombinator.com/item?id=37820877 - Oct 2023 (192 comments)



I watched the video on the home page and thought it is weird that they spend an inordinate amount of time on frame rate. Who picks an editor based on frame rate?

If you want to talk about perf in the context of a text editor show me how big of a file you can load--especially if the file has no line breaks. Emacs has trouble here. If you load a minified js file it slows to a crawl especially if syntax highlighting is on. Also show me how fast the start up time is. This is another area where Emacs does not do well.

So Zed is available on Windows--but only if you have a x64 processor. Lots of people run Windows on Arm64 and I don't see any mention of Arm64. This is where the puck is heading.

Also noticed Emacs key binding is in beta still.


It's not just frame rate, but also input delay. If you're using Visual Studio Code, you might be used to waiting 100 ms for a character you typed to appear. My personal workflow is based on Kitty and Neovim, which I've configured so that it can launch within 20 ms. Working without any input delay allows me to explore and edit projects at typing speed. As such, even tiny delays really bother me and make me lose my flow. I would believe Zed's focus on performance is motivated similarly.

Also, I do not believe Windows on Arm64 is a very large demographic? Especially for developers, unless they're specifically into that platform.


> you might be used to waiting 100 ms for a character you typed to appear.

The latest benchmark I could find is 2022 and it's nowhere as bad as you claim

https://github.com/microsoft/vscode/issues/161622#issuecomme...



Did you run this on a clean VSCode install?

I know as a matter of fact that bad extensions slow down VSCode significantly.


Thanks. Could you please do Zed also? I tried, but it was struggling to type.


The only IDE I have used where frame rate is noticeable was Visual Studio (not Code).

Once you are beyond a bare minimum, every other speed metric is more important. Zed does really well on many of those, but some depend on the LSP, so they become the bottleneck quickly.



Most of that is macOS and ChromeOS, not Windows.


Yeah. The Steam survey isn't a perfect sample since it's skewed towards gamers, but that currently shows just 0.08% of Windows users are on ARM, while 81.5% of Mac users are on ARM.


That may be true if you're looking at all windows computers in existence. If you look at new laptops being sold you see different numbers. As of 2025, Arm processors hold about 13% to 20% of the market share for new Windows laptops. This is important because these are the people who are more likely to download and install your software.


You literally can’t tell the difference in a 20ms delay. That is an order of magnitude lower than the neural feedback loop latency. You may think that you can, but studies don’t back this up.


Let's see.

https://web-backend.simula.no/sites/default/files/publicatio...

> At the most sensitive, our findings reveal that some perceive delays below 40 ms. However, the median threshold suggests that motorvisual delays are more likely than not to go undetected below 51-90 ms.

By this study's numbers, 20ms is somewhat below the lower limit of ~40ms, but not too far below. 100ms would be easily perceivable - though, based on the other replies, it seems that VS Code does not actually have that much latency.

Don't confuse this with human reaction time, which is indeed an order of magnitude higher, at over 200ms. For one thing, reaction time is based on unpredictable events, whereas the appearance of keystrokes is highly predictable. It's based on the user's own keypresses, which a touch typer will usually have subconsciously planned (via muscle memory) several characters in advance. So the user will also be subconsciously predicting when the text will appear, and can notice if the timing is off. Also, even when it comes to unpredictable events, humans can discern, after the fact, the time difference between two previous sensory inputs (e.g. between feeling a keyboard key press down and seeing the character on screen), for much shorter time differences than the reaction time.

Of course, just because these levels of latency are perceptible doesn't mean they're a material obstacle to getting work done. As a relatively latency-sensitive person, I'm not sure whether they're a material obstacle. I just think they're annoying. Higher levels of latency (in the hundreds of ms) can definitely get in the way though, especially when the latency is variable (like SSH over cellular connections).


He’s not arguing that he can perceive the latency. He’s arguing that the latency affects his work/productivity. That claim seems unreasonable.


You're the one who said "you literally can't tell the difference". I agree to a point. It seems plausible that they were experiencing some other effect such as hitching or slowdown, rather than just a constant 100ms delay (which again isn't supposed to happen).

On the other hand, I just thought of one way that even a small fixed amount of latency can be a material obstacle. Personally, I type fast but make lots of typos, and I don't use autocorrect. So I need to react to incorrect text appearing on screen, backspace, and retype. The slower I react, the more text I have to delete (which means not just more keypresses but also more mental overhead figuring out what I need to retype). For this purpose, I am bound by the human reaction time, but editor latency is added on top of that. The sooner the text appears, the sooner my 'reaction timer' can start, all the way down to 0 latency. [Edit: And 100ms of latency can make a meaningful difference here. I just did a quick typing speed test and measured 148 WPM which is around 12 characters per second, so 100ms is one extra character, or a bit more.]

Also, latency might affect productivity just by being annoying and distracting. YMMV on whether this is a legitimate complaint or whether you should just get used to it. But personally I'm glad I don't have to get used to it, and can instead just use editors with low latency.


"Order of magnitude", so you're saying the neural feedback loop latency is >100ms? That seems obviously wrong.

Also you can absolutely feel the visual difference between 60Hz (~16ms) and 120Hz (~8ms), and for audio it's even more nuanced.

Just because studies don't back this up yet doesn't make it false. I imagine this is really hard to measure accurately, and focusing only on neuron activity seems misguided too. Our bodies are more than just brains.


> "Order of magnitude", so you're saying the neural feedback loop latency is >100ms? That seems obviously wrong.

Human neural feedback loop latency is a range that varies widely depending on the type of loop involved. Reflex loops are fastest, operating in tens of milliseconds, while complex loops involving conscious thought can take hundreds of milliseconds.

Short-latency reflex: 20-30ms. Signal travels through spinal cord, bypassing the brain. E.g. knee-jerk reflex.

Long-latency reflex: 50-100ms. Signal travels to the brainstem and cortex for processing before returning. E.g. Adjusting grip strength when an object begins to slip from your hand.

Simple sensorimotor reaction: 230 - 330ms. Simple stimulus-response pathway involving conscious processing, but minimal decision-making. E.g. pressing a button as soon as light turns on.

Visuomotor control: ~150ms, adaptable with training. Complex, conscious loops involving vision, processing in the cortex, and motor commands. E.g. steering a bike to stay on a path in a video game.

Complex cognitive loops: Brain's processing speed for conscious thought is estimated at 10 bits per second, much slower than the speed of sensory data. High-level thought, decision-making, internal mental feedback. E.g. complex tasks like analyzing a chess board or making a strategic decision.


A few years ago I did some testing with a quick Arduino-based setup I cobbled together and got some interesting results.

The first test was the simple one-light-one-button test. I found that I had reaction time somewhere in the 220-270ms range. Pretty much what you'd expect.

The second test was a sound reaction test: it makes a noise, and I press the button. I don't remember the exact times, but my reaction times for audio were comfortably under 200ms. I was surprised at how much faster I was responding to sound compared to sight.

The last test was two lights, and two buttons. When the left light came on I press the left button; right light, right button. My reaction times were awful and I was super inaccurate, frequently pressing the wrong button. Again, I don't remember the times (I think near 400ms), but I was shocked at how much just adding a simple decision slowed me down.


very cool data. thanks for sharing!


Do you not perceive more than 50 Hz?


Do you react and respond per-frame of a video?


Most people can with some Aimlabs training...


I don't have to think a full thought for every keystroke.


Then you don’t have to have an input response latency so small as to be perceived instantaneously.


I dunno what to tell you, Zed feels so much snappier than VSC to me.


High frame rates (low frame times, really) are essential to responsiveness which, for those who appreciate it, is going to make much more of a difference day to day than the odd hiccup opening a large file (not that zed does have that issue, I wouldn't know as I haven't tried opening something huge).


This is one of those things that make me question whether I experience the world fundamentally differently than many of you.

I have never, ever felt “latency” in editor UI. Any editor UI. It’s editing text for Pete’s sake. I can only type so fast, or read so fast.


You probably do. Many people just never notice that. It's not about typing or reading fast either, it's just about how it feels. Typing into something with shitty latency feels like dragging my fingernails across a chalkboard.

It's the same with high dpi monitors. Some people (me included) are driven absolutely insane by the font rendering on low density monitors, and other people don't even notice a difference.

Honestly, consider yourself blessed. One less thing in the world to annoy you.


Yes, I can perceive that latency, if I am actively looking for it. No, it has absolutely no effect whatsoever on my ability to work. The latency is far, far below what could possibly affect neural feedback loops, even on the slowest editors. And it doesn’t bother me in the slightest.

Low-dpi font rendering also isn’t an issue for me, unless it is so bad as to be illegible (which no modern system is).

We really do perceive things differently.


Have you ever used a display running over 60hz refresh rate?


Has it ever impacted your ability to read, or type?


That's an interesting take. For whatever reason, frame rate is not one of my complaints about existing editors such as Emacs, VS Code, etc.


Latency often is for VS Code - that's frame rate. Your editor taking 1s to respond to inputs is not normal.


It's expected for editors to have non-perceivable latency. It's just text, how hard can it be.


> Who picks an editor based on frame rate?

Me! Frame rate and input latency are very important for a tool I use for hours every day. Obviously that's not the only feature I look for in an editor but if an editor _doesn't_ have it, I skip it. I also try to work on devices with 120Hz displays and above these days.


I think the claim is more that an editor is supposed to have an arbitrary good frame rate.


Yeah, Kate will choke on a large single line file. Its one of the very few issues I bump into from time to time.


This always makes me laugh. The editor was barely announced two years ago. They've built it from the ground up with native support now for three different operating systems. They're experimenting with some cool new features, and even though I don't care about it I've heard their AI integration is pretty damn good.

But waaaaah they don't support a processor that accounts for probably less then 10% of Windows Machines


Ubiquity is pretty important when you're going to invest in learning a new editor. This is one of the advantages of vim for example. It is available everywhere... linux, windows, terminal, gui, etc.


You mean... like a GUI editor that runs on Windows, Mac, and Linux?


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

Search: