This was nowhere near the top submission. But even if a solo engineer could get a top kernel, you don't think that having thousands of engineers, infinite tokens, and stronger models than are available to the public would give the labs a significant edge?
Does the edge matter? I know you added significant as your hedge, but once you have feedback, your gain is largely irrelevant. Gain buys you bandwidth, so we are constructing systems run by the most powerful corporations where they are now optimizing for latency, as Archer says, do you want to flash crash civilization? This is how you do it.
1. labs have lots of inference capacity
2. they will have domain experts working on this so their efficiency is gonna be exponentially more (can direct LLM better, save money, reach same results faster)
You can't exceed roofline performance on hardware. There is an performance cap you can hit. This recursive self improvement stuff lets you be closer to the pareto frontier, but the idea that it is leading to some exponential growth is a total pipe dream.
See my comment above - the common language rulesets work in similar ways as Buck(2), AIUI. (Except bazel has features to consume external dependencies without vendoring, as opposed to Reindeer approach for example). Another difference is that since Bazel has much more adoption across the OSS world, there are more viable choices in language implementation rulesets, as opposed to Buck's prelude.
This comment gives off the impression that bazel just wraps cargo/pip/npm invocations, which is incorrect (at least in the commonly used scenarios)
First of all, bazel does not handle any of these languages/ecosystems itself. Such logic is delegated to language-specific rulesets, of which there are multiple implementations with different tradeoffs.
While it's true that bazel allows to patch all dependencies on the fly, in my experience many Bazel users do try to contribute back, because managing stacks of hundreds of patches across all your dependencies isn't particularly fun.
To be honest this stuff feels like it's gotten soooo much better in the years since I've used Bazel. (one can easily argue that it's been thanks to language ecosystems getting their things better) compared to when I've last had to use Bazel back in 2021-2022 (I had initially set up Bazel in ... 2018 for an existing Python project). So this might be a bit like relitigating Python 3.0. The lessons are learned perhaps!
If I want to be very cynical... I think there is a universe where uv could have existed 5 years earlier if Google had decided "we're going to extract our Bazel learnings to get Python packaging to be better".
You might say "well they have blaze they don't need this" and that's kind of the point. In the world of setup.py you still need some language-specific infrastructure. Google and friends could have pushed things along in interesting ways, IMO!
But given their general sort of "we just vendor everything in" attitude they don't need to do that. So language ecosystems don't get the right kind of pushes and it takes us a decade for someone in the Python community to write "lockfiles that work + a package installer that works". Feels like a missed opportunity, mainly.
Zig is also a god send in that it has all the generated glibc header bullshit for Linux.
I've got a system that is able to cross-compile ffmpeg for Linux from Windows. Which is a shockingly painful and rare capability. Linux userspace design is so so so so so bad. So embarrassingly bad.
yes, that was my point. as domeone who uses ai extensively to write zig (and someone who has made very small non-AI cobtributions to zig in the past), rejecting ai is currently a strategically good decision for core zig.
Look into Bazel, a very standard build system used at many large tech companies. It splits fetches from build/test actions and allows blocking network for build/test actions with a single CLI flag. No hassle at all.
The fact that you haven't come across this kind of setup suggests that your hundreds of CI systems are not representative of the industry as a whole.
I agree our sample may not be representative but we try to stay focused on the current and next crop of tpuf customers rather than the software industry as a whole. So far "CI prohibits network access during tests" just hasn't come up as a pain point for any of them, but as I mentioned in another comment [0], we're definitely keeping an open mind about introducing an offline dev experience.
(I am familiar with Bazel, but I'll have to save the war stories for another thread. It's not a build tool we see our particular customers using.)
Even if you ignore all the other benefits of type annotations, merely being explicit about the types of parameters your function accepts helps people reading your code.
If you're going to make the argument that you can just add comments with the types - well then that's exactly what mypy is doing, but if you do it in the mypy format you get static analysis of your types for free.
Static typing and unit testing aren't mutually exclusive.
> What does mypy do if you make a call from code with type annotations into code without? Or vice-versa?
It's not able to analyze across such boundaries, but as you expand the set of typed code you get better and better coverage.
> Has anyone ever gotten paid to add annotations to code that works?
At Dropbox, we're starting to add type annotations to code. We're confident it will catch many bugs at lint time.
Source: I work at Dropbox.
> Personally, I view type systems as like a safety line when doing work on a roof, and optional typing as having a line that might or might not be tied off.
At least it has the possibility of being tied off and catching you. Better than definitely not having a line.
