I can't even read it because you either have to accept all tracking or pay a subscription fee. Pretty sure that's against the GDPR? Anyway, not a good look.
>We do not need vibe-coded critical infrastructure.
I think when you have virtually unlimited compute, it affords the ability to really lock down test writing and code review to a degree that isn't possible with normal vibe code setups and budgets.
That said for truly critical things, I could see a final human review step for a given piece of generated code, followed by a hard lock. That workflow is going to be popular if it already isn't.
It might when an individual function has 50 different models reviewing it, potentially multiple times each.
Perhaps part of a complex review chain for said function that's a few hundred LLM invocations total.
So long as there's a human reviewing it at the end and it gets locked, I'd argue it ultimately doesn't matter how the code was initially created.
There's a lot of reasons it would matter before it gets to that point, just more to do with system design concerns. Of course, you could also argue safety is an ongoing process that partially derives from system design and you wouldn't be wrong.
It occurred to me there's some recent prior art here:
I do not care how strong your vibes are and how many claudes you have producing slop and reviewing each others' slop. I do not think vibe coding is appropriate for critical infrastructure. I don't understand why you think telling me you'd have more slop would make me appreciate it more.
As I see it, the focus should not be about the coding, but about the testing, and particularly the security evaluation. Particularly for critical infrastructure, I would want us to have a testing approach that is so reliable that it wouldn't matter who/what wrote the code.
I have been thinking about that lately and isn't testing and security evaluation way harder problem than designing and carefully implementing new features? I think that vibecoding automates easiest step in SW development while making more challenging/expensive steps harder. How are we suppose to debug complex problems in critical infrastructure if no one understands code? It is possible that in future agents will be able to do that but it feels to me that we are not there yet.
AI as advanced fuzz-testing is ridiculously helpful though - hardly any bug you can in this sort of advanced system is a specification logic bug. It's low-level security-based stuff, finding ways to DDOS a local process, or work around OS-level security restrictions, etc.
I'm kind of doubtful that AI is all that great at fuzz testing. Putting that aside though, we are talking about web browsers here. Security issues from bad specification or misunderstanding the specification is relatively common.
I disagree. Thorough testing provides some level of confidence that the code is correct, but there's immense value in having infrastructure which some people understand because they wrote it. No amount of process around your vibe slop can provide that.
That's just status quo, which isn't really holding up in the modern era IMO.
I'm sure we'll have vibed infrastructure and slow infrastructure, and one of them will burn down more frequently. Only time will tell who survives the onslaught and who gets dropped, but I personally won't be making any bets on slow infrastructure.
I somewhat agree, but even then would argue that the proper level at which this understanding should reside is at the architecture and data flow invariants levels, rather than the code itself. And these can actually be enforced quite well as tests against human-authored diagrammatical specs.
If you don't fully understand the code how do you know it implements your architecture exactly and without doing it in a way that has implications you hadn't thought of?
As a trivial example I just found a piece of irrelevant crap in some code I generated a couple of weeks ago. It worked in the simple cases which is why I never spotted it but would have had some weird effects in more complicated ones. It was my prompting that didn't explain well enough perhaps but how was I to know I failed without reading the code?
Exactly. We do not have another artifact than code which can be deterministically converted to program. That is reason we have to still read the code. Prompt is not final product in development process.
It's extremely tempting to write stuff and not bother to understand it similar to the way most of us don't decompile our binaries and look at the assembler when we write C/C++.
So, should I trust an LLM as much as a C compiler?
Well if the big players want to tell me their models are nearly AGI they need to put up or shut up. I don't want a stochastically downloaded C compiler. I want tech that improves something.
What do you mean by "production ready" here exactly? In a web browser context, the JS engine is expected to have a high performance optimising JIT compiler. Do the existing Rust JS engines have that?
There's something to be said for the security benefits of not having a JIT though. Especially if you've used Rust for the engine you should have pretty solid security.
Yeah, having a code section that is writable and executable is a huge no-no from a security standpoint. JIT is a fundamentally insecure concept, just in general. By definition it's trading security for speed.
> Complete JavaScript execution pipeline from source code parsing to bytecode execution.
So it's a bytecode interpreter, not a JIT.
It might still be production ready for a bunch of use cases. I may use it as a scripting layer for some pluggable piece of software or a game. I wouldn't consider it appropriate for a "production ready web browser" which intends to compete with Firefox and Chrome.
EDIT: Also for some reason all its components are called v8_something? That's pretty off putting, you can't just take another project's name like that.. and from the author's Reddit comments it seems to be mostly AI slop anyway. I'm guessing Claude wrote the "production ready" part on the website, I wouldn't trust it.
The fundamental problem with Rust versioning is that 0.3.5 is compatible with 0.3.6, but not 0.4.0 or 1.0.0; when major version is 0, the minor takes the role of major and patch takes the role of minor. So packages iterate through 0.x versions, and eventually, they reach a version that's "stable".
If version 0.7 turned out to hit the right API and not require backward incompatible changes, releasing a version 1.0 would be as disruptive as a major version change to your users and communicate through version semantics that it is a breaking change.
Semver declares that version 0.x is for initial development where there is no stability guarantee at all. This is the right semantics for a versioning system, but Cargo doesn't follow this part of semver. Providing stability guarantees throughout the 0.x cycle inevitably results in projects getting stuck in 0.x.
This is one of my biggest gripes with Cargo. But Rust people seem to universally consider it a non-issue so I don't think it'll ever be fixed.
> The fundamental problem with Rust versioning is that 0.3.5 is compatible with 0.3.6, but not 0.4.0 or 1.0.0
That’s a feature of semver, not a bug :)
Long answer: You are right to notice that minor versions within a major release can introduce new APIs and changes but generally, should not break existing APIs until the next major release.
However, this rule only applies to libraries after they reach 1.0.0. Before 1.0.0, one shouldn’t expect any APIs to be frozen really.
To go further, semver provides semantics and an ordering but it says nothing about version requirement syntax. The caret operator to describe a range of versions is not part of the spec. It was introduced by initial semver-aware package managers such as npm or gem. Cargo decided to default to the caret operator, but it's still the caret operator.
In practice, there's no real issue with using the first non-zero component to define the group of API-compatible releases and most package managers agree on the semantics.
Eventually this will get cleared up. I’m close than I’ve ever been to actually handling this, but it’s been 9 years already, so what’s another few months…
> If version 0.7 turned out to hit the right API and not require backward incompatible changes, releasing a version 1.0 would be as disruptive as a major version change
TL;DR: You take the 0.7 library, release it as 1.0, then make a 0.7.1 release that does nothing other than depend on 1.0 and re-export all its items. Tada, a compatible 1.0 release that 0.7 users will get automatically when they upgrade.
Even more interesting is that you can use this to coordinate only partially-breaking changes, e.g. if you have 100 APIs in your library but only make a breaking change to one, you can re-export the 99 unbroken APIs and only end up making breaking changes in practice for users who actually use the one API with breaking changes.
The standard library has a whole bunch of tools to let them test and evolve APIs with a required-opt in, but every single ecosystem package has to get it right first try because Cargo will silently forcibly update packages and those evolution tools aren't available to third party packages.
Personally, I think the 0 major version is a bad idea. I hear the desire to not want to have to make guarantees about stability in the early stages of development and you don't want people depending on it. But hiding that behind "v0.x" doesn't change the fact that you are releasing versions and people are depending on it.
If you didn't want people to depend on your package (hence the word "dependency") then why release it? If your public interface changes, bump that major version number. What are you afraid of? People taking your project seriously?
0.x is not that you don't want people depending on it, you just don't want them to come and complain when you quickly introduce some breaking changes. The project is still in development, it might be stable enough for use in "real projects(tm)", but it might also still significantly change. It is up to the user to decide whether they are OK with this.
1.x communicates (to me at least) you are pretty happy with the current state of the package and don't see any considerable breaking changes in the future. When 2.x comes around, this is often after 1.x has been in use for a long time and people have raised some pain points that can only be addressed by breaking the API.
If you are at the point that other people can use your software, then you should use v1. If you are not ready for v1, then you shouldn't be releasing to other people.
Because this comment, "The project is still in development, it might be stable enough for use in "real projects(tm)", but it might also still significantly change." That describes every project. Every project is always in development. Every project is stable until it isn't. And when it isn't, you bump the major number.
I think we can come up with a reason why bumping the version number each breaking change isn't an elegant solution either: You would end up with version numbers in the hundreds or thousands.
Indeed! I think both 0-based versioning, and this (maybe?) downside I bring up addresses the tension between wanting to limit the damage caused by breaking changes with retaining the ability to make them.
Versioning is communication. I find it useful to communicate, through using version 0.x, "this is not a production ready library and it may change at any time, I provide no stability guarantees". Why might I release it in that state? Because it might still be useful to people, and people who find it useful may become contributors.
Any project may change at any time. That's why they bump from v1 to v2. But by not using the full precision of the version number, you're not able to communicate as clearly about releases. A minor release may not be 100% compatible with the previous version, but people still expect some degree of similarity such that migrating is not a difficult task. But going from v0.n to v0.(n+1) uses that field to communicate "hell, anything could happen, YOLO."
By releasing a library with version 1.0, I communicate: "I consider this project to be in a state where it is reasonable to depend on it".
By releasing a library with version 0.x, I communicate: "I consider this project to be under initial development and would advice people not to depend on in unless you want to participate in its initial development".
I don't understand why people find this difficult or controversial.
For example, sometimes projects that have a 0.y version get depended on a lot, and so moving to 1.0.0 can be super painful. This is the case with the libc crate in Rust, which the 0.1.0 -> 0.2.0 transition was super painful for the ecosystem. Even though it should be a 1.0.0 crate, it is not, because the pain of causing an ecosystem split isn't considered to be worth the version number change.
99% of the time this situation is okay, because Cargo allows you to have both 0.1 and 0.2 in the same project as dependencies. It's just packages that call out to external dependencies, like libc, where it enforces the single version rule.
This looks like a motte-and-bailey. Your original comment, the bailey: "he posted much religious stuff from official Intel accounts". This comment, the motte: "he posted much religious stuff".
You could've just said, "I thought it was extremely strange that he posted so much religious stuff while CEO". That would've been a very defensible position. You didn't need the false part of posting from official Intel accounts.
Or, if it was an honest mistake, you should've written something along the lines of: "Sorry, I misremembered, it was his personal accounts. But when you're a CEO, I don't think the distinction matters much; anything you post will be read as 'Intel's CEO says'".
I don't understand what you mean. Stock price has tripled since last August based on Intel finally having a competitive architecture and a competitive process again, no? At least that in combination with various geopolitical circumstances. Sounds like Pat's decision resulted in Intel's stock price rising?
Complaining about the distinction between apps and windows isn't a "stupid reason" to complain though.
Say I use Slack, Teams and Outlook. If I use their Electron versions, I switch between them with cmd+tab. If I use them in separate browser windows, I switch between them by using cmd+tab to switch to Firefox, then cmd+` to cycle through windows until I find the one I want. That's weird; how you switch between these three apps depend on the technical details on how you opened them? Why?
Say I have neovim, the mutt email client, and a shell open. These are three separate apps, but because they happen to run in a terminal emulator, I still have to cmd+tab to the terminal emulator, then cmd+` to cycle between them. They're semantically different applications in dedicated windows, but technical implementation details mean they belong to what macOS considers "the same app", just like the "apps in Firefox windows" example above.
It wouldn't be so bad if the cmd+` "cycle between windows in the app" feature worked well. But it doesn't. Unlike cmd+tab, it doesn't show a bar which you get to select from, it just instantly re-orders your windows; and it's impossible to select a window in another workspace. That means, if I have Slack open in Firefox in workspace 1 and Outlook open in Chrome in workspace 2, I can switch between Slack and Outlook with cmd+tab, but if I Slack open in Firefox in workspace 1 and Outlook open in Firefox in workspace 2, there is no way to switch between Slack and Outlook. That's pretty bad.
The (shift+)cmd+` order also resets to match the window z-order whenever you switch apps. So if the order is windows A, B, C, then you select window B, cmd+tab away, then cmd+tab back, the order will now be B, A, C.
I've developed an intuitive understanding of this, but I had to experiment just now to describe the behavior precisely. And my intuition is still wrong sometimes (like if the app has windows on multiple monitors, it's hard to predict the z-order).
> if I Slack open in Firefox in workspace 1 and Outlook open in Firefox in workspace 2, there is no way to switch between Slack and Outlook
My local maximum is to never use workspaces – just cmd+tab, cmd+`, and sometimes cmd+h to reduce screen clutter.
I would also add to this that in order to open two instances of an app the app explicitly needs to support this. For example, you can't open 2 instances of Calculator.app side by side.
If only I could write it down in a text note and refer to it and many more, as opposed to keeping a calculator window open per prior calculation I want to refer to...
Or if only there was a tool like Soulver or Calca...
Yes you can write down the result of calculations and all relevant state and then clear the state of the calculator window before doing a new calculation. But why?
The closest thing you can do on macOS is to turn on "reduced motion". This doesn't remove any animations, it just replaces them all with fade animations which take the same amount of time.
reply