Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Several core problems with Rust

bykozy.me

Post reply on HN
Print view View original

21–30 of 341 posts

Re: Several core problems with Rust

#21

Post by tptacek »

cetra3 wrote: post #14

> Node.js and Go are considered practically safe language Node JS has had vulnerabilities in the past: https://www.cvedetails.com/cve/CVE-2021-22940/ Go is also not Memory safe: https://www.ralfj.de/blog/2025/07/24/memory-safety.html

Node.js and Go are both memory safe, as are Python, Ruby, and Java. "Memory safe" is a term of art referring to susceptibility to memory corruption vulnerabilities in code written by an ordinary practitioner of the language. Almost invariably, attempts to show languages like Go and Python as memory-unsafe involve a programmer deliberately working to defeat the language. But you can do that in any language, including Rust.

There are essentially just two mainstream memory-unsafe languages: C and C++.

Re: Several core problems with Rust

#23

Post by tptacek »

deadbabe wrote: post #16
paulddraper wrote: post #7

Earlier quoted context omitted.

Why do you think that?

lists, em dashes, headings and typical length of LLM response.

You think an AI wrote "So, is the Rust bad or good? It’s neither. It’s a mediocre programming language with thousands of man-month put into its development — this fact alone makes Rust a viable tool"? No it didn't.

Re: Several core problems with Rust

#24

Post by themgt »

You cannot go along like “I’m writing a cold path high-level code, I don’t need performance, I don’t need to go deeper into lifetime handling, I just want to write a high level logic”. You will be forced into the low level nuances every time you write a single line of Rust. There is no garbage collector for Rust and will never be — you will have to semi-manually pack all your data into a tree of ownership. You have to be fluent in ownership, borrowing, traits to write just a few lines of code.

It's still quite rough around the edges, but Crystal is a fun choice for this type of thing. If you want a readable high level language and sane package manager that compiles to reasonably performant machine code, it's worth a look.

Re: Several core problems with Rust

#25

Post by nicce »

gr4vityWall wrote: post #9

The author would probably find joy in using Zig. Personally my biggest complain from Rust is that I wish it was more readable. I've seen function signatures that seemed straight out of C++.

> Personally my biggest complain from Rust is that I wish it was more readable. I've seen function signatures that seemed straight out of C++.

There is always a trade-off. You really cannot provide enough information for the compiler without the current signatures. There is a certain point where you cannot compress the information without losing some features.

Re: Several core problems with Rust

#26

Post by byko3y »

deadbabe wrote: post #16
paulddraper wrote: post #7

Earlier quoted context omitted.

Why do you think that?

lists, em dashes, headings and typical length of LLM response.

Yeah, the article was written in Markdown, LLM-s employ markdown formatting too. It's not a typical length of LLM response — it's approx 1.5-2.0 times longer than a typical long LLM response. Not easily noticable to a human being though, indeed.

Re: Several core problems with Rust

#27

Post by claudiug »

themgt wrote: post #24

You cannot go along like “I’m writing a cold path high-level code, I don’t need performance, I don’t need to go deeper into lifetime handling, I just want to write a high level logic”. You will be forced into the low level nuances every time you write a single line of Rust. There is no garbage collector for Rust and will never be — you will have to semi-manually pack all your data into a tree of ownership. You have t…

the issues with Crystal, nim, zig, is that they have zero changes to be bigger.

Re: Several core problems with Rust

#29

Post by bccdee »

> telling a victim “but the memory was not corrupted in the crash” is a weak consolation. We actually had a recent Cloudflare outage caused by a crash on unwrap() function. It’s probably the strongest point of my whining: Rust is memory safe and unreliable. The price of memory safety was reliability

This is incorrect in a way that honestly feels insulting. It's not the language's fault that you called the `crash()` function—every language has a way to terminate execution, and for good reason. Crashing isn't even necessarily incorrect behaviour; that's how you pass the error up to the infrastructure layer for handling. The problem here existed at a system design level, not a language level.

For the author to paraphrase this (bad) critique like this:

> You cannot get 99.999% reliability with Rust — it crashes all the time.

is outright dishonest and insulting to me as a reader.

Re: Several core problems with Rust

#30

Post by ozim »

edoceo wrote: post #8
yoyohello13 wrote: post #3

I think we’ve officially reached the inflection point where the Rust haters have become more annoying than the Rust evangelists. Maybe in a couple years we will finally be able to stop writing blog post about it.

Not to worry, another tech thing will be along shortly to fill the hype/hate cycle with its own drivel.

Unfortunately there are topics that should stop long ago but people still rave about those: ORMs, OOP, Git, JavaScript bloat, Linux vs Windows.

Somehow there are always fresh people who think someone cares or that somehow those are important discussions.

Post reply on HN