9,976 karma · joined March 14, 2013
Principal Software Engineer @ NVIDIA
Opinions are mine and not that of my employer, etc.
Sandy has gone into it on various podcasts and mediums. It's pretty clear he doesn't consider Carmack responsible but rather someone he refuses to name (but is quite obviously Tim Willits) that caused pretty much all the problems.
My read is Carmack is saying he is sorry he lacked the awareness and experience to manage the people stuff.
He lost his dream team, I'm sure it's something he has thought about a lot.
I think the only real solution is to add increasingly strict guardrails that can be enforced with a combination of more AI agents and actual executable contracts. The other aspect is through using languages and tools that densify correctness. i.e languages like Rust that have very rich type system so both review and design can be focused on a small by volume slice which is the core types. The other main tools for densifying correctness are formal methods, (model checking, etc), fuzzing/property based testing and static analysis.
All of these tools are cheaper to use than they once were because of lot of the minutiae can be handled AI agents while core invariants can receive heavy human scrutiny.
IMO generative AI is here to stay in development so may as well get ahead of the game and start using these tools to try get the best out of it.
For higher level patterns again the APIs are the same so anything building on libibverbs or aforementioned ucx etc are pretty compatible from a high level ideas perspective. If you are new to RDMA in general definitely start with raw verbs instead of using abstractions like MPI if you really want to build a good intuition and then move to MPI once you understand what it is doing for you.
I would separate the knowledge into maybe 3 distinct buckets.
The baseline: device/host boundary, SIMT programming etc.
The intermediate: kernel architecture, CUDA graph vs persistent kernels, warp specialisation/divergence avoidance techniques etc.
The advanced: architecture specifics so tcgen05, TMA, SMEM/HBM, memory throughput vs compute biases in various arch impls., GEMM, FHMA, all the tricks that make modern fused kernels very fast. Also would bucket most GPU Direct RDMA/GPU NetIO/friends here too.
The baseline hasn't changed much and probably won't, the intermediate knowledge has also remained pretty reliably stable for ~10 years with only things like graphs changing stuff. Tile might become more relevant than it is today but for now CUDA, cuBLAS, friends are where it's worth investing knowledge.
You do want to use Rust with LLMs.
The reason you want it is simple, it's more constrained.
LLMs thrive on constraint and drown in freedom.
The further you can constraint the solution space the more likely you are to end up with a solution you like/is actually good.
Rust has several properties that make it really good for LLMs:
* Really robust type system that is also very expressive, if guided LLMs can implement most of the invariants in types which substantially increases the chances of success.
* Great compile time errors, the specificity and brevity (vs say C++ template expansion) means token efficient correction of syntax and/or borrow mistakes etc.
* Protection against subtle errors at compile time, namely data races and memory safety issues.
* Great corpus of well designed code and patterns, higher quality on average than some other ecosystems more favored by begineers/mass-market programming.
* Stdlib is strong, small-ish number of blessed crates.
* Context friendly, type signatures, errors, etc are all dense information.
* Also bias towards compile time checks means less runtime tests which means less toolcall time (and less tests needed overall) which in turn makes the process a ton faster.
I have been continually using Rust, Python and Kotlin since ~Jan this year and keeping track of my thoughts and I increasingly bias towards Rust now where I would have previously chosen Python or Kotlin instead just because I am lazy and I prefer the tool that the computer writes better so I have to write less lol.
1200 years is a serious timescale, I think humans generally struggle reasoning about long durations or very vast distances. Which leads to them instead postulating how all these other more present, more recent and nearer things can be to blame when what you really need to do is zoom out (in space and/or time).
It's always been poo, the YAML is bad, the reliability is bad and the cost is bad.
So there is really no redeeming features because even if you tout forge integration it's UI is, you guessed it, also bad.
Putting aside the anti-pattern of using vendor YAML for literally anything (please don't do that) you are distinctly better off with literally any other CI/orchestration service. Buildkite is good, dynamic pipeline = good, there are other good options. If you are a serious person you will find good things to use.
Getting back to vendor YAML, please just use a real build system instead. Define all the actual logic there with entry points/targets the YAML hits. Also generally make sure that you don't need the actual CI system to be up to do releases, deployments etc. A sufficiently elevated local user should be able to run the appropriate target with the appropriate credentials to get the job done in absence of said CI system.
Not to mention being able to quickly deliver counter-attacks to like for like infrastructure when theirs has been attacked. i.e the Ras Laffan counter punch after South Pars was attacked and the UAE aluminium plants after their steel mills were hit etc.
They have also already essentially taken AWS Bahrain permanently offline at this stage.
So they are certainly capable of it but simply hitting the target removes the leverage of using it in a negotiation. If it's already gone you can't say "we won't hit X if you agree to terms Y before time Z".
Now that a war is started it has to be finished or the GCC is left far worse off with Iran in a much stronger strategic position in the region despite a decimated military.
My journey up from Senior/Staff was mostly on the back of proposing and then leading cross-functional projects.
Which means I was doing Principal work before being granted the title. To be honest it was (and remains) a huge amount of work and I wouldn't continue doing it if the recognition and compensation hadn't been forthcoming in the following perf reviews.
If you are doing this stuff and aren't moving up where you are then you should be going somewhere else as that is probably a very exploitive work relationship.
H1Bs are not getting approved for these for years now.
Infosys and TechM exploited the crap out of it to do shit like this which caused the rules to be tightened massively.
These days you are only getting H1B for folks atleast earning 200k+ base.
Unfortunately resetting the bar has massive collateral damage but it will sort itself out pretty quickly.
All the good ones will be re-employed within short order. The ones that the layoffs were trying to flush out with said layoffs will transition out of FAANG into lower-tier employers.
As your main point.
More educated or not doesn't actually matter, whether they meet the bar or not is all that matters no?
My over-arching point is if there were more Americans to be hired that meet the bar they will usually be hired before immigrants because they are less paperwork and money (immigration lawyers fees).
Also I think comparing to immigrant education isn't necessarily a great idea, immigrants need more on-paper education to simply clear the immigration requirements because most governments around the world place a higher emphasis on that than work experience or their salary. US in particular values years of education at a roughly 2:5 ratio vs work experience with 10 years of work experience necessary to qualify vs a 4 year degree.
If you are somehow implying immigrants are fundamentally less intelligent then yeah I don't know what to tell you but that is probably not correct.
None of it? The way I see it is every top tier programmer in America is already employed.
I think the inevitable outcome would just be the big multi-nationals (FAANG in particular) would just hire more in their international offices and spread out their engineering org more instead of remaining so American heavy and using immigration to centralise staffing.
There probably isn't a world where these huge companies decide to simply not take advantage of the global talent pool, if they don't exploit it someone else will and they can't have that.
There are only so many American engineers that meet said bar, they are all either employed or choosing not to be employed.
The ones that don't meet the bar are either employed by smaller employers with lower bars that don't use H1B anyway or yes, maybe unemployed or transitioning to a new industry because they couldn't hack it.
The mythical group I am saying doesn't exist is engineers that are somehow perfectly capable of meeting FAANG bar but are somehow being displaced by H1B. That group doesn't exist.
The Americans you work with (along with your other co-workers) meet the bar.
If there were more Americans that met the bar they would employ them before taking on all the extra work and cost of immigration.
I'm not talking about Americans you work with. I'm talking about the mythical ones you don't work with that are somehow disadvantaged by H1B and thus unemployed/underemployed. You don't work with these people because they don't exist.
If you aren't good enough then don't be surprised the companies prefer an immigrant. You don't get an automatic American free pass for having less skills, experience, interviewing poorly, etc.
i.e skill issue.
Ending immigration for tech would simply mean far more global workers/offshoring in order to access the top tier talent via different means as that is the real reason all along.
Wage suppression was the old (and now largely incorrect) story. The visa is still exploitive, it should be amended to be a 10 year visa that is independent of employment so immigrants aren't screwed by layoffs.
Yeah no.
In Singapore you have a single party which has used it's constitution, laws, courts and media control to enforce a defacto one-party state for 60 years. Singapore citizens can (and do) vote but those votes have absolutely zero chance of changing anything.
Is it technically democracy? Well they vote so yes? Is there any chance at all of peaceful regime change through voting? Technically yes, in practice? Probably not. I would expect extreme suppression and HK style riot crushing. They have been doing it quietly for decades, targeting and legally destroying/bankrupting any opposition to the PAP.
So the only real difference vs say China is that while both are authoritarian regimes the Chinese didn't bother with a mechanism to pretend you can throw them out.
To be clear, I don't object to their form of government. I think it works for them and thus it's completely ok. If anything I find Singapore a really safe and efficient place and visit frequently.
I do object to people pretending it's somehow a liberal democracy though, that just ain't the truth.
The actual problem is using a bunch of unportable vendor YAML for literally anything.
Define your entire build + artifact publishing pipeline in something like Bazel, Nix, etc and completely decouple everything from the runner. This allows running it locally and also switching runners extremely easily if one of them is no longer to your liking.
Don't fall prey to the vendor YAML trap.
Coming from a lot of bare metal C and FreeRTOS it finally feels like embedded is getting a toolchain that is actually modern and better.
Some of that isn't just Embassy but the surrounding ecosystem, some highlights:
* probe-rs w/cargo run integration
* defmt logging (combined with probe-rs and rtt it's very nice)
* embedded_hal (and in my case stm32-rs)
I have also tried RTIC but I decided to keep going with Embassy because I like the async ergonomics more and the few times it's been a downside/missing functionality (no existing async driver for specific peripherals basically) it wasn't to hard to implement what I needed.
I was surprised it just works out of the box on OS X also, generally speaking I would always end up having to use Linux to develop for embedded. Being able to compile on fast Apple M hardware and then run immediately with zero friction is awesome.
It took a little bit to get my head around how to share access to peripherals etc but once I did it's been great and it's nice to know that locking semantics are essentially enforced at compile time so it's actually not possible to have 2 things stomping over the same bus etc which can sometimes be a very hard bug to track down when working with big and fast SOCs.
Other really big aspect Embassy has been good for is really high quality USB and networking stacks. I am using both the USB stack (for PLDM over USB) and Ethernet w/the TCP stack in embassy_net and both have been flawless.
Only real downsides I can think of are it can sometimes be hard to onboard folk that are used to copy/paste from vendor examples and sometimes communicating and debugging with vendors themselves when they aren't familar and won't engage unless you can reproduce on the vendor HAL.
So overall really happy with it and I highly recommend trying it out especially if you are in the STM ecosphere.
So there isn't one reason, there is a ton of reasons.
It's not irrecoverable but it's bad. I honestly hope there is some wake-up moment for Americans when they realise that their leaders have been selling them out for decades now.
So nice to see there are good rules for Zig and that folks are using them.
Also ironically I think starting with Bazel/Buck/whatever your poison of choice is almost always a good move even if people tell you it's overkill. The easiest time to do it as at the beginning, all times after that is too hard and the marginal cost of building with it from the start is minimal.
1. Access to any extension you want and importantly ability to create your own extensions.
2. Being able to run any version you want, including being able to adopt patches ahead of releases.
3. Ability to tune for maximum performance based on the kind of workload you have. If it's massively parallel you can fill the box with huge amounts of memory and screaming fast SSDs, if it's very compute heavy you can spec the box with really tall cores etc.
Self hosting is rarely about cost, it's usually about control for me. Being able to replace complex application logic/types with a nice custom pgrx extension can save massive amounts of time. Similarity using a custom index access method can unlock a step change in performance unachievable without some non-PG solution that would compromise on simplicity by forcing a second data store.
They will be the first to sodium ion and solid state though.