Looking at the benchmarks, 5.4 is slightly better. But it also offers "Fast" mode (at 2x usage), which - if it works and doesn't completely depletes my Pro plan - is a no brainer at the same or even slightly worse quality for more interactive development.
My own experience is that I get far far more usage (and better quality code, too) from codex. I downgrade my Claude Max to Claude Pro (the $20 plan) and now using codex with Pro plan exclusively for everything.
Thanks - and no, I haven't seen this one. I like how they have the edit mode dashboard - show the original image + two edits; I was thinking about doing something like this.
I'm also a bit surprised they have gpt-image-1.5 so high above Nano Banana 2 - my limited testing shows that, at least for the visual styles, people like Nano Banana more.
Yeah I think that it's part of the issue with a single "squashed" comparative metric. Some users are going to grade higher based on the overall visual fidelity and others are going to value following the prompt.
For a point of reference, I run a pretty comprehensive image model comparison site heavily weighted in favor of prompt adherence.
EDIT: FWIW, I agree with your assessment. OpenAI's models have always been very strong in prompt adherence but visually weak (gpt-image-1 had the famous "piss filter" until they finally pushed out gpt-image-1.5)
Thanks. So I have a bespoke python program that basically does this:
- Takes the platonic set of prompts
- Uses model specific tuning directives with LLMs to create a bunch of prompt variations so that they get a diverse set of natural language expressions to "roll" generations
But I still have to manually review each of the final image - which is pretty time-consuming. I've tried automating it using VLMs (like Qwen3-VL) but unfortunately they can miss the small details and didn't provide as much value as I was hoping.
Shutting down low-volume, complex project, that needs to be substantially redesigned to be competitive, while these resources can be redeployed elsewhere, in high growth areas? I disagree: https://news.ycombinator.com/item?id=46805773
"HN is dying" is a cliche, I know, but I seriously want to bookmark this thread to revisit it in 10 years - I'm sure it will age even better than (in)famous Dropbox thread. So from that perspective, HN is alive and well :).
The level of cynicism of the discussion is overwhelming, frankly. I get it that some people don't like Musk because of his politics, but why should that prevent people interested in technology to at least try to present a steelman case?
Let me try it, at a risk to be down-voted to oblivion...
1. As people correctly point out, S&X are outdated, low volume models. Investing more engineering time in them doesn't make any business sense; these engineering resources and capital should be clearly redeployed elsewhere.
2. People think that Waymo is supposedly better(?) than FSD, but at least some very well informed people (and NVIDIA as a company) believe that it's not. Personal anecdote: an older (HW3) version of Tesla drove me perfectly well in Yosemite last weekend, in on winding mountain roads with 0 cell phone coverage. It will take Waymo forever to map everything there properly with LIDAR, and true autonomy only in selected metro areas has limited value.
3. It's obvious that when we have autonomous, general purpose humanoid robots, they will completely transform our societies. Any such robots would require an enormous AI/vision investment. Say what you want about Elon, but xAI basically caught up with the top LLM shops in ~18 months, and now have comparable AI training capacity. You can bet against Optimus, but who else would have the skills to bring both the technology and the AI to market first? China? Good robotics, but no enough data to train their vision models comparing to Tesla, at least not yet.
4. So the bear case is that (a) driving autonomy is not possible without LIDAR, (b) Tesla can't bring another very complex product to market, and (c) autonomous robots are not possible in our lifetime. If you look at the AI progress even in the last 12 months, that's a tough sell to me.
What are the serious, tech-based counterarguments to the points above?
Okay, I'll bite. For the record, I own Tesla stock and I am generally bullish about AI.
I'll try to provide some counter-points specifically regarding the rate of progress.
3. It's much easier to catch up in capability (ex. LLMs) than it is to achieve a new capability (ex. replace humans laborers with humanoid robots). You can hire someone from a competitor, secrets eventually leak out, the search space is narrowed etc.
4(c). To me, what's most important is whether or not truly autonomous humanoid robots happens in 3 years, 5 years, 10 years, etc. rather than in our lifetime.
These timelines will be tied to AI development timelines which largely outside the control of any one player like Tesla. I believe the world is bottlenecked on compute and that the current compute is not sufficient for physical AI.
It's extremely easy to be too early (ex. many of the self driving car companies of the past decade), and so for Tesla, there is a risk of over-investing in manufacturing robots before the core technology is ready.
Re: both 3 and 4(c) - agree that compute (or maybe even power for that compute) is likely to be a bottleneck in the next 3-5 years. However, I think Tesla/xAI are better positioned than many competitors as Tesla is a manufacturing company first and foremost; and this expertise (which is shared freely between Musk's companies) can help it to build it's own data centers, power generation (e.g., solar), or - in the most bullish case - even fab capacity.
1. Your argument is that cutting off a rotting limb is good. Obviously it is, but I'd rather not have a rotting limb in the first place. I want a healthy, revenue-generating limb.
2. Waymo has been offering a driverless taxi service for some time now, and Tesla is not. That's a hard fact. Meanwhile your arguments are beliefs and personal anecdotes.
When, or rather if, Tesla starts offering their service, they will be behind Waymo by approximately however long ago Waymo started theirs, so at least a few years.
Unless you have some "serious, tech-based counterarguments"?
3. It's also obvious that when we have AGI, fusion, etc., they will completely transform our societies. I promise I will deliver you those by the end of this year. Send money now. If my timeline slips by a little—maybe a few decades—well, it was just a best-effort estimate and I did deliver in the end!
4. No, the bear case is that there's no real reason to believe Tesla would be the company that captures the market vs any other company. Their solar, tunnelling, and now car business models have failed/are failing, so they must win on self-driving/robots.
Self-driving is looking really bad, they're badly losing to Waymo.
They have shown nothing in terms of robots. If anything, dressing people up as robots and showing that is a rather negative signal. Oh, and robots are at least a 10x harder problem than self-driving.
Only if you are confusing FSD and actually autonomous. Which is basically just a bait and switch on Musk's part. FSD is whatever Musk says it is, actually autonomous is another thing entirely.
Thanks for saying this. For new, impressionable minds here who read most of the comments here and think this it's all devs - it isn't. A lot of us value Musk and incredibly awesome tech like FSD and aren't consumed by political partisanship. That tells you more about the commenter than Musk.
Some of these same commenters were trying to make you believe not long ago that FSD wasn't going to be competitive with Waymo because it dropped LIDAR. If you bring that up now they'll just change goalposts. There's no point even arguing with someone unable to approach an argument in good faith.
What's with the "outdated" adjective? There's nothing in the US market even remotely close to the X. Every other EV is a slapdash pile of hoobajoobs and knobs that can't even drive itself.
Source: 45000 miles in a bit over two years, loved every minute of it. Makes our other high priced German car a disappointing machine to be avoided if possible.
You might be more informed that I am. We only have 3 and Y in the family. I based my statement on th fact that S/X were last refreshed 5 years ago; so they would need to be refreshed fairly soon.
Dropbox really was shit, the fact that we lampoon the HN anti-Dropbox guy is evidence that this place died long ago. You really could have just done it with rsync and I'm so glad Claude Code exists to kill every other shit SaaS business that doesn't deserve to exist. Dropbox first please.
i think there's a danger here of underestimating how varied mankinds 'mindware' is at large.
for us lot who were 'born in it, molded by it' (tech), it can be very hard to internalize that there are a lot of people out there who legimiately cannot for the life of them wrap their head around a computer, or the internet, other than "wifi logo = i can video call my grandkids".
you could say services like dropbox are outreach/charity organisations that onboard the masses onto 10x productivity curves (whether they like it or not!)
and to be honest, ive become guilty of drag n dropping tarballs to/from my gdrive account when im too dumb to figure out the ssh proxy tunnel incantation (or beg an llm for one for the 1000th time.) so really, everyone wins.
im not sure claude code will change all that much for the non-technical segment. from their point of view, you changed one terminal window for another. so what? its still a black box (literally).
Hard to tell whether you are serious or sarcastic, but assuming it's the former: my contrarian position on CC vs SaaS is that in the quest to kill shitty businesses people will discover that creating a high-value SaaS is very non-trivial. CC would kill a whole category of low effort SaaS while at the same time substantially raising the quality bar for SaaS that people are willing to pay money for.
I’m using it on Linux for an embedded product. No reason other than it’s a nice language that I am familiar with and productive in. The async/await features are quite nice too when you need to implement a lot of protocols / state machines.
Personally I stay away from Corp owned languages. Even cross platform ones like .net, Java and also swift. With the single commercial party owning it you never know if theyll close it, change things for the worse or get acquired by a hostile party which obviously happened to java :(
Which language would you classify as not corp owned?
It’s also weird to include Java and Swift in that list considering both afaik are maintained by a separate foundation. Java from Sun is even predominantly basically OpenJDK with some remaining proprietary Sun / Oracle bits but it’s the reference open source implementation used by most everyone.
> Java from Sun is even predominantly basically OpenJDK with some remaining proprietary Sun / Oracle bits but it’s the reference open source implementation used by most everyone.
Note that Oracle contributes around 90% of the work to OpenJDK. If they decided to stop working on it, there would be a big gap to fill.
That’s generally true of most languages. Rust is struggling with this right now.
I’d say though that Oracle is highly unlikely to stop working on Java and Google is still invested in the JDK even though they’re trying to shift new code in this space towards Kotlin (another “corp owned” language)
For a significant portion of time Python was funded by Google, Meta and Facebook and maybe some other corps.
Zig doesn’t have any serious adoption in the industry yet but if/when it does I’d expect corps to be hiring the language devs.
JS is a consortium but it’s filled primarily with Google and Apple engineers.
Same goes for C/C++ lot of Apple, MS and Google engineers.
Elixir I’m not sure about. Rust was largely turns out employed by Amazon until the most recent culling.
It’s not surprising. This is technically difficult work and if the language is important to a corp they’ll hire the maintainers. There needs to be a funding source and in the industry that typically means a for profit company paying the salary of the people moving things forward. Indeed - it’s one of the things Rust is struggling with for now.
They fund it cos they want to use it for their thing. Does not mean they own them. They are all community governed projects.
Rust, Julia, Typescript on the other hand are governed by Corps. They are not community projects.
Elixir is BDFL (good one) last I checked. Dont know if they became a company or foundation.
Zig is for all purposes a good example of community governed project. Itcs in production at Bun and TigerBeetle. But also, its not yet production ready (v1.0). So their current trend make sense.
But I could've been wrong with JS and C. Not sure about their governance now that I think about it.
This is patently wrong on at least several of these.
Rust is explicitly a community project having been born out of a non-profit, and if you’re discounting corp-funded but community driven that’s definitely Rust. If not, please indicate the corp that’s driving Rust.
Zig is a BDFL project like Python was (not sure how it is these days) - community contributes sure, but Andrew makes the big calls and directional changes.
> Rust is explicitly a community project having been born out of a non-profit, and if you’re discounting corp-funded but community driven that’s definitely Rust. If not, please indicate the corp that’s driving Rust.
Non-profit doesn't mean community project. Rust foundation is a non-profit 501-c(6). Which is a non-profit category for trade unions and stuff. It's not a charity categorization. It's run by corporate members and works only for the members which are - surprise corporates. A community member like you or me doesn't have any say (Unless you have $325k per year to pay) - https://rustfoundation.org/get-involved/. This is the same case with Linux foundation as well. It's NOT a community project. The only difference is, Linus has more say cos trademark is on him.
PSF and Zig foundation are charity / commuinty projects cos they are non-profit 501 c(3). It's categorised as public charity or for the good of people. You and I can have more say in it. NOT THE CASE WITH RUST.
>Which language would you classify as not corp owned?
I would like to respectfully disagree with you there as well.
The above was the context. I was replying to this which opened the conversation.
Not to mention, end users and consumers don't get a say in the corp funded projects. Everything works as long as it aligns with the goals of the corp. Not otherwise.
I’ve been in the Apple ecosystem in one form or the other 40 years and that’s definitely not true compared to Microsoft.
Most recently they dropped support for 32 bit Mac and iOS apps. But before that it was dropping support for PPC apps and 68K apps.
On the hardware side, the funniest was they dropped support for my Core 2 Duo Mac Mini and I could still install a supported version of Windows 7 on it.
There are 10 different answers for how to take a substring by index+len, depending on which version of Swift. They even changed how arrays as function parameters work between versions.
Not viable to stay on an old version, especially doing iPhone dev. The real answer back in the Swift 1-4 times was to just use ObjC instead, it still had full support.
Arc browser famously had native parts of the UI done in Swift, which admittedly is not a lot: browser tabs, some popups and buttons here and there, a lot of their settings UI is rendered in HTML and is stock Chromium. Which is probably why they actually made a port of it to run on Windows rather than rewriting it into something like Qt or WPF or whatever.
Ladybird browser team planned to start using Swift in their codebase, but it hasn't happen yet.
Chicken/egg, I think. There was a burst of activity of Swift on the server a few years ago and frameworks like Vapor seem like they’re still pretty active:
But I think “why” remains a valid question when you could make a safe pick like Node, Python etc. I really like Swift as a language but I’d still struggle to justify using it outside of iOS.
Don't know of large organizations using it in production, the vibe I get is that it's useful for an iOS developer who wants to deploy a small server for their product without learning Python or Javascript.
You could certainly use it at larger scale, but you have to justify giving up the big ecosystems of its competitors.
Sadly this project is getting steadily slower. Adopting async made it slower than Django. But this is due to Swift limitations. Hopefully Swift replaces Codable and improves async performance.
Swift is absolutely not a peer to Rust. Even without GC, Swift comes with a substantial runtime to enable a lot of features that precludes such a comparison like everything to do with messages and actors. With regards to safety, Swift's data isolation system is cute, but isn't comparable to a substructural type system at all, and it's useless if you're not writing code that uses actors.
Most of what makes Rust's safety powerful is that lifetime analysis is universal and highly granular. Things like no dangling references to local variables, no 'collection cycles', handling parametric code, etc. are basic features that Swift can't provide. On top of it all, the whole system is ruinously complicated compared to Rust's type system. That's the sad reality of what happens when you try to implement something so fundamental as an extra bolt-on to a language that can't properly accomidate it.
On the other hand, Swift has a more gentle learning curve with plenty of progressive disclosure (many features aren't strictly required to build something useful) and generally more approachable syntax.
Swift is also more conducive to "old style" retain mode imperative UI frameworks like AppKit (sometimes declarative and/or immediate mode doesn't fit the bill), which has to date been a major weak point for Rust.
For what it's worth, I'm not an active user (or fan) of Rust. I've just used a lot of languages, it's a hobby of mine to learn new tools.
> a more gentle learning curve ... and generally more approachable syntax.
This is all the more reason it's not a peer. The heavyweight class Rust belongs to (which includes things like Sepples, ATS, Ada/SPARK, D) are as a rule not approachable things. All of them are serious industrial tools whose target audience are experienced professionals that prioritize extremely broad functionality and flexibility in output. What the input looks like, or the cost of learning to operate these tools is not even a consideration for this audience. Swift doesn't fit this bill. It simply compromises too much for things that this class of language isn't concerned with. People reaching for a new language in this class aren't thinking about how easy it is to learn, or even how nice it is to use. Rust abandoned ML-family syntax to babyduck C++ at massive cost to its "niceness".
On syntax, do you mean semantics? Syntactically they're both generic curly-brace algol stuff with minor differences at best. Semantically Rust is certainly more complicated.
> which has to date been a major weak point for Rust.
It's very ironic, given Rust's original purpose was to replace C++ as the implementation language for Firefox. Retained mode GUIs have unfortunately fallen by the wayside due to a number of factors, it's not just unique to Rust. If a language hasn't inherited a legacy retained mode lib, it's not likely it'll get a decent one unless it's really lucky. Unfortunate, because you're right, retained mode GUIs absolutely have their upsides and web browsers aren't a solid replacement. They're just complicated to implement, and computers are fast enough now that the much simpler immediate mode paradigm is the choice for every new framework being written. It is what it is.
Swift concurrency used to be a bit rough around the edges, but since Swift 5.5 it uses async/await and structured concurrency, which has been a massive improvement. We also have built in ways to handle data races around mutable state with actors and the main thread with @MainActor.
Rust has a more explicit and strict approach to ownership/borrowing for sure, but I’d argue Swift has worked to be memory safe be default since the start, with ARC, no unchecked pointer arithmetic in normal code, etc. it’s still tightly coupled to Apple platforms, but the swiftlang teams has been hard at work changing that and I think it’s a fine language to start new projects with in 2025.
I guess so. In a way it makes sense if you can share your code base between the iOS/MacOS app and your backend. It makes development easier. But I guess that the majority of apps is not running MacOS servers for the backend. So far it's probably some node backends and all going JSON inbetween. But for some dedicated apps without a web portal inbetween it might be easier if app and backend are both in Swift.
> …and the build system is not on the same level of Gradle or similar.
Worth noting that Gradle's long list of capabilities can sometimes be as much of a liability (or at least a frustration) as it is a boon. A great many projects don't need even a fifth of its complexity.
My encounters with Gradle have mainly been through Android development, so the example that springs to mind is how much of a pain in can be to get a project that's been sitting for a while patched up.
Basically, as a result of dependencies working only with certain versions of Gradle, it's very easy for an project with moderate to high complexity to wind up in a huge tangled mess when updating anything — updating Gradle might require you to update your dependencies, but all your dependencies might not support the version of Gradle you updated to, and the errors that get thrown as a result will be generic and won't tell you as much, sending you on a goose chase. This chain of events can also be set off by upgrading a single library for some feature you need.
It also makes it a pain to read others' Gradle files since there's no agreed upon standard, with everybody doing it a little bit differently.
In contrast, in the several years after switching my Apple platform projects to Swift Package Manager and away from CocoaPods, it's been rare for either toolchain or library upgrades to cause any sort of problem, and broadly speaking there's only a single correct way to write Swift package files, which makes them easier to read and work on.
Yes, because Apple gave up on the server market, so that demography usually uses Linux based servers and does code sharing between backend and their iDevices apps.
Not true at all. Swift is a very capable backend language, Apple has open sourced a lot of great libraries to power server software development, and there are projects like Vapor [0] that are used in production.
Ah. You're right, I phrased that ambiguously, sorry.
I meant to point out that there is no apple native cloud solution where you can run swift on apple hardware.
So if your iOS app needs to talk to a backend that you want to develop and host, you need to run that backend on an OS with cloud support, like Linux, some other Unix or windows. But not macOS or some other "Apple cloud" hosting.
For reasons stated above, you might in that case choose Swift.
Ah, gotcha—yes, that is actually a pain point and a strange omission. If you need to run backend code for any reason to support your app, Apple literally offers nothing.
IBM at one point offered Swift "serverless" lambdas/cloud functions, which made me briefly hopeful that Apple could do the same, but that service was deprecated years ago, and Apple has shown no motion there.
SwiftUI is build upon Apple's frameworks like Metal, CoreGraphics, CoreAnimation, and UIKit / AppKit. If someone want's to make a version for another platform, they will have a whole lot of work to do. That is the real show stopper, and not the core SwiftUI features like many were led to believe
Prediction: the only remaining providers of AI-assisted tools in a few years will be the LLM companies themselves (think claude code, codex, gemini, future xai/Alibaba/etc.), via CLIs + integrations such as ASP.
There is very little value that a company that has to support multiple different providers, such as Cursor, can offer on top of tailored agents (and "unlimited" subscription models) by LLM providers.
If you look at even the Claude/OpenAI chat UIs, they kind of suck. Not sure why you think someone else can't/won't do it better. Yes, the big players will copy what they can, but they also need to chase insane growth and getting every human on earth paying for an LLM subscription.
A tool that is good for everyone is great for no one.
Also, I think we're seeing the limits on "value" of a chat interface already. Now they're all chasing developers since there's a real potential to improve productivity (or sadly cut-costs) there. But even that is proving difficult.
I recently started using Codex (OpenAI's Claude Code) and it has a VSCode extension that works like a charm. I tried out Windsurf a while ago. And the Codex extension simply does everything that Windsurf did. I guess it doesn't show changes at well, (it shows diffs in it's own window instead of in the file), but I can just check a git diff graphically (current state vs. HEAD) if I really wanted that.
I am really tempted to buy ChatGPT Pro, and probably would have if I lived in a richer country (unfortunetley purchase power parity doesn't equalize for tech products). The problem with Windsurf (and presumably Cursor and others) is that you buy the IDE subscription and then still have to worry about usage costs. With Codex/Claude Code etc., yeah, it's expensive, but, as long as you're within the usage limits, which are hopefully reasonable for the most expensive prices, you don't have to worry about it. AND you get the web and phone apps with GPT 5 Pro, etc.
I don't know. Foundation models are very good, and you can get a surprising amount of mileage from them by using them with low level interfaces. But personally I think companies building development tools of the future will use LLMs to build systems with increasing capabilities. I think a lot of engineering challenges remain in scaling LLM's to take over day to day in programming, and the current tools are scratching the surface of what's possible when you combine LLMs with traditional systems engineering.
I read that the source won't be made available because it contains some anti-spam (anti-abuse?) measures that would be easily circumvented if the source were open. Security through obscurity is famously no security at all, but I can see how it can reduce the noise that dang has to deal with a bit.
reply