It's not really political. Or let me rephrase possibly yt-dl is being political. VUT the concept of 'not adopting a core dependency until it has been widely used in production for 6 months - a year.', is not a political on general. A full rewrite of 1 million loc is essentially a new runtime that has the same ABI as the previous and for many downstream consumers it's not something they are comfortable taking a production dependency on. If for sale of argument BUn was fully rewritten by hand would be the same situation. I personally think this kind of decision is pretty standard, I also personally think the Bun LLM rewrite will be of good quality overall, but I certainly would not bet my product/company on it. I want to be the one making the risky changes on my software not being forced into it by downstream deps.
I think your stance is more reasonable than the one in the article, TBH. If yt-dlp said something like "We're going to wait 6 months on the Rust rewrite", that would be reasonable. But instead it says something more like we think that Bun is vibe-coded, so we don't want to use it any more. That seems less reasonable.
It's not less reasonable. They don't have to promise giving Bun time in the future to evaluate. They might do it but they absolutely don't have to be responsible for doing it when the project made such dramatic shift.
They can do absolutely what they want with their project especially when its majority decision. There can't be no doubt about that.
They can absolutely do what they want, and I can absolutely say it's an unreasonable decision. When I say "unreasonable", I am evaluating whether they are operating on sound technical principles or not - not like, "are they allowed to do this" or something more obviously true.
Why is it unreasonable, from a technical standpoint, to avoid vibe-coded software?
To me, proving a vibe-coded piece of software is fit for purpose is much more difficult than if it is human-written, or LLM-assisted with a human reviewing all the generated code.
> Bun was recently rewritten in Rust using Claude, and its development seems to have taken a turn towards being fully vibe-coded. This is alarming and disappointing for a number of reasons, and frankly it seems like a future headache that we'd prefer to avoid. We are adding a support ceiling of version 1.3.14, as that is the last release built from the original zig codebase.
That’s as reasonable as it gets. Yt-dlp isn’t a beta testing grounds for hyperscalers.
Even re-written by hand isn't the same because a hand re-write proceeds slower over a longer period of time with more smaller updates that get tested somewhat along the way.
Also I don't think it's wrong to use an action as an input to judging engineering character. That could be read as judging yt-dlp or judging bun but in this case I mean it's reasonable to judge bun's developers.
IDK if i'd personally judge this action quite so badly though. It depends how they went about it and what they proffessed to get out of it.
I am very much against letting llms think and decide for you, but I don't think it's so wrong for an actual coder to employ automation.
But if they are acting like it's magic and everything will be so much better after the magic llm uses the magic safe language... yeah that definitely gets the side eye. Or no eye. Just no longer interested in or concerned with their output.
Since this is being offered as the next release version while still being new and stuffed with unsafe, looks like it's the latter. So I'm with yt-dlp in this case.
It doesn't matter if the new code happens to be ok or not, it's still a problem that they got there by hoping a black box does the right thing. A black box that that no one wrote and no one understands, not just themselves.
gcc is a black box to me, but I know that someone wrote it and understands it (or some people collectively understand all it's parts), and I know that any time I want, I can choose to understand any part of it, and satisfy myself that it is doing something both sane and deterministic.
So a developer choosing to use gcc when it's a black box to them does not reflect badly on them to me.
But no one can say that about any llm or ai. So yeah, a developer choosing to use them, depending on exactly how, may reflect badly on them.
The same was true for cheap off-shore gig coding by humans too. I have tried to use them myself in the past, hire out for small generic programming jobs using those web sites where you put up some escrow money and post a job and people bid for it, you choose one, they do it and get paid from the escrow. I only tried about 3 times for the same small job and every time I git ridiculously shit (but technically functional) results.
These were humans 15-20 years ago, no possibility of hidden ai usage like today, and it's essentially the same dynamic of just hoping some magic will get you something good for cheap, and accepting any result that appears good as good.
If someone said that that's how they made their product, I would decide that product is probably pretty crap inside and no way should I buy it or invest in it as a dependency if I have any choice.
And that's humans not ai. The problem isn't really the ai, it's the judgement to use an ai that way.
I don't think it's helpful to call this psychosis. N
Beyond that I don't think it's even irrational.
It is definitely factual that there is a complete paradigm shift in the prioritization of quality in software. It's beyond just AI side effects, and now its own stand alone thing.
There have always been many industries, companies, and products who are low on quality scale but so cheap that it makes good business sense, both for the producer and the consumer.
Definitely many companies are explicitly chosing this business strategy. Definitely also many companies that don't actually realize they are implicitly doing this.
Wether the market will accept the new software quality paradigm or not remains an open question.
Generally agree with this stance case in point: the breakthrough in ai coding was not that AI intelligence increased as much as that a lot of the core process execution moved out of the LLM prompt and into the harness.
This again? In general, Software Engineering is not engineering.
It's not a technical issue, it's a 'software doesn't really kill people so government doesn't intervene in it'. In the case where the software is life and death it's generally developed in ways similar to 'real' engineering
Fundamentally folks built building/structures without engineering, just so consistently caused death and destruction that govt stepped in and started requiring licensed trained folks, approval trails etc. without this real world intervention regular physical 'engineering' the same crap shoot as software engineering.
> it's a 'software doesn't really kill people so government doesn't intervene in it'
I think we've reached the point where this is no longer true - self driving cars, supposed robots you can take home, LLMs being unleashed to randomly guess at medical data or write software to do verification or sensitive tasks.
I think software engineering is definitely engineering, we've just been successful in lobbying against proper regulation. But all that is changing, the EU is introducing the Cyber Resilience Act and I think we need a lot more of that.
Any place money is changing hands needs at least enough engineering, enough "application of scientific principles," to do it securely. Observably failing at that task means it ends up not being a pet food store. (It ceases to exist or becomes a scam instead.)
It really does. The pet food store app asks me for my cat’s allergies and medical conditions. Someone needs to be responsible if they fuck it up. Same with self driving cars - the whole idea of “engineering” is about quality and responsibility.
“Quality” is subjective, so you’re correct that it’s not about quality. A tool designed with a planned lifespan of 100 hour lifespan is just as much a product of engineering as one designed to last 10k.
Responsibility though is very much is a central component of capital E Engineering. The modern profession in many ways is a direct response to big newsworthy engineering disasters.
When you hire a Professional Engineer there are minimum safety standards that they must meet. They can't charge you less and waive their liability. They are essentially required by law to "sell you some responsibility".
> This again? In general, Software Engineering is not engineering.
Software Engineering is definitely Engineering. But Software Development usually doesn't practice it. I've got a degree in Computer Engineering and took SE courses and at least at the companies I've been at, we never did any of that. You can't use formal methods without a formalized specification, and I never even got a written specification of any project I worked on in 20+ years. Regardless, Software Engineers don't wear stripey hats and are not real engineers.
There's not much structual engineering in single family home construction either. A couple story wood frame building needs to be pretty exotic to have structural issues (but soft story buildings used to be common and collapse with strong earthquakes)
I don't do a lot of frontend work. But when I did, the mocks were almost always best case; no mocks for when there was missing data (which was often). I did work on one project with an interaction designer, which was great --- having all the flows laid out was awesome, but it was only the happy path.
Software "engineering" doesn't kill people instantly in a flashy way, sure, but it has become more like leaded gasoline, a widespread low-level harm whose effects are increasingly evident in hindsight. You pretty much can't go more than a couple of days without hearing about another massive consumer data compromise by hackers, CVE, major services outage, etc. At some point, there is going to be a software related incident that is bad enough that the public and government is going to demand accountability.
Boeing, insulin pumps I could think of, missiles exploding on the pylon, lot of ways software can (almost) kill instantly, like that rocket that started flying sideways due to I think switching measurement units
The things you list illustrate @aplamers point that software "doesn't really kill people". If you asked the average person on the street, they might just barely remember the Boeing incidents and the rest they probably have never heard of. Even something as gruesome as the Therac-25 incident is probably unknown to most.
It's the rising tide of low-level everyday harm from software that is going to motivate the public to start coming after the software industry.
You know there had to have been increased literal pain and suffering from patients while hospitals scrambled to fall back on old methods of coordination and communication.
This shit is serious and I'm tired of people arguing that our craft should not be taken seriously.
A lot of us work on infrastructure just as vital as bridges and tunnels, and with real world consequences when these things fail.
Almost no physical engineering requires licensing either. Most things are YOLO-ed without a licensed engineer because it isn't required and adds little value.
The issue is that software systems are qualitatively more complex than any physical system due to their intrinsic malleability. Physical systems are sufficiently simple that formal verification methods are actually tractable (and used).
Physical products require the CE mark [0], so software systems (especially the complex ones) should be able to meet the same standard because they’re used in places where bugs and glitches can cause harm.
Many engineered physical devices can't cause harm to their end users the same way you say software cannot. And many software applications can cause harm to people both directly and indirectly. See social media, or hacks and data leaks which can destroy the lives of individuals or countries.
> In the case where the software is life and death it's generally developed in ways similar to 'real' engineering
I think even that is highly romanticised by people. Take Boeing's two big blunders in recent years. The Max and Starliner both had terrible terrible software practices that were "by the book". The problem is "the book" really changed a lot, and the behemoths haven't kept up.
It used to be that "the NASA way" was the most reliable way to build software, and there are still articles and blog posts shared here about the magical programming "rules", but frankly they've been left behind by the industry. On the Starliner project Boeing was seen as the "stable, reliable, tried and true" partner, while Dragon was seen as the "risky" one. Yet Boeing doing everything by the book had 2 loss of crew problems in their first uncrewed demo flight, one relating to software timers, and their crewed demo flight was plagued by problems root-caused to a lack of integration testing. Again, everything by the book, and they failed multiple times on the happy path! The book has to be rewritten, taking into account what the software industry (tech) has "learned" in the past decades. Just think about man-hours and amounts of billions that went into tech software engineering and you can see that obviously NASA can't keep up.
I think, rather, you're romanticizing what "real" engineering looks like.
Real engineering doesn't mean that mistakes are never made or that there are never bugs. Rather, it is that systems are tested thoroughly enough, and designed with enough failsafes and redundancy, that safety concerns are mitigated.
The problem in the Boeing case was not that the software had bugs. Lots of aviation software has bugs, it's actually very common. Rather, the problem was that they did not design the system to be safe in the event a bug occurred.
How that looks exactly tends to differ depending on the system. As a common example, many aircraft systems have other systems which monitor them and emit a warning if they detect something which doesn't make sense. Though this would've required Boeing to create technical material for pilots on how to respond to this new type of warning, which would've required training updates, which would've required recertification of their plane design, the cost of which Boeing desperately wanted to avoid. Fortunately (unfortunately), FAA oversight had become very lax, so Boeing instead just downplayed the safety concerns and nobody asked any questions.
> Rather, it is that systems are tested thoroughly enough, and designed with enough failsafes and redundancy
Yeah... That's one of the main reasons why engineers from most other disciplines have a lot of difficulty creating large reliable software.
Testing systems and adding failsafes are not nearly enough for system reliability, and not the best way to add it to software. It's almost enough for mechanical engineering... Almost, because it's not enough to make human interactions safe.
Just like with systems reliability, nobody knows it well. But some things we do know are that keeping it simple quickly becomes more impactful than adding failsafes, and you need to design quality holistically from the top down, and not focus at failures or known failure modes.
And just to say, the fact that nobody has any idea how to engineer systems reliability is the main reason why we have a duopoly in large airplanes that everybody expects to turn into a monopoly soon. If we knew how to do it, companies would pop into the market all the time.
Software engineering absolutely is engineering. Engineering is not defined by presence of regulations. Engineering is about solving practical problems within the constraints of physical reality and economics.
TFA (and your comment indirectly) seem to be about the lack of rigor in software engineering. However, any discussion of engineering that leaves out economics and costs is fundamentally incomplete.
The only reason most software development seems to have less rigor is because the economics of most software projects permit it. Other domains of software engineering where lives are on the line definitely have high levels of rigor.
Safety is not the only parameter that can be engineered (obviously), nor is it the only one subject to regulation. Efficiency for example is regulated, like when the EPA states what an appliance must accomplish while using some amount of energy. Meeting that guideline takes engineering.
Developing an application is applying techniques but by nature, you don't really build the same application many times such that you can come up with rules that the daily grunt applies without thought.
What is the software equivalent of spacing studs interspersed with fireblocks that we're not doing?
In software, easily repeated steps and proper practices are moved to the runtime/language/compiler etc.
Is it too conceited to argue that each application is more unique than each housing structure? I'm not sure. But we do actually have many many practices in place that are automatically handled.
> Is it too conceited to argue that each application is more unique than each housing structure?
I would say the exact opposite, actually. Two random software applications designed for the same purpose are likely much more similar to each other than two random buildings that were built for the same purpose.
This is because, for practical reasons, the software applications are likely just going to be slight variations of the same base. Unless your application is extremely intricate, most of the complexity (and most of the code that's executing) is actually in the kernel and the libraries. You're mostly just reusing those shared components and arranging them in a slightly different way.
> What is the software equivalent of spacing studs interspersed with fireblocks that we're not doing?
You're comparing apples to hockey pucks. For the analogy to hold, you need to specify what industry the software is for. i.e., if I'm building a garden shed, I don't need a specific stud spacing or even fireblocks at all. Hell, I can build it from raw timber if I have enough of it.
That doesn't really sound like an invalid analogy, you just don't need the same fire code for all structures but there are still fire codes that apply to building sheds.
I'm not sure what your point is. Like, ok, you came up with a structure that doesn't need a lot of structural engineering but clearly others do. So what are you trying to say?
That asking about a "software equivalent" isn't possible to answer without specifying an industry or what's being built. It will vary considerably between an human-implantable device or a game on your phone.
> What is the software equivalent of spacing studs interspersed with fireblocks that we're not doing?
>
> In software, easily repeated steps and proper practices are moved to the runtime/language/compiler etc.
At least in my opinion, that doesn't make them _not_ the equivalent of spacing studs interspersed with fireblocks, etc. It just makes it automatic... the same way that contractors buy materials that have certain things build into them (weather resistant, fire retardant, etc).
Just like it's entirely possible to build software without using common libraries (roll your own, etc); one can do the same with buildings. The only difference is the official rules requiring they way things are done.
Who makes the software that "real" engineers use to design bridges? Can developers of such software afford to be any less rigorous than the "real" engineers?
Most software flaws would manifest during the design phase, and a crashed application just causes design delays (pushing back bridge opening, but still). The sort of software flaw that would cause the application to not crash, but to mysteriously micalculate some load/shear/whatever limit seems unlikely. You'd almost need a silicon bug, a floating point unit that just totally shits the bed and comes up with a retard result.
That said, I'm in general agreement that the software developers should be as rigorous as the "real" engineers, but that's often just impossible from an office politics standpoint.
The sort of software flaw that would cause the application to not crash, but to mysteriously micalculate some load/shear/whatever limit seems unlikely.
Numeric instability is not only possible, but downright common in application software. You don't need exotic floating point issues to cause it.
When a software error can simultaneously shut down hospitals, air transport, ground transport, emergency services, and telecommunications, I don't see how the design of that software system should be held to a different legal standard than the design of, say, a steam turbine at a power plant, or the electrical grid itself.
> "The outage disrupted daily life, businesses, and governments around the world. Many industries were affected—airlines, airports, banks, hotels, hospitals, manufacturing, stock markets, broadcasting, gas stations, retail stores, and governmental services, such as emergency services and websites. The worldwide financial damage has been estimated to be at least US$10 billion"
It’s because it doesn’t directly kill a bunch of people all at once in a way that causes public outcry.
If it weren’t for the many large scale “flashy” engineering disasters that caught the attention of the average person, we wouldn’t have any of the Engineering regulations we have today.
My guess is that at some point some piece of software will kill enough people or cause a large enough economic disaster that we’ll start seriously regulating it.
This again? You don't need a license to be an engineer. Every graduate of an engineering school at an accredited university/college IS an engineer. People seem to conflate an "engineer" with a "professional engineer". The two are not the same; the latter requires a license. At least in the US.
There are states that regulate the bare term “engineer” depending on the context.
And all states require a license to offer certain engineering services, so practically speaking in certain fields you can’t “be an engineer” without a license.
For example in most (all?) states you can’t hang up a shingle adverting yourself as an “Engineer” doing structural work without a license even if you aren’t calling yourself a “Professional Engineer”.
Government did not invent the discipline of engineering. This is just completely backwards. How do you think all of those engineering organizations came up with those manuals and regulations, were they not doing any engineering until they published a manual? Complete nonsense.
I don't think the title and the article really communicates it's case well. Did not understand the goal until 90% through the article when they showed the source code of RCL with the loops.
This isn't syntax vs abstraction. This is how much programming language power do you want to enable in your configuration language. This is a big difference and I think we miss the interesting part of that discussion because we dip into this 'abstraction angle.
I think if people want a more powerful, programmable config language, maybe they should use something like Lua or Scheme instead of reinventing the wheel with those new niche languages.
I upvoted this, because while it was critical it didn't feel meanspirited and it was factually correct.
After fully reading the article I came to understand it really was not referring to anything sqllite specific, was really 'what if you ran postgres as an application on a server', there really is nothing more to be gained from reading the article beyond this, and this is kind of the most basic deployment model for postgres for like the last 40 years.
Sure, you are correct! But I've already learned about pglite and sqlite-vector from the comments here alone. So if one reads the article AND the comments, I hope it's a net-positive for you, too, even if the article alone didn't give you anything.
And if not, I hope you didn't spend too long reading. :-)
Ultimately the important thing is that the development team align on the style of programming that they will use at least per project. And the larger the codebase and more developers working on it the more important the consistency in implementing the style guide is.
Imperative programming style has many advantages over functional for some problems. Functional programming style has many advantages over imperative for some problems.
The only clearly 'wrong' approach is codebases where you can look at the code and determine a specific developer on the team wrote feature x because it fundamentally looks completely different from the other sections.
I don't think 'gentrification' is the right word for this. However the comments here do illustrate an underlying 'real' phenomenon what ever you call it.
Just for clarity:
- Non-Japan Asia is new to gaming, and that's okay, it's going to take some time before they find their own voice.
This is not factually true, video games have one of the most popular forms of entertainment in non Japan Asia for 25 years. Nearly a quarter of humanity lives in non-japan asia. There were good non japanese games, bad non japanese games, and more than anything tons of 'mid' non japanese games. They aren't new too it, and they do have their own voices and styles.
What gets talked about as history of video gaming tends to reflect American video gaming history and the unavoidable influence of America's number one vassal state, Japan. Really this is the history of games marketed in North America and that's fine, it just isn't the whole history.
I am not knocking the article but seems like if you are going to dedicate the effort of learning quick mental math it's probably more efficient to 'just' know how to multiple 2 digits quickly than specifically focusing on 2 digit squares...
