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

221–230 of 308 posts

Re: My negative views on Rust (2023)

#221

Post by Expurple »

tmtvl wrote: post #199
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 don't use Rust and I've bounced off trying to learn it 3 times so far, so take this with a mountain of salt, but... I think that Rust having unsafe is fine as there will be edge cases where the compiler can't quite work out whether some code will work fine or not and where the programmer can vouch for it. That's no problem. The issue I have with it is that the unsafe block then gets kinda swallowed by the supposedl…

This annotation would be useless, because it would infect ~99% of your codebase. All IO is implemented as unsafe FFI calls or unsafe inline assembly somewhere down the stack. And even "pure" types like Box, Option, Vec have a lot of unsafe in their implementations. At some point these standard implementations just have to talk to an allocator which is implemented unsafely (obviously), or they have to construct a slice [1], etc. Would you make an exception for the standard library and why? I think, this just doesn't make sense. It's all unsafe somewhere down the stack.

[1] https://doc.rust-lang.org/std/slice/fn.from_raw_parts.html

Re: My negative views on Rust (2023)

#222

Post by pjmlp »

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…

Code editor and then paste.

Re: My negative views on Rust (2023)

#223

Post by pjmlp »

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…

If the programmers have a proper degree, they surely have used them, additionally they probably have done it inderectly, depending on what languages they use.

Re: My negative views on Rust (2023)

#224

Post by pjmlp »

almostgotcaught wrote: post #196
Const-me wrote: post #194

Earlier quoted context omitted.

> I could get effectively the same performance with containers and move semantics When I’m happy with the level of performance delivered by idiomatic C++ and standard collections, I tend to avoid C++ all together because I also proficient with C# which is even faster to write and debug. But sometimes I want more performance. An example from my day job is a multi-step numerical simulation which needs to handle grids o…

> proficient with C# which is even faster to write and debug. I don't get it - why are we ignoring the fact that C# necessarily implies distributing CLR? NativeAOT doesn't work for everything.

As usual the typical argument that if it doesn't cover 100% of everything it isn't good enough.

There are plenty of use cases where NativeAOT works perfectly fine, and is getting better with each .NET release.

Re: My negative views on Rust (2023)

#225

Post by pjmlp »

sebastos wrote: post #140

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

Depends, how much from unstable Rust ends up in Rust during the next 30 years, to match where C++ is today after 40 years of production deployments across the industry.

Re: My negative views on Rust (2023)

#226

Post by hollerith »

Yujf wrote: post #188
hollerith wrote: post #177

Earlier quoted context omitted.

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.

Thanks. Another consideration that favors Rust, at least for game engines, is https://news.ycombinator.com/item?id=41793725

Re: My negative views on Rust (2023)

#227

Post by faitswulff »

jiggawatts wrote: post #208
faitswulff wrote: post #155

Earlier quoted context omitted.

> Maybe not yet, but it is heading in that direction When people say that Rust is complex, they often neglect to differentiate between implementation complexity and developer facing complexity. The implementation complexity is growing in part to support the end user simplicity. I also don't understand why anyone feels the need to know every feature of the language. You can just learn about and use the features that y…

That only works if you sit in isolation on a mountain and start with no_std and write everything else from scratch, yourself. The majority exist in a community and have to collaborate with others. They have to deal with the code written by others, code which may use any language feature. Every developer doing serious work will trip over every available language feature eventually.

> Every developer doing serious work will trip over every available language feature eventually.

Steve Klabnik:

“Just to provide another perspective: if you can write the programs you want to write, then all is good. You don't have to use every single tool in the standard library.

I co-authored the Rust book. I have twelve years experience writing Rust code, and just over thirty years of experience writing software. I have written a macro_rules macro exactly one time, and that was 95% taking someone else's macro and modifying it. I have written one proc macro. I have used Box::leak once. I have never used Arc::downgrade. I've used Cow a handful of times.

Don't stress yourself out. You're doing fine.“

https://www.reddit.com/r/rust/comments/1fofg43/i_am_struggli...

Re: My negative views on Rust (2023)

#228

Post by CryZe »

pjmlp wrote: post #218
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…

Maybe I suffer from brain damage due to knowing C++ since 1993, starting with Turbo C++ 1.0 for MS-DOS, however Rust is indeed getting into C++'s complexity. Lets not forget people tend to compare 40 year old language complexity, ampered by backwards compatibility and large scale industry deployment, with one that is around 10 years old, with lots of features still only available on nightly. The Unstable Book has an…

Only about 1/3 of those are language features. Out of those a ton are #[cfg] related (i.e. being able to more accurately doing conditional compilation), const (lifting limitations with compile time evaluation), documentation, architecture specific additions (like intrinsics) and co.

I only see about like 30 or so that are actual proper language additions, some of which are just exploration without even an RFC either, leaving us with about 15 or so, which really isn't that bad.

Re: My negative views on Rust (2023)

#229

Post by pjmlp »

CryZe wrote: post #228
pjmlp wrote: post #218

Earlier quoted context omitted.

Maybe I suffer from brain damage due to knowing C++ since 1993, starting with Turbo C++ 1.0 for MS-DOS, however Rust is indeed getting into C++'s complexity. Lets not forget people tend to compare 40 year old language complexity, ampered by backwards compatibility and large scale industry deployment, with one that is around 10 years old, with lots of features still only available on nightly. The Unstable Book has an…

Only about 1/3 of those are language features. Out of those a ton are #[cfg] related (i.e. being able to more accurately doing conditional compilation), const (lifting limitations with compile time evaluation), documentation, architecture specific additions (like intrinsics) and co. I only see about like 30 or so that are actual proper language additions, some of which are just exploration without even an RFC either,…

Every single of them needs brain space, regardless of the use.

Also any language designer knows that every feature has exponential capacity due to the way it interacts with everything already in use, that is why innovation tokens are a thing in language design.

Re: My negative views on Rust (2023)

#230

Post by burntsushi »

tialaramex wrote: post #220
burntsushi wrote: post #207

Earlier quoted context omitted.

There's plenty of examples like that though. A Python programmer might not know to compile in release mode. They might not use buffering when reading from a file. They might pass around copius copies of Vec instead of &[T]. The list could go on and on.

Sure, and there would probably be some value in a tool which can walk them through the easy stuff before they show a real human code which it turns out just wasn't tested with release optimisations or whatever. Still, as I understand it CTRE means if you just "use" the same expression over and over in your inner loop in C++ (with CTRE) it doesn't matter, because the regular expression compilation happened in compilat…

IDK how we jumped to CTRE. Python doesn't do CTRE. It's doing caching. In Rust, you use std::sync::LazyLock for that. I don't get what the problem is to be honest.

I assume by CTRE you're referring to the CTRE C++ project. That's a totally different can of worms and comes with lots of trade-offs. I wish it were easy to add CTRE to rebar, then I could probably add a lot more color to the trade-offs involved, at least with that specific implementation (but maybe not to "compile time regex" in general).

Post reply on HN