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

91–100 of 341 posts

Re: Several core problems with Rust

#91

Post by josephg »

byko3y wrote: post #81
yoyohello13 wrote: post #51

Earlier quoted context omitted.

Literally hates on Rust for the whole article except the final summary.

Man, I explained it in the first sentence of the article — it's not bad, it's much worse than it could have been. The main body of the article is not hate — it's plain facts. Everybody working on a significant Rust codebase agrees that Rust compilation takes eternity. Complexity? I know people that like complexity, they would say "that's a great language because of how hard it is to write a program in it!" — complexi…

> The main body of the article is not hate — it's plain facts. Everybody working on a significant Rust codebase agrees ...

Lol. Its not facts. Its a description of frustrating things you've experienced working with rust, dressed up as "deep truths about the language". You don't speak for the rust community. This article would be much more interesting if you just talked about your own experience without pretending your issues are universal.

Re: compilation time, in the 2024 state of rust survey 25% of rust developers said slow builds was a big problem. And thats a lot of people! But 19% of people said its not a problem at all for them. Its certainly not "everyone".

https://blog.rust-lang.org/2025/02/13/2024-State-Of-Rust-Sur...

I suspect if you keep using rust, the things that annoy you about the language will change a lot over time. Some things will stop bothering you, and some things will start bothering you a lot more! (Like IMO Rc/Box/etc isn't a big deal. Once you learn to structure your code in a rusty way, you almost never need that stuff.)

I really like rust now. But I found learning rust to be incredibly painful. I get why you're struggling with it. But please don't confuse your struggle for universal truths about rust. You're only one person.

Re: Several core problems with Rust

#92

Post by kstrauser »

byko3y wrote: post #26
deadbabe wrote: post #16

Earlier quoted context omitted.

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.

I disagreed with your article, but this critique of it is just goofy. I also write in Markdown, use lists where appropriate, and — gasp! — write em dashes where appropriate.

Re: Several core problems with Rust

#93

Post by EnPissant »

byko3y wrote: post #90
josephg wrote: post #67

Earlier quoted context omitted.

A couple years ago I implemented a btree (technically order statistic tree) in a couple thousand lines of unsafe rust for a project. I wrote it more or less how I'd do it in C. Each internal node and leaf node was a separate heap allocation and internal nodes had an array of child pointers. It was surprisingly hard to program up. And complicated! In my opinion, unsafe rust code is worse to use than C because rust is…

>Eventually I rewrote my btree on top of Vecs. My node & leaf pointers are now array indices. The result? There is no longer any unsafe code. The code has become significantly simpler and it now runs ~10% faster than it did before, which is shocking to me. I guess bounds checks are cheaper than memory fragmentation on modern computers. Optimizations are very complex and potentially fragile in Rust, LLVM has to sort t…

> Do note that binary trees are mostly an obsolete legacy today — they are way too cache-unfriendly

BTree is not Binary Tree. It's B-Tree and is cache-friendly

> C++20 with concepts mostly reproduce the traits.

C++20 concepts are not the same as traits. Concepts are structural and awkward to use compared to Traits which are nominal. There are other important differences, too.

Re: Several core problems with Rust

#94

Post by byko3y »

EnPissant wrote: post #55
paulddraper wrote: post #7

Earlier quoted context omitted.

Why do you think that?

The ragebait part is because it feels more provocative than sincere. Some examples from the introduction: > Its compilation is slow. I mean SLOW. Slower than C++. I know over years Rust became several times faster, but objectively we need it to be two orders of magnitude faster, not just two times. I've done significant C++ and Rust and Rust compiles WAY faster than C++ for day-to-day incremental compilation. C++ suf…

>I've done significant C++ and Rust and Rust compiles WAY faster than C++ for day-to-day incremental compilation. C++ suffers from the header inclusion problem and modules may as well not exist because you can't practically use them.

It really depends on what you are compiling. I did lots of C/C++ that compiled 50k lines of code in 10 seconds FROM SCRATCH — I doubt you can do it in Rust. To be fair, headers in that project were somewhat optimized for compilation speed (not "hardcore", but "somewhat"). People forgot how fast C/C++ compilation can be without 10 Boost includes in each module.

>This is intentionally over complicated, there is no reason for the Box to be there.

Arc>> — sounds good now? Don't get me wrong — C++ can be just as horrible, but Rust made it a rule, you can only write your program like this.

>What does this even mean?

I've already answered above, but I can repeat: there are runtime models that allow crash and recover, there are models that crash and limp. In Rust there is only one model of crash: you just crash.

Re: Several core problems with Rust

#95

Post by tptacek »

mirashii wrote: post #61
GaggiX wrote: post #33

Earlier quoted context omitted.

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

I agree, and I personally wouldn't call golang memory safe for that reason. Thomas's semi-definition includes the word "vulnerability", which narrows the scope so much that golang fits under the bar, since the common data race that causes memory corruption hasn't been shown to be exploitable without being contrived. My personal definition of memory safety for a language like golang would specify that you can't cause…

The same thing happens any time a message board confronts a professional term of art. The same thing happened with "zero trust", where you'd have long wooly debates about what was meant by "trust", but really the term just meant not having a conventional perimeter network architecture. Sorry, but the term as used in industry, by the ISRG, and in government guidance refers specifically to vulnerabilities.

Re: Several core problems with Rust

#96

Post by tptacek »

benjiro wrote: post #73
tptacek wrote: post #56

Earlier quoted context omitted.

"Memory corruption vulnerabilities" != "concurrency bugs" or even data corruption. The last thread I was in about this, someone pointed to Go segfaults and said "see! memory corruption!" (obviously: no). An easy response to claims like this: there's a huge tower of software written Go at this point, including the entire K8s ecosystem. Show me the memory corruption exploits.

The amount of Rust code using unsafe is a major issues for a language build around safety. And yes, the same argument can also be made about Go having a unsafe keyword. The fact that there exist crates to detected the usage of unsafe in dependencies, shows that its a rather liberal used keyword. Geiger comes to mind. Unsafe in a language like Go is very rare, mostly because people do not program at such low system le…

It's got really not much at all to do with `unsafe`.

Re: Several core problems with Rust

#97

Post by byko3y »

EnPissant wrote: post #36
tptacek wrote: post #23

Earlier quoted context omitted.

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.

It's 200% LLM used in production — like 10 hours of dialogs right before writing the article. I had much more hours of coversations with Rust fanboys and it was mostly a waste of time, they just would not try to negotiate on Rust's weak points. I would definitely not be able to write the article with only human support — it's really sad to conclude that LLM-s are much better assistants because they are neutral and objective.

Re: Several core problems with Rust

#99

Post by josephg »

byko3y wrote: post #90
josephg wrote: post #67

Earlier quoted context omitted.

A couple years ago I implemented a btree (technically order statistic tree) in a couple thousand lines of unsafe rust for a project. I wrote it more or less how I'd do it in C. Each internal node and leaf node was a separate heap allocation and internal nodes had an array of child pointers. It was surprisingly hard to program up. And complicated! In my opinion, unsafe rust code is worse to use than C because rust is…

>Eventually I rewrote my btree on top of Vecs. My node & leaf pointers are now array indices. The result? There is no longer any unsafe code. The code has become significantly simpler and it now runs ~10% faster than it did before, which is shocking to me. I guess bounds checks are cheaper than memory fragmentation on modern computers. Optimizations are very complex and potentially fragile in Rust, LLVM has to sort t…

> Do note that binary trees are mostly an obsolete legacy today — they are way too cache-unfriendly. I mean you could have written similar code in C++ using std::vector or std::dequeue and get the bounds checking too.

As a sibling comment said, its a b-tree not a binary tree. B-trees are - as far as I know - the fastest data structure on modern computers for the class of problems they solve.

And yes, I think if I ever go back to C/C++ I'll try this approach out. It might also work great in GC languages like JS/TS/C#/Go because there's fewer pointers to keep track of.

> Cargo is good for as long as there are few packages in there. Large projects already suffer from five versions of serde in one build and dependencies on FFI-connected libs that cargo itself cannot build. I mean look at the NPM nightmare — and they've mostly dodged FFI-s.

I haven't run into the "five versions of serde" problem, but I can easily imagine it. I've lived NPM nightmares more times than I can count. But I'd still prefer that to all the problems you get from CMake, autotools and Makefiles. At this rate we're going to get self driving cars before we have a single sane build system for C.

Re: Several core problems with Rust

#100

Post by aw1621107 »

byko3y wrote: post #94
EnPissant wrote: post #55

Earlier quoted context omitted.

The ragebait part is because it feels more provocative than sincere. Some examples from the introduction: > Its compilation is slow. I mean SLOW. Slower than C++. I know over years Rust became several times faster, but objectively we need it to be two orders of magnitude faster, not just two times. I've done significant C++ and Rust and Rust compiles WAY faster than C++ for day-to-day incremental compilation. C++ suf…

>I've done significant C++ and Rust and Rust compiles WAY faster than C++ for day-to-day incremental compilation. C++ suffers from the header inclusion problem and modules may as well not exist because you can't practically use them. It really depends on what you are compiling. I did lots of C/C++ that compiled 50k lines of code in 10 seconds FROM SCRATCH — I doubt you can do it in Rust. To be fair, headers in that p…

> I doubt you can do it in Rust.

You absolutely can. You'll need to pay attention to how things are structured and not all codebases will be equally amenable to such techniques, but those are shared characteristics with C++.

As you said, "It really depends on what you are compiling."

> In Rust there is only one model of crash: you just crash.

Hardly. Why else would catch_unwind exist?

Post reply on HN