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

31–40 of 341 posts

Re: Several core problems with Rust

#31

Post by nicce »

singularity2001 wrote: post #17
IshKebab wrote: post #5

Totally wrong. > Its compilation is slow. I mean SLOW. Slower than C++. No way. Maybe Rust 1.0, but it's steadily improved and it's definitely faster than C++ now. > It’s complex. Just as complex as C++. True, but the problem with C++'s complexity is that you have to memorise all of it or you'll accidentally invoke UB. It's so complex that is basically impossible. Rust is complex but most of the time the compiler wil…

> I would love to hear what he thinks a good programming language is not OP, but outside of extreme performance critical software I MUCH prefer Swift, C# or python.

C# is really good, but is Swift good enough as true general-purpose language for every platform and OS?

Re: Several core problems with Rust

#33

Post by GaggiX »

tptacek wrote: post #21
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…

It's easy to cause memory corruption with Go while building a concurrent system, you don't need to learn anything about "defeating the language".

Re: Several core problems with Rust

#34

Post by cratermoon »

"they only corrupt user data and act sporadically"

The author dismisses these defects, but try telling a financial institution that it's "only" corrupt user data when the books don't balance. Explain to an aerospace company that acting sporadically is just fine.

Re: Several core problems with Rust

#35

Post by piskov »

IshKebab wrote: post #5

Totally wrong. > Its compilation is slow. I mean SLOW. Slower than C++. No way. Maybe Rust 1.0, but it's steadily improved and it's definitely faster than C++ now. > It’s complex. Just as complex as C++. True, but the problem with C++'s complexity is that you have to memorise all of it or you'll accidentally invoke UB. It's so complex that is basically impossible. Rust is complex but most of the time the compiler wil…

Modern c# is very nice. And can be fast too

Re: Several core problems with Rust

#36

Post by EnPissant »

tptacek wrote: post #23
deadbabe wrote: post #16

Earlier quoted context omitted.

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.

I 100% think LLMs were involved in its production, just not written wholesale.

Re: Several core problems with Rust

#38

Post by cogman10 »

Mutable shared state is a feature, not a bug.

It's true that it's easier to write correct async code using immutable shared data or unshared data.

However, it's very hard if not impossible to do fast and low memory concurrent algorithms without mutable shared state.

Re: Several core problems with Rust

#39

Post by preommr »

claudiug wrote: post #27
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.

crtystal and nim, probably not.

Zig... is surprisngly used a lot given how rough the state of the language is. It makes me think that if it ever reaches v1.0, it has a very good chance of being at least a "Kotlin", probably a "elixir"/"haskell", and a decent enough shot of "typescript".

Re: Several core problems with Rust

#40

Post by cwillu »

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.

“Summary:

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, just because you can pick it from the shelf and employ as-is. This blog was generated with Zola, written in Rust — I did not have to write a single line of Rust code to use it. And the Rust is a good fit for Zola SSG because of its non-interactive nature with one-way flow of immutable data. Just, please, don’t run around screaming “we should all switch our development to Rust because it’s the best programming language”.”

Is this what makes someone a Rust hater?

Post reply on HN