No, H1-B is a "dual intent" visa, i.e. you are allowed to transition from one to a green card. Something like a TN visa is actually intended for temporary skilled workers.
I also went to try it out and gave up in frustration. Getting "embeddings" in particular seems critical to having it work well but also extraordinarily hard to try out, I'm not actually sure if you are required to pay sourcegraph money for that feature before you can use it or not.
The 300 hours I spent completing Space Exploration were a lot of fun, but it definitely feels very stretched out and grindy. One of the hardest things to do in game design is to make cuts & simplify, but the end result is usually much better.
Like any technology, there are both positive and negative aspects of it. The positive take would probably be that this technology is already widely used by iOS and Android apps. People use Apple's AppAttest to e.g. ensure that high scores submitted for a game are from a legitimate copy of the game and not just someone calling the SubmitHighScore API.
But it's absolutely fair to argue that the web operates on a different set of expectations than the Play Store/App Store, and I think the concerns that this will create a second-class citizen status for browsers are totally valid. There's a huge difference in character between "in order to prevent piracy and ensure ad revenue we are only releasing our app on the Play Store" and "we are only releasing our web app for Chrome".
I've found that IntelliJ is much better at having code completion always work, even in the presence of macros. Rust Analyzer has a tendency to randomly break down when you're writing code, even with something as simple as the vec![] macro.
Last time I tried this, the plugin was incapable of actually showing compile errors in the project view and they said their false positive error rate was too high to enable it (https://github.com/intellij-rust/intellij-rust/pull/8373). That was a dealbreaker for me compared to VSCode. It doesn't look like that's changed?
OOP is a tool like any other, and it has real costs and benefits. The original idea of being able to easily add new common APIs via inheritance is very powerful and widely applicable. In fact both Haskell and Rust wound up with a similar mechanism to inheritance (the 'deriving' annotation) to reduce the pain of problems like "I don't want to have to write code to define equality for every struct" which are hard for the purely-functional approach to solve.
I've never used Go, but do you really not need to create anything similar to a Cargo.toml file specifying dependencies to create a package? That doesn't seem like it could be true within Google since they would use blaze to compile their Go code, which mandates a new BUILD file for each package...
The other stuff here is mostly just a matter of convention. Every large Rust codebase I'm familiar with absolutely does avoid creating huge crates, so I think the author is just mistaken about what constitutes standard Rust practice.
What is the probability of an asteroid hitting the earth and wiping out humanity? I've seen numbers like 0.000001%, yet NASA is spending real money on mitigating this risk. Is the risk of fast takeoff AI dramatically lower than that?
This seems to mostly be an argument that implicit conversions are harmful. I think that's generally agreed to be true, most newer programming languages require all type conversions to be explicit.
This just feels like taking two unrelated things and bunching them together under a label in order to be provocative and imply that software 2.0 will "replace" existing code.
If you surveyed e.g. all of the code Google has in their piper repository, you would find significantly less than 1% of it could be replaced by even an extremely good neural network.
Tried it out. I like this idea, but requiring two hands is a deal-breaker for me. I need to be able to switch apps while my hands are over the keyboard without needing mouse/trackpad interaction, ideally staying as close to home row as possible.
I believe this is the same string representation Rust uses? Although in Rust the empty string is guaranteed to not allocate memory, not sure if that's true here.
There are phenomena in the universe that, for example, general relativity does not predict correctly. Is your conclusion that we should discard any useful theory which ever fails to match an observation?
Would someone who relied on Newtonian dynamics 100 years ago likewise be incorrect to do so because it failed to explain many aspects of planetary motion?
I can't immediately think of any really big differences, and the ones that do exist are more down to cultural differences (e.g. Google has a much more involved/rigorous code review process, which is reflected in their tools). Mercurial is definitely better than Perforce/Piper, but IIRC Google now actually has a very similar mercurial frontend wrapper that a lot of employees use.
Every non-trivial (>10k lines) Cocoa/iOS/Android application I've ever seen or worked on has re-implemented at least some parts of React's data flow model. It's surprising to me that the author glosses over handling lists, which is a huge challenge with this approach, and one that forces you to do some React-like stuff (UITableView cell recycling identifiers!) even if you don't want to.
However, there are definitely some problem domains that don't map very well to the React model. Real time games, for example, have very different requirements.
So you'd stop running tests for all of the calling code? It sounds like you have a higher level of confidence than I do that non-API changes can never break any downstream repositories in subtle ways.
How does not having a monorepo solve this problem? They would still need to compile and run the same code in order to run these tests between 1000 small repositories vs 1 large one, presumably they see a lot of value in end-to-end tests.
Is the suggestion just "an easier way to avoid this problem is to not have so many tests?"
I'm confused how data structures work in this language, and there's no documentation about it as far as I can tell. Is this going to be a Rust-style vectors+iterators system? It it going to use purely-functional concatenative structures? The first example you show invokes `map` and `sum` over an Array, but what is this code actually doing? Making a copy of the data in the array? Creating a mapping iterator?
Animation is usually the biggest pain point with frameworks like this -- and it usually feels like a complete afterthought for framework designers. Of course you always have the simple CSS-style stuff (here's a list of properties you can attach transitions to) but as soon as you get into anything more complicated it all falls apart.
At one point in the past, Unity had a legendary commitment to backwards compatibility, but that's gone now (maybe their internal promotion process rewards shipping new features over everything else?).
Old Unity would never have shipped a fiasco like URP. They'd have figured out a way to make incremental migration possible instead of having a global setting... I refuse to believe this would even be particularly difficult.
Inflation in the form of government spending on infrastructure or wealth transfers to poorer citizens is not 'clearly' bad, there's significant academic debate on the subject. Disincentivizing cash-hoarding drives economic growth, and has done so for the past 50 years.
Even for me as a programmer, waiting for a lengthy compile cycle in order to test something like a simple logical change is pretty painful. Game programming is overwhelmingly done in low-level languages like C++/Rust which have awful compilation performance and very limited hot-reloading support.
You have committed the logical fallacy of 'to quoque', responding to criticism with criticism. The scrutiny (or lack thereof) for other individuals is of course irrelevant to the question.
The overwhelming conclusion I've drawn from this pandemic is that it's ultimately about people's level of trust in their own ability to analyze data vs trust in authority figures. There have been so many examples of 'vaccines cause harm!' articles that fundamentally misunderstand basic statistical concepts like selection bias or simpson's paradox (see the covid-datascience.com blog for lots more of these).
Is your prior on 'I will not make a significant analytic error' higher than 'the FDA analyzed the available data correctly'?
So, there are basically no consumer products on this table that have a respectable accuracy, right? The ones with good R² values all seem to be $1000+ scientific tools.