> We’ve had our agents build many versions of this emulator as we’ve refined the building machine.
I'm curious how many versions they made and the token spend on each one. There are a lot of failure modes to projects like these (e.g. gas town endlessly developing itself). Is this more of a sly marketing stunt or a real indication that this methodology is practical and economical?
FYI I checked out the repo. `du --apparent-size -h` output for some dirs:
If Anthropic can't easily pay all these commitments, what are the odds that they get all their creditors together and negotiate a mini chapter 11 (e.g. by adding 5 years to the commitment timelines, or canceling a proportion of each commitment)? The creditors have no interest in Anthropic going under, and with enough advanced notice, they can pause or cancel their own investments and probably take reduced losses.
You can use free file fillable forms to submit online. It's a bit of work to transcribe from other software. It also requires a particular interpretation when filling forms (e.g. you need to round before summing your W-2s).
The bond market and the equity market care about different things. E.g. if the company has a 10% chance of going bankrupt and a 90% chance of doubling its market value, then paradoxically its bonds will look bad and its equity will look good.
Pangram says the last 2/3rds are AI generated. I suspected when I got to this line:
> The separation of concerns is deliberate — breakpoint() and is_debugger_present() are orthogonal building blocks, and breakpoint_if_debugging() is the convenience composition.
It might be a false positive or just a few spots. Or maybe it's rage bait. I'm sorry if the author actually writes with this style.
It's amazing and at this point, absolutely no surprise that HN has worse moderation of genAI than the cpp subreddit. The conflict of interest with AI has hit HN like 9/11.
> It's amazing and at this point, absolutely no surprise that HN has worse moderation of genAI than the cpp subreddit.
I don't think this is a fair assessment. Submissions from specific sources are more frequent in niche forums, as this helps them stand out. So once a blog is found to be spamming, it's easier to target the blog and not individual submissions.
This is much harder to do on generalist forums such as HN.
Sure, sure, but they've already won by even having a policy against AI slop articles and posts, which, to my knowledge, HN seems steadfast in refusing to do so. After all, the public is fiercely divided into mostly one side in favor of banning said articles. HN is apparently just going to ride this out with only a policy banning LLM comments.
At this point, my only reason for still being around on here is because I simply don't know of any place that I find strictly better. Most of the popular alternatives to HN are annoying in ways that I find equally hard or even harder to tolerate.
I accepted I was reading LLM output by the time I got to
None are constexpr — debugging is a runtime concern.
I am not very experienced with C++, but runtime debug functions are one of the last things where I'd expect compile-time computations. Inlining? Sure. Doing anything else at compile-time? Not really.
The sentence feels like a remark about something a human reader is very unlikely to be thinking about.
I used jellyfin-mpv-shim. You select what to play from any ui and it starts playing in mpv, which seems to have excellent support for everything you would want a player to do.
Tried it too, it still had judder as all other clients I've seen. I think it's either server software problem or maybe all clients fail to do this properly.
I think it's OK to increment/decrement the ends past each other as long as you detect that and fail the allocation for at least one end.
It's a little tricky with memory orders since you are synchronizing on two different locations. The simplest thing is to make all atomic accesses seqcst, but I think a single fence(seqcst) before checking overlap is sufficient in this case and will use fewer synchronizing instructions.
The overflow checks are also tricky. We want to make sure that if an allocation fails, subsequent allocations also fail (even on other threads), and overflow might allow them to think they succeeded by incrementing again back into a valid range. This means you generally can't use fetch_add in a thread-safe bump allocator and instead need to use a CAS loop where you detect overflow before writing.
Since you are doing a CAS loop anyway and always accessing both variables, it might actually be faster to combine both variables, especially if you typically allocate from both at the same time. E.g. if you pack two offsets into a 64-bit CAS word, you can still address 4GB, and you can get even more by aligning allocations. You also don't have to worry about seqcst.
> Just like the other stack allocators we talked about, this one can also work in a multi threaded environment. You might be tempted to make the two updates transactional – like with a compare and swap loop – but it isn’t needed.
Unfortunately they don't explain HOW this is going to work...
I don't think this is necessarily true. This wasn't purely hiring. They also licensed the technology and paid off the shareholders, which is why it's basically an acquisition in everything but name.
The problem is each step individually is important to allow companies to do, and follows as a nigh-irrefusable consequence of the previous. You can't ban companies from "poaching" employees, or you end up as an economic hellhole of indentured servants, like Florida, or New York. You can't ban the licensing of a companies technology, since we want innovators who don't necessarily have the opportunity to directly execute on their new technology to still innovate. And you can't ban paying the company for doing so, since that's the whole point.
Meanwhile, the way that plays out is that Google hires all the talent by fairly paying more than the startup can, then can turn around and say "your company is a dead man walking, you can either sell us your tech, or crash and burn with nothing", and the only fiscally responsible decision is to sell.
The rules aren't that simple. The combination should be considered holistically against antitrust law. It's a judgement call that ultimately comes down to a judge or jury.
Antitrust is also federal and is probably generally supreme over state law. E.g. even if Google fairly acquires talent according to state law, it can still be determined to violate antitrust.
This poaching scenario (where Big Co pays above market to a large number of employees to drive a competitor out of business) is very similar to dumping (selling goods below market etc.), which has been illegal for a long time even though "selling goods" is generally legal.
However, since the government (DoJ, FTC, etc.) is the ideal litigant, you actually need someone who works there to not get fired for long enough to complete investigation and enforcement. In a lot of anti-trust cases, all the direct participants benefit: the employees get paid more, Big Co consolidates power, and Small Co gets paid off. The "losers" are most distant like their customers or uninvolved competitors who aren't in a good position to sue.
Which is why at the top end we are supposed to have complementary laws. Bans on non-compete increase competition at the low end. Antitrust and government regulation/licensing at the high end prevent monopiles and thereby increase competition. The problem today is that we are dropping the ball on the high end, letting the Googles stamp down competition when, in decades past, they would have been broken up.
There are rumors that the employees did not get paid out. Such a deal could be done by, for instance buying the equity from the investors at a current fair market value.
That the new "investor" choses to let their investment die may not matter, it would also be cheaper to selectively buy out investors than buy out all equity in the company.
I don't know how they possibly read all these in full. They are quite voluminous: 1-3 work samples, 1 analysis sample, 1-3 writing samples, 1 presentation sample, and then 8 open-ended long-form questions. The instructions often say to give as much detail as possible, and they are very clear that this is the main way they filter candidates, so I'm guessing serious applications are quite long.
At some point, there becomes a mathematical impossibility of too many pages of applications for too few evaluators who also have to do the rest of their jobs. Either they don't get quite that many applications, or the initial evaluations must be based on some incomplete reading (looking just at the resume, reading a subsection, skimming, or randomly discarding), or the backlog keeps growing.
Fwiw I also applied and the auto-reply said I should expect to wait 4-6 weeks, which has recently passed without hearing back. The application is a ton of work, and I don't mind doing it with a significant chance of being considered, but I think it's a normal reaction to be devastated if you put all that time and energy into crafting your materials, which manifest all your experience, behavior, and personality, and it turned out nobody read them. I still have a little hope, but I'm sorry you never got a response.
A better analogy is that software dev is more like making the rug making machine. If you were doing that, it would be useful to be intimately familiar with precisely how rugs are made, and you might want to make a bit of one by hand in order to get that experience. Then when you design the machine, you use gears, 4 bar linkages, and other mechanisms that you are already familiar with because you carefully studied those concepts earlier, likely with some hands-on exercise. Then you draw a design, simulate it, and send it to a machine shop and can possibly never touch the machine itself (although I think in practice these kinds of bespoke first-gen machines need debugging after manufacturing).
I.e. in order to get to the point where you didn't have to manually touch this thing, you likely did have to learn deeply about its underlying concepts by manually doing things.
Operating machines doesn't always have the same phenomenon. E.g. experience with a hand-powered drill is unnecessary to use an electric drill.
I'm curious how many versions they made and the token spend on each one. There are a lot of failure modes to projects like these (e.g. gas town endlessly developing itself). Is this more of a sly marketing stunt or a real indication that this methodology is practical and economical?
FYI I checked out the repo. `du --apparent-size -h` output for some dirs:
311 MiB of rust code in /tests/ directories. 357 MiB of rust code outside of /tests/ directories. 117 MiB of json. 1 MiB of toml.reply