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

31–40 of 308 posts

Re: My negative views on Rust (2023)

#31

Post by School-Cotton »

tptacek wrote: post #16
hyperbrainer wrote: post #4

Needs (2023) > I predict that tracing garbage collectors will become popular in Rust eventually. The use of Rc is already very widespread in projects when people don't want to deal with the borrow checker and only want to use the ML-like features of Rust (Sum types, Option, Error etc.) > Rust has arrived at the complexity of Haskell and C++, each year requiring more knowledge to keep up with the latest and greatest.…

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.

> 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

No, it doesn't. If you naively express graphs containing cycles with `Rc` you will leak memory, just like you would with `std::shared_ptr` in C++.

Re: My negative views on Rust (2023)

#32

Post by hyperbrainer »

tptacek wrote: post #16
hyperbrainer wrote: post #4

Needs (2023) > I predict that tracing garbage collectors will become popular in Rust eventually. The use of Rc is already very widespread in projects when people don't want to deal with the borrow checker and only want to use the ML-like features of Rust (Sum types, Option, Error etc.) > Rust has arrived at the complexity of Haskell and C++, each year requiring more knowledge to keep up with the latest and greatest.…

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.

Considering that there exists a book about building linked lists in Rust[0], I am going to go ahead and say "Unclear" That does not matter though. It is easier (though verbose and often unidiomatic), and hence Rc has become really popular, especially with beginners.

[0] https://rust-unofficial.github.io/too-many-lists/

Re: My negative views on Rust (2023)

#33

Post by tptacek »

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

I feel pretty comfortable with Rc and Arc, read the "too many lists" book, &c. and feel like it is not actually simple to model trees with Rc? What am I missing? I'd love to be convinced I'm wrong about this (I want to like Rust more than I do).

Re: My negative views on Rust (2023)

#34

Post by Aeolos »

VeejayRampay wrote: post #9
IshKebab wrote: 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

Anecdotal experience: we rewrote an image processing algorithm from numpy+scipy to pure rust and got a 50x speedup in release builds, without even spending any effort optimizing the rust side.

There are further improvements possible around memory allocation and cachelines, but 2 days for 50x improvement was sufficient to not make it worth investing additional effort.

Edit: this was from a team who had _never_ touched Rust before.

Re: My negative views on Rust (2023)

#35

Post by pshc »

Animats wrote: 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…

> Rust does need a better way to do backlinks. You can do it with Rc, RefCell, and Weak, but it involves run-time borrow checks that should never fail. Those should be checked at compile time.

It's not clear to me how rustc could detect a dangling backlink in a tree structure at compile time. Seems impossible short of adding proofs to the type system.

Re: My negative views on Rust (2023)

#36

Post by DiabloD3 »

tptacek wrote: post #19
dvektor wrote: post #14

I agree with a couple points here, specifically I agree that choosing a language based on it's community (and not it's ecosystem) is just silly. And we all know that async ended up being a bit of a thorn in rust's side. But yeah, rust is very much a systems language: so it will be forcing you to think about memory layout one way or the other. Idk how valid of a complaint that is when you really consider that, and spe…

A complication of the "Rust is a systems programming language" thing is that people adopt definitions of "systems" of varying expansiveness to suit the situation. There are unquestionable systems programming domains --- the kernel is a great example, and one where it's easy to see why Rust is an exciting proposition; same with browsers, the "second OS" everyone runs --- and then more questionable domains. Is the fram…

"Systems programming language" has almost turned into a weird slur; instead of using it to refer to languages that can actually handle that task, they use it to attempt to pigeonhole a language into only that.

As in, people don't realize being a "systems programming language" is extremely difficult to get right, and many languages simply can't handle that (and never will, as per internal design requirements unique to those languages); if a language gets that right, they're going to get everything else right too if people decided to use it for that.

Re: My negative views on Rust (2023)

#37

Post by IshKebab »

VeejayRampay wrote: post #9
IshKebab wrote: 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

It is basically reading a massive JSON file containing a few thousand logs and then scanning them with a load of regexes.

I was a bit surprised how much faster it was too. Apart from Python being dog slow the only thing I really changed was to use RegexSet which isn't available in Python. I didn't benchmark how much difference that made though; I just used it because it was obviously the right thing to do.

That's kind of the point. If you just do the obvious thing in Rust you get very good performance by default.

It's the same in C++ but then you're writing C++.

Re: My negative views on Rust (2023)

#38

Post by jkelleyrtp »

"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 Copy, Drop, Deref for you: it would be really annoying to write Rust if you had to call `.copy()` on every bool/int/char. A language like this exists, I'm sure, but this hasn't stopped Rust from taking off

- 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

- Rewrite anything and it gets faster: okay sure, but there are limits to how fast I can make a Py/JS algorithm vs a compiled language, and Rust makes writing compiled code a bit easier. People probably aren't rewriting slow Python projects in C these days

- Rust is as complex as C++: ...no, it's not. Rust really hasn't changed much in the past 6 years. A few limitations being lifted, but nothing majorly new.

- Rust isn't as nice of community as people think: subjective maybe? People are nice to me at conferences and in discussion rooms. There's occasional drama here and there but overall it's been pretty quiet for the past year.

- Async is problematic: Async Rust really is fine. There's a huge meme about how bad it is, but really, it's fine. As a framework author, it's great, actually. I can wrap futures in a custom Poll. I can drive executors from a window event loop. Tokio's default choice of making `spawn` take Send/Sync futures is an odd one - occasionally cryptic compile errors - but you don't need to use that default.

I'm unsure why this article is so upvoted given how vapid the content is, but it does have a snappy title, I guess.

Re: My negative views on Rust (2023)

#39

Post by tuveson »

VeejayRampay wrote: post #9
IshKebab wrote: 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

If you heavily rely on the Python standard library, then you’re using a lot of Python code that doesn’t call out to C extensions. Peruse the standard library code, if you want to get a sense of it: https://github.com/python/cpython/tree/main/Lib

So you can expect any code that heavily relies on the standard library to be slower than the Rust equivalent.

A purely interpreted language implementation (not JIT’d) like CPython is almost always going to have a 10x-100x slowdown compared to equivalent code in C/C++/Rust/Go or most other compiled/JIT’d languages. So unless your program spends the vast majority of time in C extensions, it will be much slower.

Re: My negative views on Rust (2023)

#40

Post by hyperbrainer »

IgorPartola wrote: post #20
hyperbrainer wrote: post #6

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.

The two are not mutually exclusive. Also, I don't think I have ever needed to actively think about memory management more than .clone() and static for any hobby project I have undertaken. All the ML-like features like sum types, pattern matching etc. add great value. Cargo too. So, it is a great general purpose programming language. But blaming it as too low-level or similar despite choosing it is obtuse at best.
Post reply on HN