I don't get how Ive is getting so much praise as a designer, after designing the worst iPhones ever and a Ferrari that looks like a Toyota Prius on steroids.
Corporations are afraid of taking chance, and Ives have been elevated to this design guru for his work at Apple. This is despite the fact that he clearly had some terrible designes approved at Apple, but no on had the balls or status to tell him to go back to the studio and make an actual good design.
Ives also had a ton of really excellent and classic designs, but maybe the world needs to stop pretending that everything that man touches is instant classics and best in class. Maybe consumer electronics design doesn't translate well into other fields. I still think it due to companies refusal to take risk, and in some cases, like with OpenAI, wanting to get some association with Apple. Better hire Ives, because then no one can critic the design, because everyone know that Ives is the world greatest designer.
For Ferrari I don't get it. They already have good designers and I think their customers would prefer an EV that looks like a Ferrari, not a Ferrari that looks like Mac.
The exterior looks like a sad compromise between aerodynamics and design. Though the white version looks least plasticky. That weird bumper looks like the consequence of getting a lower drag coefficient.
I think that this just emphasizes how much Ive needed Jobs as a constraint. The early stuff they did together was genuinely good and changed the industry for the better. But his later work after Jobs got sick seemed significantly worse. Definitely a relationship that needed both sides.
Couldn't agree more. Jobs' advice to say no to a hundred things sounds easy in a vacuum, but to actually go against the powerful people around you and gatekeep the quality and essence of your business over decades is incredibly hard, foolish and brave.
I have a lot of issues with the Ive era and the Mac... but every iPhone he designed was a banger. I think the 12-14 era is the only era of iPhones I thought were bad and that was after him.
I suppose the iPhone 6 was bendable but that was a hardware engineering issue as shown by the same form factor not being bendable for the 6s through 8.
How can this make any sense when he designed every iPhone until 2019? None of which would have existed without his original design and all of which remain relatively close to that original design.
One of the perks of designing for cultist brands. Like, Apple could ship the next iPhone looking like the most ugly phone ever, and they will still make boatloads of money from their devoted followers. Same goes for Ferrari. If you want to find actually good designers instead of these celebrity designers, watch out for designs that don't have a cult-like following yet.
If you get every iPhone ever released, in black or black-adjacent, and lay them camera-side down and off, it would be difficult to line them up in the correct order.
Not much has really changed with them, and I'm not sure much really can.
I understand the need for memory footprint in some situations, but what's the point of seeking performance for a software that mostly calls LLMs and waits?
Before I tried coding agents my guess would have been: none.
But seeing how slow claude code and copilot cli are and how much ram they use I'm flabbergasted. If you have long running sessions they can both take tens pf gigabytes of ram and feel quite sluggish.
huh. my evidence with codex hasn’t been so bad. and tbh why would i discourage anyone from coding. hack away mr hacker. your solution will either sink or swim
The appetite for Rust is the appetite for higher guardrails. Automatic memory management in safe Rust makes it less likely your app bloats even as its source balloons.
The people "writing" agents are not themselves experts in how to write performant code. Claude Code is so massive and ugly it can only be realistically maintained by continuing to throw LLMs at it. But that's not a replacement for good software design.
I've been playing with running Claude Code inside a Vagrant VM. I can't be certain it was getting OOM killed when I allowed the VM 4GB of RAM, but when I went to 16 it did seem to be more stable...
> I can't be certain it was getting OOM killed when I allowed the VM 4GB of RAM
Of it's actually getting OOMed (and not backing off by itself), I'm pretty sure that's logged in dmesg. Or earlyoom or systemd-oomd if userspace is in play and getting there first.
I see spreading Rust as an overall good thing, because it changes benchmark on how software should feel in terms of performance, stability, memory footprint.
So even if it doesn't create tangible advantage in a particular use case - its still good for the whole industry.
Edit: I lost the context that this is about building devtools where you can’t just throw more hardware at the problem. But perhaps my answer still explains the reality: anthropic builds Claude with Claude so Claude needs to be easy to build with Claude.
Easier to read for humans is easy to read for LLMs. A more expressive language will bring about fewer misunderstandings when you apply stochastic tools like LLMs.
Just be sure you don’t choose something heavier/slower that is not more expressive.
Ada? Other than c and c++ everything else benchmarks 2-4 times slower than rust for compute bound tasks, even after jit warmup. I'm up for ada though, especially with an llm where I don't have to type all that verbose syntax.
I'm not against jit or warmup, just saying it doesn't actually catch up for compute bound tasks in my experience. Haskell and ocaml would definitely be next on my list, but they do take a very good hit in performance over ada or rust. I wouldn't say they were similar in performance, certainly. There is a pretty big cliff between the systems languages and everything else performance-wise. For a lot of things it doesn't matter I know, but none of those things are domains I've ever worked in. I've never had a project in my professional career where we didn't descope requirements to fit the available compute.
Since when is Rust a systems programming language? On their website it is defined as "general-purpose programming language".
>Approaching every problem as a systems programming problem is a massive waste of resources and intellect.
If someone took their time and decided to use Rust maybe their first couple projects won't be as efficient, but they will learn the language and how to use it in the best ways, they will contribute to the ecosystem, etc. Again, I'm looking at the big picture and not specific project case.
I haven't used Rust extensively but my feeling is, if you change the design (which inevitably happens in many early stage projects), the refactoring takes more time due to borrow-checker semantics. Although I am far from a representative sample and could well have been using it wrong
When you write Rust long enough you settle on certain architectures (message passing, event loops) that go well with the borrow checker, and don't end up thinking about it too much. Plus you can always throw an agent at the first set of errors from the refactor and let the compiler guide the annoying parts.
The biggest reason to pass on Go right now (if your software can tolerate a runtime) is the lack of algebraic data types when doing interesting domain modeling. It makes such a huge difference it’s worth tolerating the pain points of Rust (or Swift, or F#) just to have them.
You can tune java runtime in many ways, achieving impressive throughput/latency for your type of workload.
Next to none of them will get you nearly as good cold start times as of native app, if using free java.
There was GraalVM and its ecosystem which included Java Native Image - first thing I’d evaluate if thought about non-server side, performant Java application.
But it all had been sadly swept away by Oracle from free tier.
I use GraalVM and Native Image now and while the project --a small CLI tool-- is tiny (2kLOC with mainly AWS-SDK deps) the compile times are huge (~3 minutes), the OS-dependencies many (so much I use a build container to ease the burden of installing all) and the resulting binary is huge (~60MB).
But then it distributes as one binary and starts in milliseconds.
Rust would have been a better fit (cargo-and-done, smaller binary, quicker to compile); but I wanted to use Kotlin as we use in all other projects.
It hasn't been swept away by Oracle, far from it. It's development is just no longer coupled to the OpenJDK release cycle, which benefits both projects.
What's the latency difference between a long running process issuing a network call in Java vs rust? This is such a short time that it is completely overshadowed by noise (OS doing something else, what other software is running etc)
As for throughput: you have 1-2 requests going at a time, the next one waiting for the reply. What throughput are we talking about?
That's like speeding to the post office and expecting your letter to get to the recipient faster.
you seem to specifically aim at the current example, but mine wasn't
Anyways, consider how higher memory usage can affect the systems performance dramatically once the system needs to start swapping memory to disk signficantly
If you cannot write a simple Java agent without consuming so much RAM that your system is swapping then that really says more about the developer than anything.
Java is used in plenty of embedded systems and other memory constrained environments. Yes, it’s not going to perform well compared with Rust, but that doesn’t mean it’s an Electron-equivalent bloated clusterfuck of an ecosystem that’s going to eat all your system resources.
1) the agent is probably not the only thing running on the system, so more is just worse generally
2) I am fine if a developer needs Rust or similar to write a resource efficient app. I wonder what the developer could achieve when he put the optimization effort into the Rust app instead.
My point is that Java isn’t going to be the application that sends your machine into swap hell.
People are so narrow minded about programming on this forum. They talk as if only Rust fills the void between unsafe C and node.js behemoths. But the reality is there are a plethora of other good languages out there too.
> That's like speeding to the post office and expecting your letter to get to the recipient faster.
I mean, the post office is not a magic box. Actual people will take your letter somewhere, sometimes batching sends. So running to the post office might actually get your letter in an earlier batch, same as ordering on amazon or your online supermarket in the morning or in the evening might change the delivery time.
For the most part, doing things right in the given language matters more than change of language. A lot of refactors in Rust (in the coding agent space) I see jump straight to Rust without considering what inefficiencies can be addressed before changing the language.
Having said that, I considered a Go/Rust rewrite of Dirac (https://github.com/dirac-run/dirac) for some modules to support cases when someone wants to run like 30 agents, but it quickly became obvious that, a) while the node event loop is a bottleneck, it is not the sole bottleneck and b) if you have a VSCode extension, you can't totally get rid of TypeScript, so it just becomes the case of bi-lingual project and the maintenance burden that comes with it
Rust is just another language. Sure it's cooler than some langs, to some ppl. Sure.
The author made the choice. Open sourced it (thanks!). So now we all enjoy more options. Saying author did so because "cool" does not sit well with me. It's feels like you get a no-strings attached gift of significant value and then going saying the giver gave it to be seen as cool.
Opencode can be surprisingly hard on the CPU (could be an issue when coding on battery or a weak remote VM), and uses a lot of RAM. A little competition is always welcome.
Even a simple coding agent TUI should work instantenously, which I sadly cannot say is true about typescript-based applications like Claude Code or Gemini.
After switching away from GNOME Terminal + Zsh to Ghostty + Nushell, I started to appreciate how instant everything feels. Why not make everything just as fast?
I have to say this is one of my favorite things about local Qwen and Qwen code, it seems a heck of a lot faster that Claude and feels better to work with.
Problem is it is nowhere near as smart, so what speed I get in conversation gets killed by iteration.
That's true, but it's not quite the same thing. The single binary you're referring to is the interpreter and source code packaged together (at least for TS/JS).
If you install too many of these "single binaries" then at some point you would be better off just having a single interpreter and using npm/pip.
By contrast the Rust binary only contains the machine code for this program and can be directly executed.
That's exactly the tradeoff I made with Barnum (https://barnum-circus.github.io/). It's just not important to optimize the performance of the rust side for the reason you stated. So instead, all focus goes into making it easy for an LLM to build a reliable pipeline (from which LLMs are invoked).
I recall back in the mid 2000s when i saw many "rewrite in rails" apps. Its just hype, and it will die out in a few years when something new comes out.
I’m working on an ATS system that integrates LLMs for helping the recruiter in writing job descriptions, parsing CVs to Markdown, making summaries of CVs and suggest which ones match the best the job offers giving pluses and minus: https://beehive-ats.com/
Ive just designed not practical thin furniture, like the bending iPhones and the ultra thin MacBooks with no way to release heat and the keyboard that was getting broken after pressing a bit too hard
The beauty of docker is that it is a reflection of how much someone cares about deployments: do you care about being efficient? You can use `scratch` or `X-alpine`. Do you simply not care and just want things to work? Always go for `ubuntu` and you're good to go!
You can have a full and extensive api backend in golang, having a total image size of 5-6MB.
I've done both, tiny scratch based images with a single go binary to full fat ubuntu based things.
What is killing me at the moment is deploying Docker based AI applications.
The CUDA base images come in at several GB to start with, then typically a whole host of python dependencies will be added with things like pytorch adding almost a GB of binaries.
Typically the application code is tiny as it's usually just python, but then you have the ML model itself. These can be many GB too, so you need to decide whether to add it to the image or mount it as a volume, regardless it needs to make it's way onto the deployment target.
I'm currently delivering double digit GB docker images to different parts of my organisation which raises eyebrows. I'm not sure a way around it though, it's less a docker problem and more an AI / CUDA issue.
Docker fits current workflows but I can't help feeling having custom VM images for this type of thing would be more efficient.
Yep, then I have some projects that have pytorch dependencies which use it's own bundled CUDA and non-pytorch dependencies that use a CUDA in the usual system wide include path.
So CUDA gets packaged up in the container twice unless I start building everything from source or messing about with RPATHs!
> You can have a full and extensive api backend in golang, having a total image size of 5-6MB.
So people are building docker "binaries", that depend on docker installed on the host, to run a container inside a container on the host– or even better, on a non-linux host, all of that then runs in a VM on the host... just... to run a golang application that is... already compiled to a binary?
Sure but a Docker setup is more than just running the binary. You have setup configs, env vars, external dependencies, and all executed in the same way.
Of course you can do it directly on the machine but maybe you don't need containers then.
In the same vein: people put stuff within a box, which is then put within another bigger box, inside a metal container, on top on another floating container. Why? Well, for some that's convenient.
Docker / containers are more than just that though. Using it allows your golang process to be isolated and integrated into the rest of your tooling, deployment pipelines, etc.
It's go; that could be trivially done with a script.
Heck, you can even cross compile go code for any architecture to another one (even for different OSes), and docker would be useless there unless docker has mechanisms to bind qemu-$ARCH with containers and binfmt.
I'd argue that having it in a Docker container is much easier to integrate with the rest of many people's infra. On ECS, K8s, or similar? Docker is such an easy layer to slap on and it'll fit in easily in that situation.
Are you running on bare servers? Sure, a Go binary and a script is fine.
Yep, it's using docker as a means of delivery really. Especially in larger organisations this is just the done thing now.
I understand what the OP is saying but not sure they get this context.
If I were working in that world still I might have that single binary, and a script, but I'm old school and would probably make an RPM package and add a systemd unit file and some log rotate configs too!
I'm using Kamal for a Ruby on Rails app on a dedicated server on Hetzner. Works like a charm! Did you find it difficult to deploy a .NET, because of the documentation oriented more towards Rails?
Took a bit of research and trial and error to get to a solution we liked, but as it's just deploying and managing Docker Apps, deploying .NET Docker Apps was ok but a bit of time was spent supporting DB Migrations and litestream and running it from GitHub Actions, we've documented our support for Deploying with Kamal (inc YouTube Guide) at:
Yes, I have been using it and really enjoying it for deploying web apps. So far I have deployed web apps using:
* fastapi (python)
* Django ninja (python)
* ghost cms (node)
The thing that puts me off is its seemingly heavy focus on “web apps”. I have a bunch of services I either use or wrote myself and only a handful have anything to do with the web.
reply