Hacker News Reader

Comment by mapcars | Hacker News Reader

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.

View on HN

No because it means people will use Rust for the wrong reasons.

Systems programming is only a tiny fraction of code out there.

Approaching every problem as a systems programming problem is a massive waste of resources and intellect.

For small to medium projects, an LLM can write functional (if not well crafted) Rust.

Considering how easy this is now, why choose a heavier, slower and less typesafe language?

Could choose a similar weight, similar speed, equal or more typesafe language though :)

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.

OCaml? Haskell? Idris?

Lots of options with no jit or warmup

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.

Ok, so write your app in the garbage collected language, and then tell the LLM to translate it to Rust :)

I find it kind of shocking that Anthropic doesn't see it this way.

Claude Code has whole game engine built into it. God knows why.

Tell us more.

perhaps they refer to Claude code being built on top of a React renderer for terminals, Ink https://github.com/vadimdemedes/ink

and is riddled with timeouts and intervals in useffects

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.

it saves a lot of resources - for instance my devices would probably use less than half of the memory it uses now and I wouldn't hear the fan.

You won't hear the fan because you're still building it.

The resources I was talking about are developers × time.

I am talking about using software - if software is used by many people, that's the more relevant resource usage.

It is a common trend for companies to optimize for visible CapEx at the cost of increased but invisible OpEx for consumers.

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

Its just not a thing to consider and doesn't happen often.

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.

> When you write Rust long enough you settle on certain architectures (message passing, event loops) that go well with the borrow checker

So basically Go?

Go only provides one concurrency paradigm. Rust support many (if not all).

The type system of Go is very weak. I'd say that'd be my main reason to pass on Go, even when the concurrency paradigm fits the project perfectly.

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.

Traits, Enums, and Typestate allow much richer paradigms at much lower cost

How is it any faster than something written in say, Java?

latency and throughput (when with Java the system is crying for more memory while it's chilling in the Rust case)

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.

> so much

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.

I can't put Java into good languages category at least for how it allows null to be everywhere.

Of course, what would be a point of talking about an overly specific statement that has no relevance here?

> 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.

Pedantic, I know, but interesting example.

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.

Reply on news.ycombinator.com