Readit NewsSomething one doesn't see in news headlines. Happy to see this comment.
I usually google where a particular setting is now since I don't use the exact same words and the settings search is very literal.
If the hypothesis is correct, it sets an incredibly high bar for starting a new programming language today. Not only does one need to develop compiler, runtime, libraries, and IDE support (which is a tall order by itself), but one must also provide enough data for LLMs to be trained on, or even provide a custom fine-tuned snapshot of one of the open models for the new language.
It is absolutely clear that there is H1B abuse and I'm looking directly at the bodyshops like Infosys and Tata. Here's how it goes:
1. Apply for as many visas as possible. This is done primarily for Indian nationals for reasons which will become clear;
2. As the employer you really don't care which ones are approved or how many because what you're going to do is farm out those employees, whether there's 1000 of them or 10,000 of them;
3. Because there is an annual quota and applications have expanded so much, the chance of success is about 1 in 3 currently in the annual lottery. And a Principal Engineer in AI at Google or Meta has the same chance of success as a junior developer at Tata. There may be other options for the first person such as EB1 or NIW or L1 but that's really beyond the scope;
4. As part of this process you have to "prove" you cannot fill a position with a US resident or citizen. There is a whole process for this to minimize the number of applicants and to reject any who happen to find your newspaper ad and apply. This also applies to the Green card Labor Certification too, to a higher degree. Part of this is to make sure the employee is getting paid enough for their job and area. This is called a prevailing wage determination ("PWD"). This process doens't really work, which I'll get into later;
5. So you, as an Indian national won the H1B lottery and your visa is approved. You come to the US and hope Tata finds you a job where they farm you out at $200-500 per hours while paying you $50 or thereabouts;
6. Now the employer starts doing things they're technically not allowed to do, like if they can't find you a job they stop paying you. You may fall below the PWD because of this;
7. A H1B is valid for 3 years, extendable by another 3 for a total of 6 years, after which you're technically meant to leave the country. But what happens is the employer will file for an employment-based green card for you. If they do this in the first 5 years you can remain while that case is pending;
8. There are annual quotas for how many green cards are issued for each employment category. Additionally no more than 7% each year can be issued to any single country, based entirely on your country of birth, not your actual citizenship. And if you're married and have children under age, they will also count against these quotas.
9. So because H1B applicants are disproportionately Indian natioanals, there is a MASSIVE bottleneck for employment based green cards. As such, there is a HUGE backlog. Currently, USCIS is processing green cards for EB3 applicants from India who have a priority date of August 2013. That means their PERM was approved on or before August 2013;
10. So this is how these bodyshops can abuse Indian nationals. Those nationals really can't leave their job. Not easily anywway. There are laws that if they change jobs they get to keep their priority date but the new employer has to file an entirely new green card applications, including doing the entire PERM process again. Oh and if the employer moves area or their jobs changes significantly, it may invalidate their PERM too.
So these bodyshops can keep essentially indentured servants for 15-20+ years and at any time can fire that person. The power imbalance is so massive. This suppresses wages for everyone.
And these people are in the same cateogry as highly paid engineers in tech companies who have substantially better conditions.
Also, at any point along the way the USCIS can simply decide to take a whole bunch of extra time for literally no reason. They have a policy to randomly audit ~30% of applications. Why? They will never tell you. Their arguemnt is to avoid people "gaming" the system by working out the audit criteria so there's a bunch of random "noise" in there. Literally.
Well that doesn't sound bad right? Extra scrutiny? Except now you've added 1-2 years to the processing for literally no reason. You may get a request for evidence ("RFE") out of it too, which might add another year too. This can go multiple rounds too. I know people who spent 5 years going through audits and RFEs. One in particular is an engineering director at Google now.
While tech companies like Google, Meta, etc are better than the bodyshops they absolutely use this system to suppress wages, again because of the power imbalance.
It doesn't have to be this way. Take Switzerland as an example. I'm rusty on the details but IIRC if you're on a B permit (work permit like an H1B, tied to an employer) for 5 or 10 years (EU citizen is 5, otherwise 10, generally), you automatically get a C permit, which is basically a green card.
All this to say is that I have mixed feelings on this $100k fee. It will absolutely cut demand for H1Bs. It will decimate new graduate H1Bs but there's an argument that US residents and citizens should get priority for entry-level positions anyway, right?
If all this comes with much less paperwork, like skipping the whole LC process, then maybe large employers will pay it because they absolutely do spend a fortune on immigration lawyers.
If anything, the entire immigration system needs an overhaul but there's no political will for that. There are no votes in it. Quite the opposite: any serious attempt can be dismissed as "they're stealing our jobs".
I also think layoffs at large companies should absolutely preclude you from sponsoring H1Bs entirely for 2+ years.
There are two variations of the B permit one can get. An unrestricted B permit isn't tied to a specific employer and provides a path toward permanent residence (C permit) within five years for EU citizens or ten years for non-EU citizens. Based on my experience, EU citizens almost always get an unrestricted permit and are treated relatively well by the immigration process: at their first application, they receive a five-year B permit, and at the first renewal five years later, they automatically get a C permit. As a EU citizen you just need to find a job, and your right to work is essentially unrestricted.
The non-EU path is quite different. A non-EU citizen only gets an unrestricted B permit if they prove they have special skills that are not currently available on the local job market. There is a yearly quota for such permits. One can also be unlucky and get an L permit, which is for temporary work only. Moreover, restricted B requires yearly renewal with a demonstration of ongoing employment at each renewal.
If you get a restricted B permit (or L), you don't have any direct path to a C permit, no matter how many years you've lived in Switzerland. You can complete your bachelor's, master's, and PhD degrees and continue working for a university as a contractor afterward, and still not be eligible for the path toward a C permit after over a decade of living in the country. To get a C permit, the last two years prior to the application must have been on an unrestricted B permit, working a full-time, unlimited-term job contract. The change to an unrestricted B permit requires you to have become a "special talent" during those prior years; otherwise, it won't be granted.
And suddenly you can start playing with distributed software, even though it's running on a single machine. For resiliency tests you can unplug one machine at a time with a single click. It will annihilate a Pi cluster in Perf/W as well, and you don't have to assemble a complex web of components to make it work. Just a single CPU, motherboard, m.2 SSD, and two sticks of RAM.
Naturally, using a high core count machine without virtualization will get you best overall Perf/W in most benchmarks. What's also important but often not highlighted in benchmarks in Idle W if you'd like to keep your cluster running, and only use it occasionally.
Yeah, jank doesn't much with JVM APIs or the JVM at all. We have our own implementation of the compiler and runtime. It has similarities to Clojure's design, only because the object model somewhat demands that.
> Don't implement your own GC, just use mmtk [1].
Yep, already the plan. Currently using Boehm, but MMTK is the next upgrade.
> Don't underestimate complexity and importance of multi-threading and concurrency.
Clojure aids this in having STM, immutable data structures, etc. However, there are some key synchronization points and I do need to audit all of them. jank doesn't have multi-threading support yet, but we will _not_ go the way of Python. jank is Clojure and Clojurists expect sane multi-threading.
> Don't spend too much time benchmarking and optimizing single threaded performance against JVM as performance baseline.
This year, not much optimization has been done at all. I did some necessary benchmarking early on, to aid in some design decisions, but I follow this mantra:
1. Make it work
2. Make it correct
3. Make it fast
I'm currently on step 2 for most of jank. Thanks for sharing the advice!
- Don't try to provide backwards compatible subset of JVM APIs. While this might seem tempting to support very important library X with just a bit of work, I'd rather see new APIs that are only possible with your language / runtime. Otherwise you might end up stuck in never-ending stream of requests to add one more JVM feature to get yet another library from the original JVM language running. Focus on providing your own unique APIs or bindings to native projects that might not be easy to do elsewhere.
- Don't implement your own GC, just use mmtk [1]. It takes a really long time to implement something competitive, and mmtk already has an extensible and pluggable GC design that gets some of the best performance available today [2] without much effort on your end.
- Don't underestimate complexity and importance of multi-threading and concurrency. Try to think of supporting some form of it early or you might get stuck single threaded world forever (see CPython). Maybe you don't do shared memory multi threading and then it could be quite easy to implement (as in erlang). No shared memory also means no shared heap, which makes GCs's life much easier.
- Don't spend too much time benchmarking and optimizing single threaded performance against JVM as performance baseline. If you don't have a compelling use case (usually due to unique libraries), the performance might not matter enough for users to migrate to your language. When you do optimize, I'd rather see fast startup, interactive environment (think V8), over slow startup but eventually efficient after super long warmup (like jvm).
I see that jank is already doing at least some of the things right based on the docs, so this message might be more of a dump of mistakes I've done previously in this space.
My current research is about how to make handles just as convenient to use as pointers are, via a form of context: like a souped-up version of context in Odin or Jai if one is familiar with those, or like a souped-up version of coeffects if one has a more academic background.