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

131–140 of 308 posts

Re: My negative views on Rust (2023)

#131

Post by tptacek »

pcwalton wrote: post #103

I actually used to agree that Rust generally wasn't good for high-level application code, but working with Bevy has made me change that opinion for certain domains. I simply haven't seen a system that makes automatically parallelizing all application logic (game logic, in this case) feasible, other than Bevy and other Rust-based systems. The trick is that the borrow check gives the scheduler enough information to aut…

Just so we're clear, your reference points for "good for high-level application code" are systems code and game engines? :)

Re: My negative views on Rust (2023)

#132

Post by johnnyanmac »

Ygg2 wrote: post #28
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…

> My big problem with Rust is too much "unsafe" code. I hear cargo-geiger is useful identifying such crates. > I just do not see why people seem to use "unsafe" so much. Because it's: A) fast (branchless access) B) fast (calling C libs or assembly) C) fast (SIMD) D) people think unsafe Rust is easier Want to write a JSON parser that will gobble up gigabytes per second? Your only way is removing as many branches and u…

>people think unsafe Rust is easier

If that's their line of thought, I don't know why they simply don't use C/++. Or even C# with unsafe blocks. I know you said the same, but I wanted to reiterate that.

But yes, I can see a few very specific cases where unsafe access is needed. Emphasis on "few". I think anything past some fundamentals should be at best a late optimizing step after an MVP is established.

I also think, if it's not already there, that crates should be able to identify if it's "safe" or "unsafe". Same mentality where I'd probably want to rely on safe crates until I need to optimize a sector and then look into blazing fast but unsafe crates.

Re: My negative views on Rust (2023)

#133

Post by Diggsey »

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;

It's definitely getting more complex, but C++ has a huge lead haha. C++ is like a fractal in that you can look at almost any feature closer and closer to reveal more and more complexity, and there are a lot of features... Here's a page on just one dark corner of the language: https://isocpp.org/wiki/faq/pointers-to-members and it interacts in interesting ways with all the other corners (like virtual vs non-virtual inheritance) in fun and exciting ways...

Also, there are far more ways to cause UB in C++. Rust has a big lead on formalizing what constitutes UB, and even those rules you only need to learn if you are using "unsafe", whilst in C++ you don't have that luxury.

Re: My negative views on Rust (2023)

#134

Post by pcwalton »

tptacek wrote: post #131
pcwalton wrote: post #103

I actually used to agree that Rust generally wasn't good for high-level application code, but working with Bevy has made me change that opinion for certain domains. I simply haven't seen a system that makes automatically parallelizing all application logic (game logic, in this case) feasible, other than Bevy and other Rust-based systems. The trick is that the borrow check gives the scheduler enough information to aut…

Just so we're clear, your reference points for "good for high-level application code" are systems code and game engines? :)

Games themselves, not game engines. Systems code, game engines, and games.

This isn't meant to be an exhaustive list--it's just the domains I have experience with that Rust was a good fit for. Lest it seem like I'm saying Rust is a good fit for everything I've done, I also worked on Firefox where the UI was JavaScript, and I wouldn't hurry to rewrite that code in Rust. Nor would I want the throwaway stuff I write in Python or Ruby to be Rust.

Re: My negative views on Rust (2023)

#135

Post by johnnyanmac »

lll-o-lll wrote: post #10

> People waste time on trivialities that will never make a difference. This is an aha moment as I read it. The complexity of your tools must be paid back by the value they give to the business you’re in.

Really depends on the "difference". If a male a container crate that is Fer from shippable but gives me knowledge to land a Rust gig, was it a triviality?

Re: My negative views on Rust (2023)

#136

Post by School-Cotton »

beeflet wrote: post #130
School-Cotton wrote: post #26

> Distinguishing mutability has its advantages I think it's misleading to say that Rust distinguishes mutability. It distinguishes _exclusivity_. If you hold a reference to something, you are guaranteed that nothing else holds an exclusive reference to it (which is spelled &mut). You are _not_ guaranteed that nothing accessible through that reference can change (for example, it might contain a RefCell or other interi…

>IMO, the fact that exclusive references are spelled "&mut", and often colloquially called "mutable references", was a pedagogical mistake that we're unfortunately now stuck with. You couldn't just roll out a change like alias &e to &mut and &s to &, and then have a compiler warning for using the old &mut or &?

That’s technically possible, yes, but I really doubt there is any appetite to change basic syntax like that when it’s already so ingrained in everyone’s mind.

Re: My negative views on Rust (2023)

#137

Post by ilrwbwrkhv »

drogus wrote: post #114

It's funny when people mention Go as the gold standard of not adding features to the language and Rust as ever-changing when Rust hasn't introduced any major changes in at least 3-4 years and Go introduced a major paradigm shift in how people structure their code (generics). Before you start replying with "Rust introduced X" - ask yourself - is X extending an existing feature slightly or does it introduce an entirely…

Ya the article is a bit fluffy and insubstantial. Surprising it's been voted up so highly on HN. Are people just going off the title?

Re: My negative views on Rust (2023)

#138

Post by steveklabnik »

beeflet wrote: post #119
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 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 Is it possible to disable this behavior? I think it might be useful as a learning tool to familiarize myself with the Traits.

It is not.

Re: My negative views on Rust (2023)

#139

Post by ilrwbwrkhv »

lll-o-lll wrote: post #10

> People waste time on trivialities that will never make a difference. This is an aha moment as I read it. The complexity of your tools must be paid back by the value they give to the business you’re in.

This is daft logic. Your business itself has no value in the modern world. Your todo saas app is not needed. Of course this argument is faulty, so going one step back, what is valuable is in the eyes of the hacker. For a lot of people, including mine, the triviality is also part of the value chain.

Re: My negative views on Rust (2023)

#140

Post by sebastos »

"X is as complex as C++" is a preposterous statement for all values of X.

A lot of people seem to assume that "C++ is complex" is referring to how the committee adds new language features every 3 years. The conventional wisdom that C++ is wickedly difficult to learn is NOT about "oh man, now I need to learn about the spaceship operator?" C++ is an almost unfathomably bottomless pit. From the arcane template metaprogramming system to the sprawling byzantine rules that govern what members a compiler auto-generates for you, and on to the insane mapping between "what this keyword was originally introduced for" and "what it actually means here in _this_ context, there is no end to it. Keeping up with new language syntax features is an absolute drop in the bucket compared to the inherent complexity required to understand a C++11 codebase, build it (with a completely separate tool that you must choose) and manage its dependencies (with a yet different completely separate tool that you must choose).

You don't have to know anything about Rust to know that saying "Rust has become complex as C++" is objectively incorrect.

Post reply on HN