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

161–170 of 308 posts

Re: My negative views on Rust (2023)

#161

Post by morning-coffee »

pclmulqdq wrote: post #146
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 has panics, and this is bad: ...okay? Nobody is writing panic handling code, it's not a form of error handling As far as I know, the issue with the panics is that things panic a lot. Times when C or C++ will limp along in a degraded state and log something for you to look at will cause your Rust program to crash. That turns things that are not problems into things that are problems.

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 being further away from and obscuring the true root cause, and we see why C and C++ code is generally still so bug-ridden relatively speaking. Fail-fast is not just a buzz word and program bugs are not recoverable errors. See https://joeduffyblog.com/2016/02/07/the-error-model/

Re: My negative views on Rust (2023)

#162

Post by pclmulqdq »

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

Earlier quoted context omitted.

> Rust has panics, and this is bad: ...okay? Nobody is writing panic handling code, it's not a form of error handling As far as I know, the issue with the panics is that things panic a lot. Times when C or C++ will limp along in a degraded state and log something for you to look at will cause your Rust program to crash. That turns things that are not problems into things that are problems.

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 issue from logs and traces than get a page at 1 am with 1000 stack traces in it.

Re: My negative views on Rust (2023)

#163

Post by s17n »

jkelleyrtp wrote: post #51
s17n wrote: post #43

Earlier quoted context omitted.

> Fetishization of Efficient Memory Representation: ... I don't understand what the point is here. Some people care about avoiding heap allocations? They're a tool just like anything else The point is that dealing with the Rust borrow checker is a huge pain in the ass and for most Rust applications you would have been better off just using a garbage collected language.

I mean, maybe? If you come into Rust thinking you're going to write doubly-linked lists all day and want to structure everything like that, you're going to have a bad time. But then in python you run into stuff like: ``` def func(list = []): list.append(1) ``` and list is actually a singleton. You want to pull your hair out since this is practically impossible to hunt down in a big codebase. Rust is just different, a…

I have literally never used a doubly-linked list in my life, and I'm pretty sure that most programmers can say the same thing.

As for the example... yeah, Python is pretty terrible (for writing production codebases, I think its a great language for short-lived, one-person projects). Interesting that you mention Python because if you're considering Python and Rust for the same use case that's pretty bonkers, for anything that you might possibly have used Python to do there are many more natural choices than Rust. If you wouldn't have done it in C/C++ ten years ago, you probably shouldn't be doing it in Rust today.

Re: My negative views on Rust (2023)

#164

Post by tptacek »

jcranmer wrote: post #154
sophacles wrote: post #142

Earlier quoted context omitted.

I'm not arguing that there isn't a tradeoff, or about "git gud". I'm literally and genuinely baffled about how one can magically elide knowing if a file is open or closed (or the equivalent) when using a resource. Like I can't think of a single language that doesn't make you explicitly obtain resources, and most of the GC languages do the same thing as rust for casual closing - just let the handle go out of scope. Ev…

> I still don't know what people mean when they talk about "having to think about memory layout" The best example I'd give is the degree to which you have to ask yourself if you want to use String or if you want to use &str--is this struct, or this function, going to own the string or borrow it from somebody else? If you're borrowing it, who is owning it? Can you actually make that work (this is really salient for pa…

Wading in here a little bit, and I know you've thought about this --- I think it's reasonable to say that there are problem domains where it's a very good thing, and problem domains where it isn't.

I think a subtextual problem for Rust advocacy is that the places where it's a clear win are a small subset of all software problems, and that space is shrinking. Rust would, in that view of the world, be a victim of its success: it's the best replacement we have for C/C++ today, but the industry has moved sharply away from solving problems that way, and sharply towards solving them with Javascript.

(Deno is doing something smart here.)

Re: My negative views on Rust (2023)

#165

Post by tptacek »

cmrdporcupine wrote: post #157
tptacek wrote: post #107

Earlier quoted context omitted.

Yes! Mutability is what's tripping me up! That is not a minor detail!

You can get something like what you're used to a "traditional" language without compiler safeguards by using RefCell and .borrow_mut() on it. That will let you get past the compile-time borrow checks but will do runtime borrow checking and throw panic if more than one borrow happens at runtime. It's verbose, but it's explicit, at least. So: struct Node { parent: Rc >, left: Option >>, right Option >>, } and just off…

I do know that it's possible, but when people complain about this --- as with this tweet, from a PL theorist:

https://x.com/LParreaux/status/1839706950688555086

... this is what they're talking about.

(I know the tweet is about the "idiomatic" answer to this problem, which is to replace references with indices into flat data structures).

Re: My negative views on Rust (2023)

#166

Post by morning-coffee »

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…

If your goal is to converge on correctly functioning software, you know, for the benefit of the users of it, then fail-fast can help. If your goal is to optimize the sleep patterns of devops people and make changes to code without testing before releasing it to production, yeah... do what you need to do. :)

Re: My negative views on Rust (2023)

#167

Post by mewpmewp2 »

Izkata wrote: post #91
jkelleyrtp wrote: post #51

Earlier quoted context omitted.

I mean, maybe? If you come into Rust thinking you're going to write doubly-linked lists all day and want to structure everything like that, you're going to have a bad time. But then in python you run into stuff like: ``` def func(list = []): list.append(1) ``` and list is actually a singleton. You want to pull your hair out since this is practically impossible to hunt down in a big codebase. Rust is just different, a…

FYI this site doesn't use ``` for code blocks, it uses indentation (two spaces). https://news.ycombinator.com/formatdoc

A bit off topic, but how do people usually write code here or on Reddit, I always find it to be really cumbersome to make sure there's two spaces etc in front of everything? Is there some formatting tool that I'm not aware of that everyone else uses?

Because in both forums I keep coming back to edits, and it takes forever to edit some of the things, manually. I feel like I'm being stupid or the UX of all of that is just so terrible.

Re: My negative views on Rust (2023)

#168

Post by [deleted] »

s17n wrote: post #163
jkelleyrtp wrote: post #51

Earlier quoted context omitted.

I mean, maybe? If you come into Rust thinking you're going to write doubly-linked lists all day and want to structure everything like that, you're going to have a bad time. But then in python you run into stuff like: ``` def func(list = []): list.append(1) ``` and list is actually a singleton. You want to pull your hair out since this is practically impossible to hunt down in a big codebase. Rust is just different, a…

I have literally never used a doubly-linked list in my life, and I'm pretty sure that most programmers can say the same thing. As for the example... yeah, Python is pretty terrible (for writing production codebases, I think its a great language for short-lived, one-person projects). Interesting that you mention Python because if you're considering Python and Rust for the same use case that's pretty bonkers, for anyth…

[deleted]

Re: My negative views on Rust (2023)

#169

Post by pclmulqdq »

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

Earlier quoted context omitted.

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…

If your goal is to converge on correctly functioning software, you know, for the benefit of the users of it, then fail-fast can help. If your goal is to optimize the sleep patterns of devops people and make changes to code without testing before releasing it to production, yeah... do what you need to do. :)

You can have correctly-functioning software when parts of it are operating in a weird way. The complaint I have heard about Rust crashes is that the default behavior is to crash in any situation that could possibly be weird.

By the way, the trade you're talking about is great for desktop software (especially for browsers), but server-side software at scale is a bit different.

The borrow checker and all the Rust safety stuff is also completely orthogonal to most forms of testing. You don't get to do any less because your language protects you against a specific class of memory-related errors.

Re: My negative views on Rust (2023)

#170

Post by satvikpendem »

mewpmewp2 wrote: post #167
Izkata wrote: post #91

Earlier quoted context omitted.

FYI this site doesn't use ``` for code blocks, it uses indentation (two spaces). https://news.ycombinator.com/formatdoc

A bit off topic, but how do people usually write code here or on Reddit, I always find it to be really cumbersome to make sure there's two spaces etc in front of everything? Is there some formatting tool that I'm not aware of that everyone else uses? Because in both forums I keep coming back to edits, and it takes forever to edit some of the things, manually. I feel like I'm being stupid or the UX of all of that is j…

I actually use a formatting tool online if on mobile, or just vim if on the computer, which can add two spaces in front of every line.
Post reply on HN