Live data from Hacker News

My negative views on Rust (2023)

chrisdone.com

51–60 of 308 posts

Re: My negative views on Rust (2023)

#51
post #43

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

> 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, and instead of writing double-pointer code, you just use flat structures, `Copy` keys, and `loop {}` and move on with your life.

Re: My negative views on Rust (2023)

#52
post #43

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

> 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 haven’t had to „deal with” the borrow checker since like 2018. It’s quite smart

Re: My negative views on Rust (2023)

#53

Earlier quoted context omitted.

Criticising a systems programming language for needing to manually manage memory is honestly embarrassing.

I mean to be fair so is using a systems programming language for every use case under the sun. If Rust is a great systems programming language that’s one thing. If it’s a general purpose language that’s another.

A lot of git(1) subcommands were originally written in shell or Perl. Now most are written in C.

Through many decades people wrote utilities and applications in C. Not hardcore lower-level kernel modules. Just utilities and applications. Because that’s what they wanted to write them in. Over Perl or Java or whatever else the alternatives were.

What’s more C than that? Writing everything short of scripts in it?

Now people write applications in a modern programming language with modern affordances. They might be working uphill to a degree but they could have chosen much less ergonomic options.

The embarrassing part is criticizing people who have put in the work, not on the merits of their work, but on… having put in too much work.

Re: My negative views on Rust (2023)

#54
post #16

Earlier quoted context omitted.

Does Rc really resolve the core problem this post is talking about, which is that it's really painful to naturally express tree and graph structures in Rust? It feels like I mostly see people talking about building application-layer pointer systems with integers, which would be surprising if (in a single thread, perhaps) you could just Rc your way around the problem.

Sure, Rc/Arc absolutely solves this problem. It's not super idiomatic to go crazy with using it like that, but it's possible/acceptable. Using SlotMap and integer ids, etc. doesn't I think offer any advantage.

Doesn't SlotMap save RAM and pointer dereferences?

Re: My negative views on Rust (2023)

#55
post #3

I've read this before, it's been passed around the Rust community a few times. The annotated tl;dr is: Chris doesn't want to learn how hardware works, they don't want to learn how to write optimal software, they don't want to write safe software, they just want to write in a language they already know because they're not comfortable with learning other languages because their home language is a functional language (H…

Chris is a team of people? I thought he was just one developer

If you re-read the sentence with s/Chris/The Author/ I expect you'll find the pronoun cromulent. "They" was exclusively plural in Middle English in the 1300s, but, we're not speaking Middle English.

Re: My negative views on Rust (2023)

#56
post #7

So much to disagree with.... > In practice, people just want to be able to write a tree-like type without having to play Chess against the compiler. Sure, Rust's strong encouragement of tree-structured ownership may be annoying when you try and make a spaghetti ownership soup, but it's not like it doesn't have upsides. Many people have written about how the ownership & borrowing rules lead to code structure that has…

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 in performance versus the pure-compiled alternatives.

I think this is asserted a lot more often then it is benchmarked. I am reminded of the way people for a long time asserted that the performance of web languages doesn't matter because you spend all your time waiting for the database, so it never mattered. People would just whip this argument out reflexively. It turns out that if you take a non-trivial codebase written in such a language and actually benchmark it, it is often not true, because as applications grow they tend to rapidly outgrow "all my code is just running a SELECT and slamming the results with minimal processing out to the web stream". I hear this a lot less often than I used to, probably through the slow-but-effective process of a lot of individuals learning the hard way this isn't true.

I've seen a lot of Python code. Very little of it that was not "data science" was just a bit of scripting around lots of large C-based objects, such that Python wasn't doing much actual work. And even some of that "data science" was falling back to pure Python without realizing because NumPy actually makes that shockingly easy.

Re: My negative views on Rust (2023)

#57
post #3

I've read this before, it's been passed around the Rust community a few times. The annotated tl;dr is: Chris doesn't want to learn how hardware works, they don't want to learn how to write optimal software, they don't want to write safe software, they just want to write in a language they already know because they're not comfortable with learning other languages because their home language is a functional language (H…

Chris is a team of people? I thought he was just one developer

What makes you think they're a team?

Re: My negative views on Rust (2023)

#58
post #49
post #11

My big problem with Rust is too much "unsafe" code. Every time I've had to debug a hard problem, it's been in unsafe code in someone else's crate. Or in something that was C underneath. I'm about 50,000 lines of Rust into a metaverse client, and my own code has zero "unsafe". I'm not even calling "mem", or transmuting anything. Yet this has both networking and graphics, and goes fast. I just do not see why people see…

It's ugly but it's inevitable in some sense. The author should know what they are doing, and `// SAFETY:` comment is a must.

No. Nobody is going read those (because most people won't even know that some unsafe is buried 5 layers of dependencies below what they work with). The author should make reasonable effort to prove the code is working correctly (and cannot be abused) by other means if possible. It might be a domain issue, so far all my apps are 100% safe (not counting libraries).

Re: My negative views on Rust (2023)

#59
post #41

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

This is an old example, but - date/time parsing. A coworker of mine years ago was trying to parse out some large logfiles and it was running incredibly slowly (because the log file was huge). Just for fun he profiled the code and found that 90% of the time was spent taking the timestamp ("2019-04-22 15:24:41") into a Python datetime. It was a slow morning, so we went back and forth trying to come up with new methods…

One could argue that writing a timestamp as a string which then has to be parsed is silly and instead it should be delta-of-delta encoded and packed into variable width integers, but even then double integrating and constructing a datetime for each one would still be expensive in python, only less so.

Re: My negative views on Rust (2023)

#60
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…

> this is practically impossible to hunt down in a big codebase

use linters, they keep getting smarter

Post reply on HN