> The fundamental problem is that rust async was developed when epoll was dominant (and almost no one in the Rust circles cared about IOCP)
No, this is a mistaken retelling of history. The Rust developers were not ignorant of IOCP, nor were they zealous about any specific async model. They went looking for a model that fit with Rust's ethos, and completion didn't fit. Aaron Turon has an illuminating post from 2016 explaining their reasoning: https://aturon.github.io/tech/2016/09/07/futures-design/
See the section "Defining futures":
There’s a very standard way to describe futures, which we found in every existing futures implementation we inspected: as a function that subscribes a callback for notification that the future is complete.
Note: In the async I/O world, this kind of interface is sometimes referred to as completion-based, because events are signaled on completion of operations; Windows’s IOCP is based on this model.
[...] Unfortunately, this approach nevertheless forces allocation at almost every point of future composition, and often imposes dynamic dispatch, despite our best efforts to avoid such overhead.
[...] TL;DR, we were unable to make the “standard” future abstraction provide zero-cost composition of futures, and we know of no “standard” implementation that does so.
[...] After much soul-searching, we arrived at a new “demand-driven” definition of futures.
I'm not sure where this meme came from where people seem to think that the Rust devs rejected a completion-based scheme because of some emotional affinity for epoll. They spent a long time thinking about the problem, and came up with a solution that worked best for Rust's goals. The existence of a usable io_uring in 2016 wouldn't have changed the fundamental calculus.
Nvidia’s marketing team uses confusing terminology to make their product sound cooler than it is.
An Intel “core” can perform AVX512 SIMD instructions that involve 16 lanes of 32-bit data. Intel cores are packaged in groups of up to 16. And, they use hyperthreading, speculative execution and shadow registers to cover latency.
An Nvidia “Streaming Multiprocessor” can perform SIMD instructions on 32 lanes of 32-bits each. Nvidia calls these lanes “cores” to make it feel like one GPU can compete with thousands of Intel CPUs.
Simpler terminology would be: an Nvidia H100 has 114 SM Cores, each with four 32-wide SIMD execution units (where basic instructions have a latency of 4 cycles) and each with four Tensor cores. That’s a lot more capability than a high-end Intel CPUs, but not 14,592 times more.
The CUDA API presents a “CUDA Core” (single SIMD lane) as if it was a thread. But, for most purposes it is actually a single SIMD lane in the 32-wide “Warp”. Lots of caveats apply in the details though.
I've said it many times in the past: the OS is a toolbox, just like a carpenters toolbox.
I use it to keep my apps (tools) in. I use the apps (hammer, saw, screwdriver etc.) to get a job done, then I put them away. The job of the OS isn't to recommend that I use Hammer v2.0 or to update my toolbox to the latest version.
The OS is, or should be, out of my way.
I agree with others here: Windows 2000 was peak OS for me!
The fact that IP protection is expensive is essentially its defining feature. One way to think of "intellectual property" is precisely as a weird proof-of-work, since you are trying to simulate the features of physical property for abstract entities that by default behave in the exact opposite fashion.
This is the frustrating thing about getting into an argument about how "IP isn't real property" and then having the other side roll their eyes at you like you are some naive ideologue. They're missing the point of what it means for IP to not be "real property". The actual point is understanding that you are, and will be, swimming against the current of the fundamentals of these technologies forever. It is very very difficult to make a digital book or movie that can't be copied. So difficult in fact, that it we've had to keep pushing the problem lower and lower into the system, with DRM protections at the hardware level. This is essentially expensive, not just from a capital perspective, but from a "focus and complexity" burden perspective as well. Then realize that even after putting this entire system in place, an entire trade block could arbitrarily decide to stop enforcing copyright, AKA, stop fueling the expensive apparatus that is is holding up the "physical property" facade for "intellectual property". This was actually being floated as a retaliation tactic during the peak of the tariff dispute with Canada[1]. And in fact we don't even need to go that far, it has of course always been the case that patents vary in practical enforceability country to country, and copyrights (despite an attempt to unify the rules globally) are also different country to country (the earliest TinTin is public domain in the US but not in the EU).
Usually at this point someone says "It's expensive to defend physical property too! See what happens if another country takes your cruise liner". But that's precisely the point, the difficulty scales with the item. I don't regularly have my chairs sitting in Russia for them to be nationalized. The entities that have large physical footprints are also the ones most likely to have the resources defend that property. This is simply not the case with "intellectual property," which has zero natural friction in spreading across the world, and certainly doesn't correlate with the "owner's" ability to "defend" it. This is due to the fundamental contradiction that "intellectual property" tries to establish: it wants all the the zero unit-cost and distribution benefits of "ethereal goods," with all the asset-like benefits of physical goods. It wants it both ways.
Notice that all the details always get brushed away, we assume we have great patent clerks making sure only "novel inventions" get awarded patents. It assumes that patent clerks are even capable of understanding the patent in question (they're not, the vast majority are new grads [2]). We assume the copyright office is property staffed (it isn't [3]) We assume the intricacies of abstract items like "APIs" can be property understood by both judge and jury in order to reach the right verdict in the theoretically obvious cases (also turns out that most people are not familiar with these concepts).
How could this not be expensive? You essentially need to create "property lore" in every case that is tried. Any wish for the system to be faster would necessarily also mean less correct verdicts. There's no magic "intellectual property dude" that could resolve all this stuff. Copyright law says that math can't be copyrighted, yet we can copyright code. Patent law says life can't be patented, yet our system plainly allows copyrighting bacteria. Why? Because a lawyer held of a tube of clear liquid and said "does this seem like life to you?" The landmark Supreme Court case was decided 5-4 [4], and all of a sudden a thing that should obviously not be copyrightable by anyone that understands the science was decided it was. There's no "hidden true rules" that if just followed, would make this system efficient. It is, by design, a system that makes things up as it goes along.
As mentioned in other comments, at best you could just flip burden to the other party, which doesn't make the system less expensive, it just shifts the default party that has to initially burden the cost. Arguably this is basically what we have with patents. Patents are incredibly "inventor friendly". You can get your perpetual motion machine patented easy-peasy. In fact, there is so much "respect" for "ideas" as "real things", that you can patent things you never made and have no intention of making. You can then sue companies that actually make the thing you "described first". Every case is a new baby being presented to King Solomon to cut in half.
In other words, an inexpensive system would at minimum require universal understanding and agreement on supremely intricate technical details of every field it aims to serve, which isn't just implausible, it is arguably impossible by definition since the whole point of intellectual property is to cover the newest developments in the field.
A regular "chatting" LLM is a document generator incrementally extending a story about a conversation between a human and a robot... And through that lens, I've been thinking "chain of thought" seems like basically the same thing but with a film noir styling-twist.
The LLM is trained to include an additional layer of "unspoken" text in the document, a source of continuity which substitutes for how the LLM has no other memories or goals to draw from.
"The capital of Assyria? Those were dangerous questions, especially in this kind of town. But rent was due, and the bottle in my drawer was empty. I took the case."
I have had this pet theory for a decade+ that this is the case for most of the economy, and the current "recirculative bubble" is just a really strong example of it happening in a tighter loop than usual.
Think about the classic economics fairy tale of why income redistribution is bad ("inefficient") and trickle-down economics is good.
Billionaire Bill buys his 10th yacht. Workers need to manufacture the yacht and all the different parts of it. He needs to hire staff to keep it clean, to maintain it, to operate it, and to stock the fridge; he needs to pay for satellite internet so he can do business on the yacht; and he needs to buy TVs for the kids. All of that stuff is produced by other businesses with their own employess and sometimes independent contractors. So all of this economic economic activity results in a flow of income to a large number of individuals. Those individuals then themselves all need to buy groceries, clothes, housing, transportation, etc. so all that income then continues to flow outward throughout the economy. The price system orchestrates everything so that the proceeds from Billionaire Bill's yacht are used to provide the goods and services of greatest value to everyone else.
That story of course is nonsense, but the question is: why? It seems correct. In fact it is broadly correct in the sense that the things described in the story do in fact happen in real life. So why isn't it a happy ending like in the fairy tale?
There are a few things going on here, but the one of importance here is where are those yacht-builder employees buying their goods and services from?
One missing aspect of the story is that they're paid a tiny amount compared to the top management of the yacht company and a few other specialists like the naval engineer, the captain, and the lead software developer. So they don't actually have a lot to spend. And what they do spend money on is largely provided by conglomerates controlled largely by Millionaire Mike and Trillionaire Todd, who of course are very close friends of Bill. Mike and Todd know ensure that their prices are as high as possible to capture as much of their customers' income as revenue. Mike and Todd then go buy golfing trips, yachts, mansions, etc. And the cycle continues.
The effect is that all the individual employees do in fact get some of Bill's billions of dollars in the form of income, but they only get enough to cover their essentials, and any profit from buying those essentials goes right back into the hands of another person just like Billionaire Bill. The income does in fact flow throughout the economy as in the bedtime story, but you can't understand the welfare of individuals within the economy by just looking at total flows.
You don't need to be a Marxist to see that this is how the economy works and has worked since the dawn of capitalism. It's a natural low-energy state that economies naturally tend towards, because humans are humans and there is always a minority that is willing and able to take avantage of others.
The only difference here is that the loop is tighter, where Bill Todd and Mike are all just buying each other's services directly.
I don't think we should have so much VC anyway. Most of that is just basically gambling. Most of these startups crash and burn. Here in Europe we frown on that, just like we frown on taking out loans and credit cards.
Here in Europe the best credit rating is for the person who's never needed a loan or credit before. It proves they're smart with money. But US citizens have to roll money between credit cards monthly.
The VC in the US mainly existed because interest was so low that money was easy to throw around and see if it stuck. That's no longer the case but these companies are from the time it was.
I don't think we should try to become another America. We don't want unconstrained ratrace capitalism here. And we can never out-US the US (even though China does manage to do that). We should just make alternatives in our own way. Solid with good foundations, play the game by our rules not someone else's.
Here's the full original definition from Karpathy:[*]:
> There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It's possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good. Also I just talk to Composer with SuperWhisper so I barely even touch the keyboard. I ask for the dumbest things like "decrease the padding on the sidebar by half" because I'm too lazy to find it. I "Accept All" always, I don't read the diffs anymore. When I get error messages I just copy paste them in with no comment, usually that fixes it. The code grows beyond my usual comprehension, I'd have to really read through it for a while. Sometimes the LLMs can't fix a bug so I just work around it or ask for random changes until it goes away. It's not too bad for throwaway weekend projects, but still quite amusing. I'm building a project or webapp, but it's not really coding - I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works.
Some of the key points here being "forget that the code even exists," "'Accept All' always," "don't read the diffs," and "The code grows beyond my usual comprehension."
Doing software engineering using AI assistance is not vibe coding, by Karpathy's definition.
I've used it a bit. I've done some very useful stuff, and I've given up with other stuff and just done it manually.
What it excels at is translation. This is what LLMs were originally designed for after all.
It could be between programming languages, like "translate this helm chart into a controller in Go". It will happily spit out all the structs and basic reconciliation logic. Gets some wrong but even after correcting those bits still saves so much time.
And of course writing precise specs in English, it will translate them to code. Whether this really saves time I'm not so convinced. I still have to type those specs in English, but now what I'm typing is lost and what I get is not my own words.
Of course it's good at generating boilerplate, but I never wrote much boilerplate by hand anyway.
I've found it's quite over eager to generate swathes of code when you wanted to go step by step and write tests for each new bit. It doesn't really "get" test-driven development and just wants to write untested code.
Overall I think it's without doubt amazing. But then so is a clown at a children's birthday party. Have you seen those balloon animals?! I think it's useful to remain sceptical and not be amazed by something just because you can't do it. Amazing doesn't mean useful.
I worry a lot about what's happening in our industry. Already developers get away with incredibly shoddy practices. In other industries such practices would get you struck off, licences stripped, or even sent to prison. Now we have to contend with juniors and people who don't even understand programming generating software that runs.
I can really see LLMs becoming outlawed in software development for software that matters, like medical equipment or anything that puts the public in danger. But maybe I'm being overly optimistic. I think generally people understand the dangers of an electrician mislabelling a fusebox or something, but don't understand the dangers of shoddy software.
I’m sorry but I can’t help to hate it. It feels like the start of a kind of capitalist cancer, eating its way through the ecosystem, taking away the freedom of maintainers and turning them into slaves for maintenance fee-payers, and eventually goodware into crapware.
How can one simultaneously be paid for maintenance and also be free of liability? And should someone forking an open source project now be treated as a criminal for interrupting someone’s livelihood?
Finally, it feels that paying a recurring subscription is against the ethos of the “open source forefathers” so to speak. Open source software originated from a world where we paid once for software, like DVDs, not like Netflix. And I would have hoped the world has realised this was a bad idea and is trying to circle back, not undo the path backwards.
> Many tasks have easier verifications than doing the task.
In the software world (like the article is talking about) this is the logic that has ruthlessly cut software QA teams over the years. I think quality has declined as a result.
Verifiers are hard because the possible states of the internal system + of the external world multiply rapidly as you start going up the component chain towards external-facing interfaces.
That coordination is the sort of thing that really looks appealing for LLMs - do all the tedious stuff to mock a dependency, or pre-fill a database, etc - but they have an unfortunate tendency to need to be 100% correct in order for the verification test that depends on them to be worth anything. So you can go further down the rabbit hole, and build verifiers for each of those pre-conditions. This might recurse a few times. Now you end up with the math working against you - if you need 20 things to all be 100%, then even high chances of each individual one starts to degrade cumulatively.
A human generally wouldn't bother with perfect verification of every case, it's too expensive. A human would make some judgement calls of which specific things to test in which ways based on their intimate knowledge of the code. White box testing is far more common than black box testing. Test a bunch of specific internals instead of 100% permutations of every external interface + every possible state of the world.
But if you let enough of the code to solve the task be LLM-generated, you stop being in a position to do white-box testing unless you take the time to internalize all the code the machine wrote for you. Now your time savings have shrunk dramatically. And in the current state of the world, I find myself having to correct it more often then not, further reducing my confidence and taking up more time. In some places you can try to work around this by adjusting your interfaces to match what the LLM predicts, but this isn't universal.
---
In the non-software world the situation is even more dire. Often verification is impossible without doing the task. Consider "generate a report on the five most promising gaming startups" - there's no canonical source to reference. Yet these are things people are starting to blindly hand off to machines. If you're an investor doing that to pick companies, you won't even find out if you're wrong until it's too late.
The AI tooling churn is so fast that by the time a study comes out people will be able to say "well they were using an older tool" no matter what tool that the study used.
It is limited viewing, requires a reservation & the slots run out practically in seconds. Tough for us residents to get it as well. My wife could snag it in her third try, as a late birthday trip last year.
It is gargantuan & having massive holding capacity. To give semblance with something familiar, it was like standing in NY Grand Central station, except it was felt bigger, empty, damp & illuminated by floodlights from all sides. It is probably one and half football fields in length & scales high as much as a five storied building. Uploaded three pics to show the scale of this megalith. (The base of the pillars here are taller than average height of person to give a rough scale. The stairs come down from the ground level)
In addition to this underground chamber, there are two massive pumps on either sides, which divert the water from whichever river is surging to the other (Arakawa & Edogawa possibly). The chamber is the buffer zone between the rivers, not a storage tank ultimately. I was told by the civil engineer of this plant they could pump out as much as a jumbo jet's volume per minute in its storm surge channel/drain to manage flooding. You can walk up to the turbine room at the end of this room, and see its massive blades at an arm length. All with earthquake protection in place as well. Honestly mind-blowing piece of engineering.
Personally, I prefer AI to stay in its own corner. Let ChatGPT, Gemini, and the rest be something I open when I need them, like a website or an app. I'm not really into the whole "everything should have AI built into it" idea.
It kind of reminds me of how the internet used to be. Back then, you had to go to a specific room to use the family computer. The internet was something you visited. Now, tech is everywhere, from our pockets to our bathrooms. I’m not sure I want AI following that same path.
The JavaScript name came out of a cross-licensing deal between Netscape and Sun where Netscape would bundle a copy of the JVM with their browser. Sun needed a way to put the JVM on most Windows users' computers to get developers to write Java software instead of Windows software, and they knew Microsoft wouldn't ship a product that would threaten the Windows platform's domination, so they figured that bundling with Netscape was their next best option. If you read the initial JavaScript press release ( https://www.tech-insider.org/java/research/1995/1204.html ), it's mainly marketed as a way to write glue code to make it possible for Java applets (where the real application logic would go) to interact with an HTML page:
> With JavaScript, an HTML page might contain an intelligent form that performs loan payment or currency exchange calculations right on the client in response to user input. A multimedia weather forecast applet written in Java can be scripted by JavaScript to display appropriate images and sounds based on the current weather readings in a region. A server-side JavaScript script might pull data out of a relational database and format it in HTML on the fly. A page might contain JavaScript scripts that run on both the client and the server. On the server, the scripts might dynamically compose and format HTML content based on user preferences stored in a relational database, and on the client, the scripts would glue together an assortment of Java applets and HTML form elements into a live interactive user interface for specifying a net-wide search for information.
> Java programs and JavaScript scripts are designed to run on both clients and servers, with JavaScript scripts used to modify the properties and behavior of Java objects, so the range of live online applications that dynamically present information to and interact with users over enterprise networks or the Internet is virtually unlimited. Netscape will support Java and JavaScript in client and server products as well as programming tools and applications to make this vision a reality.
> "Programmers have been overwhelmingly enthusiastic about Java because it was designed from the ground up for the Internet. JavaScript is a natural fit, since it's also designed for the Internet and Unicode-based worldwide use," said Bill Joy, co-founder and vice president of research at Sun. "JavaScript will be the most effective method to connect HTML-based content to Java applets."
This was all implemented, and Java applets had full interoperability with JavaScript. Applets could call JavaScript functions, and JavaScript functions could call applet methods. Of course over time people gave up on Java applets and JavaScript became a good enough language to write real application logic directly in it. It's true that JavaScript now has virtually nothing to do with Java, but that wasn't the case initially, and the name has at least some logic behind it.
> To be fair, the quality of software has dramatically dropped, apps now take 10 seconds to load, memory usage is maxed, games crash and people needed to reinstall their OS so frequently that Microsoft literally added a "reset PC" option..
Are you talking about the 90s or now? Because those were all at least as true then as now. Everything took forever. You needed more RAM every month. Everything crashed constantly. I had to reinstall Win98SE so many fucking times that I can still type F73WT-WHD3J-CD4VR-2GWKD-T38YD from memory.
The amount of suck in commercial software is constant. Companies always prioritize adding the shiny-looking features that sell software to rubes over improving things like memory use, response time, and general quality of life until the quality of life is actually bad enough to drive customers to another vendor, so it's perpetually bad enough to keep the average customer right on the edge of "oh fuck this, I'm switching to something else."
And even then, people were never against most of it. Scrollbar thumbs with grip stipple? Checkboxes that fill in with a roundrect rather than a checkmark? Buttons and tabs that have an inline ring-highlight "intent" color to them, akin to the fill color on modern Bootstrap theme buttons? These were all parts of the Luna theme as well — and people liked them. (And, IIRC, they were often sad that these parts got deactivated when reverting to the Windows Classic theme, and often asked if there was some hybrid theme that kept these.)
With Luna, I think people were mainly just reacting negatively to two things:
1. the start button being big and green and a weird blob shape; the start menu it opens having a huge, very rounded forehead and chin — and both of these having a certain "pre-baked custom PNG image 8-way sliced in Photoshop and drawn by parts" look that you'd see used on web pages in this era. This made the whole UI feel very "non-brutalist" — form not following function, the way it did in Windows Classic (where the theme was in part designed to optimize for as few line-draw GDI calls as possible.)
2. both the taskbar and window title bars being vertically thicker, and having a vaguely-plastic-looking sheen to them to "add dimensionality."
And my hypothesis is that, of these, it was mainly the "vertically thicker" taskbar+window decorations that upset so many people.
This was an era where many screens were still largely 1024x768, even as monitor sizes were growing; so "small was cool" [and legible!] Websites baked their text into images using 8x5 pixel fonts; Linux users used tiny fonts and narrow themes in fvwm/blackbox/fluxbox, etc. In that era, a title bar stealing thirty whole pixels was almost blasphemy. (Same problem with the Office XP ribbon. Microsoft's visual designers must have been too far ahead-of-the-curve in what kind of resolutions their graphics cards supported, I think.)
I think, if there was an alternate version of Luna that also shipped with XP, that just narrowed the taskbar and window caption bar to the Windows Classic dimensions... then Luna would have been universally acclaimed.
What urge? The urge to understand what the software you're about to build upon is doing? If so, uh... no. No thanks.
I've seen some proponents of these code-generation machines say things like "You don't check the output of your optimizing compiler, so why check the output of Claude/Devon/whatever?". The problem with this analogy is that the output from mainstream optimizing compilers is very nearly always correct. It may be notably worse than hand-generated output, but it's nearly never wrong. Not even the most rabid proponent will claim the same of today's output from these code-generation machines.
So, when these machines emit code, I will inevitably have to switch from "designing and implementing my software system" mode into "reading and understanding someone else's code" mode. Some folks may be actually be able to do this context-shuffling quickly and easily. I am not one of those people. The results from those studies from a while back that found that folks take something like a quarter-hour to really get back into the groove when interrupted while doing a technical task suggest that not that many folks are able to do this.
> Think in interfaces...
Like has been said already, you don't tend to get the right interface until you've attempted to use it with a bunch of client code. "Take a good, educated stab at it and refine it as the client implementations reveal problems in your design." is the way you're going to go for all but the most well-known problems. (And if your problem is that well-known, why are you writing more than a handful of lines solving that problem again? Why haven't you bundled up the solution to that problem in a library already?)
> Successive rendering, not one-shot.
Yes, like nearly all problem-solving, most programming is and always has been an iterative process. One rarely gets things right on the first try.
Dangle-trains are one of those things that appeal to me for unknown reasons, they just look so cool. But I am unable to really quantify the appeal, so here is my attempt.
Advantages:
keeps your electrical plant out of the weather
allows the track to be out of the road while allowing street level access to train. This one is a bit iffy as the dangle train will usually be put above street traffic.
Disadvantages:
look at how much steel it takes to make that box beam.
Every thing is in tension, leading to complicated structure to contain it, joints can be much simpler in compression.
Any how as a dangle-train connoisseur I leave you with two additional videos.
I agree with the last paragraph about doing this yourself. Humans have tendency to take shortcuts while thinking. If you see something resembling what you expect for the end product you will be much less critical of it. The looks/aesthetics matter a lot on finding problems with in a piece of code you are reading. You can verify this by injecting bugs in your code changes and see if reviewers can find them.
On the other hand, when you have to write something yourself you drop down to slow and thinking state where you will pay attention to details a lot more. This means that you will catch bugs you wouldn't otherwise think of. That's why people recommend writing toy versions of the tools you are using because writing yourself teaches a lot better than just reading materials about it. This is related to know our cognition works.
The reason for this limit, at least on modern systems, is that select() has a fixed limit (usually 1024). So it would cause issues if there was an fd higher than that.
The correct solution is basically 1. On startup every process should set the soft limit to the hard limit, 2. Don't use select ever 3. Before execing any processes set the limit back down (in case the thing you exec uses select)
There are so many possible scripts that could be based on what has happened since 2022 in Ukraine. There would be no need for exaggeration of the heroism, bravery, and loss. The only issue might be that people would not believe it actually happened.
From Zelenskyy, a previous comedic actor refusing to flee, "I need ammunition, not a ride," to the defense of Snake Island "Russian warship, go fuck yourself," to all the brave women who volunteered, the farmers towing abandoned Russian tanks, the constant drone attacks on residential and commercial areas, the 40,000 stolen Ukrainian children, this most recent attack on Russian air bases...
If this was a movie, I would probably think it was a bit much myself, but this all happened. We witnessed it.
Well, I'd think of it like being car-dependent. Sure, plenty of suburbanites know how to walk, they still have feet, but they live somewhere that's designed to only be practically traversable by car. While you've lived that lifestyle, you may have gained weight and lost muscle mass, or developed an intolerance for discomfort to a point where it poses real problems. If you never got a car, or let yourself adapt to life without one, you have to work backwards from that constraint. Likewise with the built environment around us; the cities many people under the age of 40 consider to be "good" are the ones that didn't demolish themselves in the name of highways and automobiles, in which a car only rarely presents what we'd think of as useful technology.
There are all kinds of trades that the car person and the non-car person makes for better or worse depending on the circumstance. The non-car person may miss out on a hobby, or not know why road trips are neat, but they don't have the massive physical and financial liabilities that come with them. The car person meanwhile—in addition to the aforementioned issues—might forget how to grocery shop in smaller quantities, or engage with people out in the world because they just go from point A to B in their private vessel, but they may theoretically engage in more distant varied activities that the non-car person would have to plan for further in advance.
Taking the analogy a step further, each party gradually sets different standards for themselves that push the two archetypes into diametrically opposed positions. The non-car owner's life doesn't just not depend on cars, but is often actively made worse by their presence. For the car person, the presence of people, especially those who don't use a car, gradually becomes over-stimulating; cyclists feel like an imposition, people walking around could attack at any moment, even other cars become the enemy. I once knew someone who'd spent his whole life commuting by car, and when he took a new job downtown, had to confront the reality that not only had he never taken the train, he'd become afraid of taking it.
In this sense, the rise of LLM does remind of the rise of frontend frameworks, bootcamps thay started with React or React Native, high level languages, and even things like having great internet; the only people who ask what happens in a less ideal case are the ones who've either dealt with those constraints first-hand, or have tried to simulate it. If you've never been to the countryside, or a forest, or a hotel, you might never consider how your product responds in a poor connectivity environment, and these are the people who wind up getting lost on basic hiking trails having assumed that their online map would produce relevant information and always be there.
Edit: To clarify, in the analogy, it's clear that cars are not intrinsically bad tools or worthwhile inventions, but had excitement for them been tempered during their rise in commodification and popularity, the feedback loops that ended up all but forcing people to use them in certain regions could have been broken more easily.
This entire section reads like, oddly, the reverse of the "special pleading" argument that I usually see from artists. Instead of "Oh, it's fine for other fields, but for my field it's a horrible plagiarism machine", it's the reverse: "Oh, it's a problem for those other fields, but for my field get over it, you shouldn't care about copyright anyway".
I'm all for eliminating copyright. The day I can ignore the license on every single piece of proprietary software as I see fit, I'll be all for saying that AIs should be able to do the same. What I will continue to complain about is the asymmetry: individual developers don't get to violate individual licenses, but oh, if we have an AI slurp up millions of codebases and ignore their licenses, that's fine.
No. No, it isn't. If you want to ignore copyright, abolish it for everyone. If it still applies to everyone else, it should still apply to AIs. No special exceptions for mass-scale Open Source license violations.
> "For art, music, and writing? I got nothing. I’m inclined to believe the skeptics in those fields."
You've already lost me, because I view programming as an art form. I would no more use AI to generate code than I would use it to paint my canvas.
I think the rest of the article is informative. It made me want to try some things. But it's written from the perspective of a CEO thinking all his developers are just salt miners; miners go into the cave and code comes out.
I think that's actually what my hangup is. It's the old adage of programmers simply "copying and pasting from stack overflow" but taken to the extreme. It's the reduction of my art into mindless labor.
>simple fact that you can now be fuzzy with the input you give a computer, and get something meaningful in return
I got into this profession precisely because I wanted to give precise instructions to a machine and get exactly what I want. Worth reading Dijkstra, who anticipated this, and the foolishness of it, half a century ago
"Instead of regarding the obligation to use formal symbols as a burden, we should regard the convenience of using them as a privilege: thanks to them, school children can learn to do what in earlier days only genius could achieve. (This was evidently not understood by the author that wrote —in 1977— in the preface of a technical report that "even the standard symbols used for logical connectives have been avoided for the sake of clarity". The occurrence of that sentence suggests that the author's misunderstanding is not confined to him alone.) When all is said and told, the "naturalness" with which we use our native tongues boils down to the ease with which we can use them for making statements the nonsense of which is not obvious.[...]
It may be illuminating to try to imagine what would have happened if, right from the start our native tongue would have been the only vehicle for the input into and the output from our information processing equipment. My considered guess is that history would, in a sense, have repeated itself, and that computer science would consist mainly of the indeed black art how to bootstrap from there to a sufficiently well-defined formal system. We would need all the intellect in the world to get the interface narrow enough to be usable"
Welcome to prompt engineering and vibe coding in 2025, where you have to argue with your computer to produce a formal language, that we invented in the first place so as to not have to argue in imprecise language
>If you were trying and failing to use an LLM for code 6 months ago †, you’re not doing what most serious LLM-assisted coders are doing.
Here’s the thing from the skeptic perspective: This statement keeps getting made on a rolling basis. 6 months ago if I wasn’t using the life-changing, newest LLM at the time, I was also doing it wrong and being a luddite.
It creates a never ending treadmill of boy-who-cried-LLM. Why should I believe anything outlined in the article is transformative now when all the same vague claims about productivity increases were being made about the LLMs from 6 months ago which we now all agree are bad?
I don’t really know what would actually unseat this epistemic prior at this point for me.
In six months, I predict the author will again think the LLM products of 6 month ago (now) were actually not very useful and didn’t live up to the hype.
"It pains me to say this, but I think that differentiating humans from bots on the web is a lost cause."
Ah, but this isn't doing that. All this is doing is raising friction. Taking web pages from 0.00000001 cents to load to 0.001 at scale is a huge shift for people who just want to slurp up the world, yet for most human users, the cost is lost in the noise.
All this really does is bring the costs into some sort of alignment. Right now it is too cheap to access web pages that may be expensive to generate. Maybe the page has a lot of nontrivial calculations to run. Maybe the server is just overwhelmed by the sheer size of the scraping swarm and the resulting asymmetry of a huge corporation on one side and a $5/month server on the other. A proof-of-work system doesn't change the server's costs much but now if you want to scrape the entire site you're going to have to pay. You may not have to pay the site owner, but you will have to pay.
If you want to prevent bots from accessing a page that it really wants to access, that's another problem. But, that really is a different problem. The problem this solves is people using small amounts of resources to wholesale scrape entire sites that take a lot of resources to provide, and if implemented at scale, would pretty much solve that problem.
It's not a perfect solution, but no such thing is on the table anyhow. "Raising friction" doesn't mean that bots can't get past it. But it will mean they're going to have to be much more selective about what they do. Even the biggest server farms need to think twice about suddenly dedicating hundreds of times more resources to just doing proof-of-work.
It's an interesting economic problem... the web's relationship to search engines has been fraying slowly but surely for decades now. Widespread deployment of this sort of technology is potentially a doom scenario for them, as well as AI. Is AI the harbinger of the scrapers extracting so much from the web that the web finally finds it economically efficient to strike back and try to normalize the relationship?
1. Banner ads made more money. This stopped being true a while ago, it's why newspapers all have annoying soft paywalls now.
2. People didn't have payment rails set up for e-commerce back then. Largely fixed now, at least for adults in the US.
3. Transactions have fixed processing costs that make anything <$1 too cheap to transact. Fixed with batching (e.g. buy $5 of credit and spend it over time).
4. Having to approve each micropurchase imposes a fixed mental transaction cost that outweighs the actual cost of the individual item. Difficult to solve ethically.
With the exception of, arguably[0], Patreon, all of these hurdles proved fatal to microtransactions as a means to sell web content. Games are an exception, but they solved the problem of mental transaction costs by drowning it in intensely unethical dark patterns protected by shittons of DRM[1]. You basically have to make someone press the spend button without thinking.
The way these proof-of-work systems are currently implemented, you're effectively taking away the buy button and just charging someone the moment they hit the page. This is ethically dubious, at least as ethically dubious as 'data caps[2]' in terms of how much affordance you give the user to manage their spending: none.
Furthermore, if we use a proof-of-work system that's shared with an actual cryptocurrency, so as to actually get payment from these hashes, then we have a new problem: ASICs. Cryptocurrencies have to be secured by a globally agreed-upon hash function, and changing that global consensus to a new hash function is very difficult. And those hashes have economic value. So it makes lots of sense to go build custom hardware just to crack hashes faster and claim more of the inflation schedule and on-chain fees.
If ASICs exist for a given hash function, then proof-of-work fails at both:
- Being an antispam system, since spammers will have better hardware than legitimate users[3]
- Being a billing system, since legitimate users won't be able to mine enough crypto to pay any economically viable amount of money
If you don't insist on using proof-of-work as billing, and only as antispam, then you can invent whatever tortured mess of a hash function is incompatible with commonly available mining ASICs. And since they don't have to be globally agreed-upon, everyone can use a different, incompatible hash function.
"Don't roll your own crypto" is usually good security advice, but in this case, we're not doing security, we're doing DRM. The same fundamental constants of computing that make stopping you from copying a movie off Netflix a fool's errand also make stopping scrapers theoretically impossible. The only reason why DRM works is because of the gap between theory and practice: technically unsophisticated actors can be stopped by theoretically dubious usages of cryptography. And boy howdy are LLM scrapers unsophisticated. But using the tried-and-true solutions means they don't have to be: they can just grab off-the-shelf solutions for cracking hashes and break whatever you use.
[0] At least until Apple cracked Patreon's kneecaps and made them drop support for any billing mode Apple's shitty commerce system couldn't handle.
[1] At the very least, you can't sell microtransaction items in games without criminalizing cheat devices that had previously been perfectly legal for offline use. Half the shit you sell in a cash shop is just what used to be a GameShark code.
[2] To be clear, the units in which Internet connections are sold should be kbps, not GB/mo. Every connection already has a bandwidth limit, so what ISPs are doing when they sell you a plan with a data cap is a bait and switch. Two caps means the lower cap is actually a link utilization cap, hidden behind a math problem.
[3] A similar problem has arisen in e-mail, where spammy domains have perfect DKIM/SPF, while good senders tend to not care about e-mail bureaucracy and thus look worse to antispam systems.
> But Celsius as a temperature scale is no more logical than Fahrenheit
Celsius is more logical:
(1) the endpoints of Celsius are boiling/melting point of water (at standard atmospheric pressure). The lower endpoint of Fahrenheit is the lowest temperature Fahrenheit could achieve using a mixture of water, ice and ammonium chloride-using the freezing point of pure water is more logical than using the freezing point of an ammonium chloride solution-water is fundamental to all known life, ammonium chloride solutions don’t have the same significance (and why ammonium chloride instead of sodium chloride or potassium chloride? of the salts readily available to Fahrenheit, the ammonium chloride solution had the lowest freezing point)
(2) Fahrenheit initially put 90 degrees between his two “endpoints” (ammonium chloride solution freezing point and human body temperature), then he increased it to 96. Celsius having 100 degrees between its endpoints is more logical than 90 or 96
(3) while for both Celsius and Fahrenheit, there is error in the definition of their endpoints (the nominal values are different from the real values, because our ability to measure these things accurately was less developed when each scale was originally devised, and some unintentional error crept in)-the magnitude of that error is smaller for Celsius than for Fahrenheit
(4) nowadays, all temperature units are officially defined in terms of Kelvin - and Celsius has a simpler relation to Kelvin than Fahrenheit (purely additive versus requiring both addition and multiplication)
(5) Celsius is the global standard for everyday (non-scientific) applications, not Fahrenheit, and it is more logical to use the global standard than a rarely used alternative whose advantages are highly debatable at best
No, this is a mistaken retelling of history. The Rust developers were not ignorant of IOCP, nor were they zealous about any specific async model. They went looking for a model that fit with Rust's ethos, and completion didn't fit. Aaron Turon has an illuminating post from 2016 explaining their reasoning: https://aturon.github.io/tech/2016/09/07/futures-design/
See the section "Defining futures":
There’s a very standard way to describe futures, which we found in every existing futures implementation we inspected: as a function that subscribes a callback for notification that the future is complete.
Note: In the async I/O world, this kind of interface is sometimes referred to as completion-based, because events are signaled on completion of operations; Windows’s IOCP is based on this model.
[...] Unfortunately, this approach nevertheless forces allocation at almost every point of future composition, and often imposes dynamic dispatch, despite our best efforts to avoid such overhead.
[...] TL;DR, we were unable to make the “standard” future abstraction provide zero-cost composition of futures, and we know of no “standard” implementation that does so.
[...] After much soul-searching, we arrived at a new “demand-driven” definition of futures.
I'm not sure where this meme came from where people seem to think that the Rust devs rejected a completion-based scheme because of some emotional affinity for epoll. They spent a long time thinking about the problem, and came up with a solution that worked best for Rust's goals. The existence of a usable io_uring in 2016 wouldn't have changed the fundamental calculus.