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

181–190 of 308 posts

Re: My negative views on Rust (2023)

#181

Post by Animats »

pcwalton wrote: post #97
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…

> 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 seem to use "unsafe" so much. I agree. I rarely ever use unsafe, and only as a last resort. Unsafe code is really not needed to achieve high performance. > Rust does need a better way to…

> I think this will basically turn into provably-correct data structures.

That's kind of what I'm thinking. The basic idea is to prove that .upgrade().unwrap() and .borrow() never panic. This isn't all that much harder than what the borrow checker does. If you have the rule that the return value from those functions must stay within the scope where they are created, then what has to be proven is that no two such scopes for the same RefCell overlap. Sometimes this will be easy; sometimes it will be hard. A reasonable first cut would be to check that no such scopes overlap for a specific type, anywhere. That's rather conservative. If you can prove that, you don't need the checking. So it's an optimization.

Re: My negative views on Rust (2023)

#182

Post by rich_sasha »

throwawaymaths wrote: post #144
rich_sasha wrote: post #93

Earlier quoted context omitted.

I disagree re Python. It is a brilliant, flexible scripting language. It is easy to build expressive libraries such as pytest or argparse, with deep introspection. It is easy to prototype by subtly changing return types, or even keeping them flexible. It is really easy to eg build a custom data type and build custom expression trees, such as what ML often needs. It has a number of features (often stemming from the ab…

If you feel that way about python, it's really just likely you haven't tried anything else better. And anyways you probably shouldn't be serving a website with a scripting language (php and perl are great examples of why not). You probably shouldn't be deploying ml with a scripting language ( maybe training is fine, if you're not doing distributed training). You probably shouldn't have too many core os components in…

I don't think you're getting my point. It's a good scripting language - there may better ones, that's besides my point. And your heuristic is terribly wrong, I have used many languages, scripting and otherwise.

My point is, it's great at its niche and good but kind of clunky at other things it ends up used for. At its off-niche applications, it attracts a lot of criticism - like you talking about how it's a bad idea to serve a webpage from a scripting language or productionise ML models.

No one complains that C++ is clunky at, dunno, serving websites, simply because it is so ill suited for it that no one ever tries. But Rust is less obviously a bad choice. Still that attracts people who find it clunky when they "just" want to serve a webpage and don't want to deal with the vagaries of borrow checker.

Re: My negative views on Rust (2023)

#183

Post by csomar »

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…

I was going to write a rebuttal but then I read your comment and it mirrored roughly what I was going to write.

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

One improvement here could be the IDE. I don't want to write `let s: String` every time but the IDE (neovim LSP) does show it. It'd be good if I can get the full signature too.

> Async is problematic

Async Rust is by far the best Async out there. Now when I use other languages I am essentially wondering what the hell is going on there. Is there an executor? Is there a separate thread for this? How/When is this getting executed? Async Rust doesn't execute anything and as a result you can get an idea of how the flow of your program goes (as well as pick an executor of your choice, might not seem important if you are on the Tokio bandwagon but if you are in an envrionment where you need a custom executor and you need to control CPU threads, Rust Async suddenly makes a lot of sense)

Re: My negative views on Rust (2023)

#184

Post by IshKebab »

tptacek wrote: post #46
IshKebab wrote: post #45

Earlier quoted context omitted.

I don't think that was too harsh given that he's saying that everyone who likes Rust (an extremely popular language) is an idiot who has been tricked into thinking it's good. How can you take opinions like that seriously? It's like saying "nah The Beatles weren't actually that good, everyone just thought they were because of their cool sunglasses". It's patronising and illogical and I don't think it's worth listening…

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.

Re: My negative views on Rust (2023)

#185

Post by delifue »

CryZe wrote: post #61
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.

> huge pain in the ass Maybe if you structure your code weirdly? I haven't encountered a major borrow checker issue that I couldn't easily resolve in many years.

It's not appropriate to say that "having trouble with borrow checker means code is wrong". Sometimes you just want to add a new feature and the borrow check force you to do a big refactor.

See also: https://loglog.games/blog/leaving-rust-gamedev/

Re: My negative views on Rust (2023)

#186

Post by tialaramex »

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

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

The actual regular expression implementation in Rust is going to be fast, but one of the things that caught a reddit poster out only recently was that the Rust regex crate's parser doesn't magically cache, so if you sit in a tight loop making the same regex over and over, it'll do all that work over and over, whereas the Python code might take ten times longer to do it once, then caches it, it doesn't take long for that to end up faster.

Now, if you're going to use RegexSet you're also smart enough to read "For example, it’s a bad idea to compile the same regex repeatedly in a loop" and say "Yeah, makes sense, I will not repeatedly compile the same regex". But some fraction of Python programmers won't read that - and it'll be very slow.

Re: My negative views on Rust (2023)

#187

Post by Yujf »

alfiedotwtf wrote: post #153
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…

I’ve been using Rust almost daily since 2015 and I’ve used unsafe twice - both when interoping with C. I don’t know what fancy things you’re doing with unsafe that you’re seeing it on a daily basis… maybe it’s a you problem

It is explicitly mentioned that ubsafe is in their dependencies not their own code.

Re: My negative views on Rust (2023)

#188

Post by Yujf »

hollerith wrote: post #177
tptacek wrote: post #176

Earlier quoted context omitted.

No, I don't think so? I would have predicted games as a sweet spot for Rust. Most significant game projects are done in C++, and I look at Rust as basically obsoleting C++.

OK. Thanks. My guess was that since almost no one will pay more for a game's having fewer security vulns, there is less benefit to incurring the expense of Rust (takes longer to learn, development speed is slightly less)

Its not just vulnerabilities. In theory you should also get more stability.

For example I like to play Civ with a friend, but stopped because about once every 30 minutes one of us would have their game crash. If it was written in Rust, I assume it might be more stable.

Re: My negative views on Rust (2023)

#189

Post by tialaramex »

Diggsey wrote: post #133
hyperbrainer wrote: post #48

Earlier quoted context omitted.

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

> Also, there are far more ways to cause UB in C++.

As well as lots of Undefined Behaviour, C++ also has what its own experts call "False positives for the question is this a C++ program" the Ill-Formed No Diagnostic Required features, nothing like these exist in Rust, they're cases where you can write what appears to be C++ but actually although there are is no error or warning from the compiler your entire program has no meaning and might do absolutely anything from the outset. I've seen guesses that most or even all non-trivial C++ invokes IFNDR. So that's categorically worse than Undefined Behaviour.

Finally, C++ has cases where the standard just chooses not to explain how something works because doing so would mean actually deciding and that's controversial so in fact all C++ where this matters also has no defined meaning and no way for you to discover what happens except to read the machine code emitted by your compiler, which entirely misses the point of a high level programming language.

One of the things happening in Rust's stabilization process is solving those tough issues, for example Aria's "Strict Provenance experiment" is likely being stabilized, formally granting Rust a pointer provenance model, something C++ does not have and C23 had to fork into a separate technical document to study.

Re: My negative views on Rust (2023)

#190

Post by googh »

tialaramex wrote: post #189
Diggsey wrote: post #133

Earlier quoted context omitted.

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

> Also, there are far more ways to cause UB in C++. As well as lots of Undefined Behaviour, C++ also has what its own experts call "False positives for the question is this a C++ program" the Ill-Formed No Diagnostic Required features, nothing like these exist in Rust, they're cases where you can write what appears to be C++ but actually although there are is no error or warning from the compiler your entire program…

Most (if not all) of your posts here on HN boil down to "C/C++ bad, Rust good". I wonder what you are trying to achieve by this, but I assure you that this does not do Rust any favor other than giving the impression that the Rust community is obnoxious.
Post reply on HN