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

My negative views on Rust (2023)

chrisdone.com

Post reply on HN
Print view View original

231–240 of 308 posts

Re: My negative views on Rust (2023)

#231

Post by rascul »

googh wrote: post #212
Ukv wrote: post #198

Earlier quoted context omitted.

I found their comment an interesting contribution to the discussion, pointing to a couple of specific pitfalls in C++. It's not just an empty "C/C++ bad, Rust good", and I don't see why it'd give the impression of an obnoxious community.

I just wrote that as an observation, and I did not mean to offend the parent. Now, let me explain why I felt that way. First and foremost, the phrase "undefined behavior" only applies to C and C++ because the specifications of those languages define it. The statement that Rust has no UB does not make sense because Rust has no specification, and all behavior is defined by the default implementation. For example, C/C++…

> The statement that Rust has no UB does not make sense because Rust has no specification, and all behavior is defined by the default implementation.

It is in the reference.

https://doc.rust-lang.org/reference/behavior-considered-unde...

Re: My negative views on Rust (2023)

#232

Post by seethishat »

jkelleyrtp wrote: post #38

"There are only two kinds of languages: the ones people complain about and the ones nobody uses". --- Glad to see fluffy negative articles about Rust shooting up the first slot of HN in 20 minutes. It means Rust has made finally made it mainstream :) --- The points, addressed, I guess? - Rust has panics, and this is bad: ...okay? Nobody is writing panic handling code, it's not a form of error handling - Rust inserts…

"There are only two kinds of languages: the ones people complain about and the ones nobody uses." This is a famous quote from Bjarne Stroustrup in defense of C++. Source: https://www.stroustrup.com/quotes.html

IMO, it's ironic to see Rust proponents using his quote in defense of Rust (and not crediting him).

Re: My negative views on Rust (2023)

#233

Post by al_potato »

IshKebab wrote: post #184
tptacek wrote: post #46

Earlier quoted context omitted.

He didn't say that at all.

I literally quoted it: > I think that the excellent tooling and dev team for Rust, subsidized by Big Tech, pulls the wool over people’s eyes and convinces them that this is a good language that is simple and worth investing in. There’s danger in that type of thinking. Patronising and wrong.

I think they're squaring "simple" against "millions of dollars of investment." Some other languages are successful without that.

Re: My negative views on Rust (2023)

#234

Post by NoGravitas »

jerf wrote: post #56
VeejayRampay wrote: post #9

Earlier quoted context omitted.

I'm curious what kind of code gets a 45x speedup by going from python to rust and by that I don't mean the rhetorical or bait-style "i'm curious", no, the literal I'm curious, cause I'm trying to find use cases such as that these days and I'm often thwarted by the fact that for anything requiring remotely decent speeds, python most of the time already delegates to C extensions and so any rewrite is not as useful

"I'm often thwarted by the fact that for anything requiring remotely decent speeds, python most of the time already delegates to C extensions and so any rewrite is not as useful" Be sure you verify this is the case for whatever you think it is, though. Pure Python is so much slower than compiled languages (not just Rust) that you don't have to do much percentage-wise in pure Python before you've badly fallen behind i…

It would be interesting to me to look at something written in Python and rewritten in Rust with a 40x speed-up, and then rewrite it in something like C# or Common Lisp, and see what the speed-up is. My gut tells me the Rust implementation would use significantly less memory than the CL one, but be only minimally faster, if at all. But my gut has been known to be unreliable in the past.

Re: My negative views on Rust (2023)

#235

Post by Const-me »

jltsiren wrote: post #209
Const-me wrote: post #194

Earlier quoted context omitted.

> I could get effectively the same performance with containers and move semantics When I’m happy with the level of performance delivered by idiomatic C++ and standard collections, I tend to avoid C++ all together because I also proficient with C# which is even faster to write and debug. But sometimes I want more performance. An example from my day job is a multi-step numerical simulation which needs to handle grids o…

I've been using std::vector with arrays that take up to tens of gigabytes for ~15 years without any real issues. Once the size of the allocation exceeds a few megabytes, any reasonable allocator is going to use an anonymous memory map anyway. And if the array doesn't need to grow, it takes effort to make a standard library vector worse than a manually optimized one. It's just a pointer and two integers, after all.

> it takes effort to make a standard library vector worse than a manually optimized one

A simple use case is a 2D array where rows are padded to be multiples of 32 bytes (size of AVX SIMD vectors, saves a lot of implementation complexity because no need to handle remainders) or 64 bytes (saves a tiny bit of performance when parallelizing, guarantees cache lines aren’t shared between rows).

When element size is not a power of 2, it’s impossible to implement that RAM layout on top of an std::vector

Re: My negative views on Rust (2023)

#236

Post by mrkeen »

brink wrote: post #25
VeejayRampay wrote: post #8

rust is fine, it's a solid mix of performance and expressiveness, it has good constructs and it's gaining traction it's hard to learn so we shall see what kind of niche it can carve for itself, but it's fine

> it's hard to learn And as long as Rust remains popular, this is why we will witness endless complaining about it. Most devs are lazy, and would rather sweep complexity under the rug and pretend it doesn't exist until it becomes a real problem they can't ignore anymore. That's fine. But no need to be so vocal about it. At this point, people whining about Rust is more of a trope than people proselytizing it.

> Most devs are lazy, and would rather sweep complexity under the rug and pretend it doesn't exist until it becomes a real problem they can't ignore anymore.

It's the opposite for me. I would put more effort into Rust, but I'm not going to invest in learning how to write safe rust if my libraries are built on unsafe.

Re: My negative views on Rust (2023)

#237

Post by Ukv »

googh wrote: post #212
Ukv wrote: post #198

Earlier quoted context omitted.

I found their comment an interesting contribution to the discussion, pointing to a couple of specific pitfalls in C++. It's not just an empty "C/C++ bad, Rust good", and I don't see why it'd give the impression of an obnoxious community.

I just wrote that as an observation, and I did not mean to offend the parent. Now, let me explain why I felt that way. First and foremost, the phrase "undefined behavior" only applies to C and C++ because the specifications of those languages define it. The statement that Rust has no UB does not make sense because Rust has no specification, and all behavior is defined by the default implementation. For example, C/C++…

> The statement that Rust has no UB does not make sense because Rust has no specification

I don't think it was claimed that Rust has no UB in this conversation, only IFNDR.

From what I can tell, Rust does document a set of "behavior considered undefined" like using unsafe to access misaligned pointers. For practical concerns ("could code optimization change these semantics?", "is this guaranteed to work the same on future compiler versions?") it seems reasonable to me to call that undefined behavior, and to say that Rust doesn't have much of it.

> I see the parent commenter doing this frequently and sometimes[1] even in the C++ subreddit (of all the places!). How is this not obnoxious?

Both their comment here and their reddit comment look fine to me. Something like "C++ sucks, switch to Rust!" would be annoying, but specific relevant technical comparisons ("In Rust for comparison the static growable array V isn't dropped when the main thread exits [...]") seem constructive.

> Rust requires unsafe to do a lot of things which can be done in safe code in a GC'd language. Thus, unsafe is pretty common in Rust than most GC'd languages. If a segfault can literally kill a person, it is absolutely immoral to choose Rust over Java (it does not matter that Rust "feels" safer than Java).

Java does technically have the Unsafe class for low-level unsafe operation and JNI to interoperate with C/C++/assembly.

I'd expect that the average Rust program makes more use of unsafe, but largely just because the average Rust program is lower-level (including, increasingly, parts of the Linux and Windows kernels). It's unclear to me whether the same program written in Java or Rust would ultimately prevent more bugs.

Re: My negative views on Rust (2023)

#238

Post by tialaramex »

googh wrote: post #212
Ukv wrote: post #198

Earlier quoted context omitted.

I found their comment an interesting contribution to the discussion, pointing to a couple of specific pitfalls in C++. It's not just an empty "C/C++ bad, Rust good", and I don't see why it'd give the impression of an obnoxious community.

I just wrote that as an observation, and I did not mean to offend the parent. Now, let me explain why I felt that way. First and foremost, the phrase "undefined behavior" only applies to C and C++ because the specifications of those languages define it. The statement that Rust has no UB does not make sense because Rust has no specification, and all behavior is defined by the default implementation. For example, C/C++…

I really am interested in what Safer C++ proposes for [1], but I never found out.

Your point [4] is very silly because you're assuming that while the unsafe code implementing a safe Rust interface might be flawed the code implementing a safe Java interface such as its garbage collector (which will often be C++) cannot be. As we'd expect, both these components are occasionally defective, having been made by error prone humans, such flaws are neither impossible nor common in either system. There are indeed even safer choices, and I've recommended them - but they're not Garbage Collected.

> First and foremost, the phrase "undefined behavior" only applies to C and C++ because the specifications of those languages define it.

Nope, those words have an ordinary meaning and are indeed used by Rust's own documentation, for example the Rustonomicon says at one point early on, "No matter what, Safe Rust can't cause Undefined Behavior". The purpose there is definitional, it's not a boast about how awesome Rust is, it's a claim that if there is Undefined Behaviour that's not because of the safe Rust, there's a soundness problem somewhere else.

> Another example: signed overflow being UB is not a memory safety problem unless the value is used for array indexing

This is wrong. Because Signed Overflow is UB the C++ compiler is allowed to just assume it will never happen, regardless of the systemic consequences. What that means is that other IR transformations will always be legal even if they wouldn't have been legal for any possible result of the overflow. This can and does destroy memory safety. Actually it would be weird if somehow the IR transformations always preserved memory safety, something they know nothing about, despite changing what the code does.

Re: My negative views on Rust (2023)

#239

Post by dartos »

hyperbrainer wrote: post #48
jkelleyrtp wrote: post #38

"There are only two kinds of languages: the ones people complain about and the ones nobody uses". --- Glad to see fluffy negative articles about Rust shooting up the first slot of HN in 20 minutes. It means Rust has made finally made it mainstream :) --- The points, addressed, I guess? - Rust has panics, and this is bad: ...okay? Nobody is writing panic handling code, it's not a form of error handling - Rust inserts…

> Rust is as complex as C++: ...no, it's not. Maybe not yet, but it is heading in that direction; and I only say this because of the absolutely giant pile of features in unstable that seem to be stuck there, but I hope will eventually make its way to stable at some point. > Async Rust really is fine I dunno. Always thought it was too complicated, but as another person pointed out avoiding Tokyo::spawn solves many iss…

> Maybe not yet, but it is heading in that direction

I have little doubt that Rust will end up being as complicated as C++ eventually, but a big difference is how explicit and well documented the discusson of new features are.

The Rust RFCs provide a ton of context to almost every feature of the lagnuage. I find that historical context extremely helpful when trying to figure out why something is the way that it is.

There may be something like that for C++, but I feel like a lot of it is "you had to be there" kind of reasons.

Re: My negative views on Rust (2023)

#240

Post by jamincan »

pclmulqdq wrote: post #162
morning-coffee wrote: post #161

Earlier quoted context omitted.

First, things don't panic a lot in my experience writing Rust for the past three years. Second, when things do panic, it indicates a defect in the code that needs to be fixed. Aborting the program with a stack dump is the perfect behavior for seeing the state and the invariant that was violated and then figuring out the fix. Contrast this to C or C++ "limping along", usually until a later invariant causes a crash and…

These arguments get said a lot and they are all fine in theory, but in practice, all code over a certain size has a tremendous number of latent bugs, even Rust code. At a certain scale, you are virtually guaranteed to be running in a degraded mode of some kind. If the consequences of those latent bugs are operational nightmares, that's a problem. Most people would rather be able to roll in at 10 am to debug a minor i…

> These arguments get said a lot and they are all fine in theory, but in practice, all code over a certain size has a tremendous number of latent bugs, even Rust code.

Are you claiming this from direct experience, or do you have some data to back it up? Apparently the rollback rate for Rust code in Android is less than half that of C++. [1]

1. https://security.googleblog.com/2024/09/eliminating-memory-s...

Post reply on HN