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

201–210 of 308 posts

Re: My negative views on Rust (2023)

#201

Post by northhanover »

Shatnerz wrote: post #110
jkelleyrtp wrote: post #88

Earlier quoted context omitted.

The title is inflammatory and yet there are few nuanced takes in the article. It's weird to see it shoot to the top of HN. I think the loglog article is a much better, nuanced, full critique of Rust. https://loglog.games/blog/leaving-rust-gamedev/ The internet is just so full of negativity these days. People upvote titles but don't read articles. Reading about people's views on subjects is useful, but I don't think t…

Inflammatory? "My Negative Views on X" is pretty far from inflammatory. It is exactly what the post was, with some positivity sprinkled in as well.

It’s 2024. If I read some thing I don’t agree with on the internet it IS inflammatory.

Re: My negative views on Rust (2023)

#202

Post by SkiFire13 »

pclmulqdq wrote: post #162
morning-coffee wrote: post #161

Earlier quoted context omitted.

First, things don't panic a lot in my experience writing Rust for the past three years. Second, when things do panic, it indicates a defect in the code that needs to be fixed. Aborting the program with a stack dump is the perfect behavior for seeing the state and the invariant that was violated and then figuring out the fix. Contrast this to C or C++ "limping along", usually until a later invariant causes a crash and…

These arguments get said a lot and they are all fine in theory, but in practice, all code over a certain size has a tremendous number of latent bugs, even Rust code. At a certain scale, you are virtually guaranteed to be running in a degraded mode of some kind. If the consequences of those latent bugs are operational nightmares, that's a problem. Most people would rather be able to roll in at 10 am to debug a minor i…

I wonder how you could realistically end up in those two situations for the same issue though.

Re: My negative views on Rust (2023)

#203

Post by cmrdporcupine »

tptacek wrote: post #165
cmrdporcupine wrote: post #157

Earlier quoted context omitted.

You can get something like what you're used to a "traditional" language without compiler safeguards by using RefCell and .borrow_mut() on it. That will let you get past the compile-time borrow checks but will do runtime borrow checking and throw panic if more than one borrow happens at runtime. It's verbose, but it's explicit, at least. So: struct Node { parent: Rc >, left: Option >>, right Option >>, } and just off…

I do know that it's possible, but when people complain about this --- as with this tweet, from a PL theorist: https://x.com/LParreaux/status/1839706950688555086 ... this is what they're talking about. (I know the tweet is about the "idiomatic" answer to this problem, which is to replace references with indices into flat data structures).

I don't have a twitter account and don't read links to paywalled services there, so don't know what the complaint is.

Ergonomics aren't great for this type of problem, but it's something I almost never run into. Feels like a cooked up example. I've written tree data structures, etc. and never had much issue. ASTs for compilers, no particular drama.

Rust is just making you consider whether you really want to do this, is all.

Re: My negative views on Rust (2023)

#204

Post by SkiFire13 »

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…

If you're doing graphics then you will have to use `unsafe` to interface with the OS primitives, there's no other way.

Backlinks would be "nice" but they break fundamental assumptions that the borrow checker does.

> Detecting a double borrow is the same problem as detecting a double lock of a mutex by one thread, which is being worked on.

Is it being worked on using heuristics or formal methods?

Re: My negative views on Rust (2023)

#205

Post by kunley »

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…

I think the author rather refers to "tamagotchi tooling" and constant adapting libraries to new trends. It was not that much about language changes per se

Re: My negative views on Rust (2023)

#206

Post by SkiFire13 »

Const-me wrote: post #109
jltsiren wrote: post #90

Earlier quoted context omitted.

Non-trivial data structures are often just a bunch of arrays/maps with additional semantics. You may consider implementing/using unchecked versions of basic operations for a little bit of additional performance. If you implement (de)serialization yourself, you may need unsafe code. Sometimes the safety of deserialization may be a convenient lie, if checking the invariants fully would be too expensive. And sometimes y…

> Non-trivial data structures are often just a bunch of arrays/maps with additional semantics This might be fine for code which consumes data structures implemented by other people. The approach is not good when you actually need to implement data structures in your program. In modern world this is especially bad for a low-level language (marketed as high performance, BTW) because the gap between memory latency and c…

> You do need efficient data structures, which often implies developing custom ones for specific use cases.

You are assuming you can't do this with those vecs/maps. But you can! That's what the "additional semantics" are.

They will be slightly slower due to often using indexes instead of raw pointer, which requires a bound check and an addition to get the pointer, and sometimes a reallocation, but they won't be that slow. Surely they will be faster than C#, which you claim can implement those same data structures efficiently. You also often get the benefit of better cache locality due to packing everything together, meaning it could even be faster.

Re: My negative views on Rust (2023)

#207

Post by burntsushi »

tialaramex wrote: post #186
IshKebab wrote: post #37

Earlier quoted context omitted.

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

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.

Re: My negative views on Rust (2023)

#208

Post by jiggawatts »

faitswulff wrote: post #155
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 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.

Re: My negative views on Rust (2023)

#209

Post by jltsiren »

Const-me wrote: post #194
jltsiren wrote: post #120

Earlier quoted context omitted.

I used to think like that. Then C++11 arrived, and I realized I could get effectively the same performance with containers and move semantics, while spending less effort on writing and debugging the code. If you need an array for your custom data structure, a standard library vector is almost always good enough. Associative arrays are a bit more tricky, but you should be able to find a handful of map implementations…

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

I've been using std::vector with arrays that take up to tens of gigabytes for ~15 years without any real issues. Once the size of the allocation exceeds a few megabytes, any reasonable allocator is going to use an anonymous memory map anyway. And if the array doesn't need to grow, it takes effort to make a standard library vector worse than a manually optimized one. It's just a pointer and two integers, after all.

Re: My negative views on Rust (2023)

#210

Post by mwcampbell »

bachmeier wrote: post #84
andrepd wrote: post #5

Earlier quoted context omitted.

Thinking like that is how we get 12MB of javascript to read a news article, or mobile apps that are jankier than Word 97. I don't get how someone can criticise a systems programming language by saying "I have to think about memory layout"....

There's a response to your comment in the post: > I feel like Rust is self-defined as a “systems” language, but it’s being used to write web apps and command-line tools and all sorts of things. > This is a little disappointing, but also predictable: the more successful your language, the more people will use your language for things it wasn’t intended for. > This post still offends many who have tied Rust to their id…

I think maybe the GP's point is that we should use systems languages, with their focus on efficiency, for things that the OP defines as out of scope, as an antidote to the creeping software bloat that we all like to complain about from time to time.

And let's not forget that Word 97 felt bloated in its day, however fondly we may look back on it now.

Post reply on HN