Hacker News Reader

I have written around 30k+ lines of rust by now, and I have to agree with OP. I have encountered many situations where perfectly reasonable, zero copy, memory management that would be completely normal, fast and safe in C, it basically impossible to replicate in Rust (or at least I am not clever enough to figure it out). Are there other ways to structure the data that work in Rust? Yes, of course. Do I like them compared to the C one? No, not at all. Do I think that the additional memory safety that comes from Rust is worth it? In some use cases, yes

I have written about 50K LoC of Rust, so fairly similar. I will agree that I have had occasional "lost days" with some very complex spots of code that would not have been a problem in a GC language. That said, I feel like I've made up for that at least 1.5-2x by my productivity and lack of bugs in other sections.

That said, I can understand how it may not be for everyone. I love it, but there are some data structures you just have to code differently, and until you spend time thinking about how to do that, it would seem like wasted time you wouldn't get back.

My personality may also be a fit: I'm very much a measure twice, cut once kind of person. I tend write my algorithms in pseudo code and sketch my data structures on paper before I touch the keyboard, so even in my "get it done" language I don't immediately just start coding always.

Seeing some of the hassles with creating basic stuff like a linked list is part of the reason I have yet to use it seriously. I think I will eventually, but I certainly won't act like it doesn't come with a cost or that it always pays off.

If you were clever enough to write it safely in C I can guarantee you'd be clever enough to write it in Rust.

Oh boy, that is so not true. Anything where the boundaries of the lifetimes are easily determined at runtime but unknown at compile time is extremely easy to model safely in C, and a nightmare in Rust. At least if you want the same level of performance and a similar modeling of the data

> Anything where the boundaries of the lifetimes are easily determined at runtime but unknown at compile time is extremely easy to model safely in C,

I don't even know how to respond to this seriously. I guess just imagine me pointing to every blatant instance of this not being true.

With all due respect to Michael Palin, "this isn't an argument ... it's just contradiction."

Perhaps, for the benefit of those of us observing if nothing else, it might be beneficial to identify some concrete examples to discuss before proceeding.

I dislike when a discussion turns into "I have to teach you the basics now". I'm just not willing to engage in that most of the time with strangers on the internet because they usually don't want to be taught, they want to be right.

Explaining that you can express complex dynamic lifetimes in Rust using 'unsafe' and module-level safety is a waste of my time because it's empirically true.

But you are engaging with strangers on the internet. You're just not doing it in a way that's particularly edifying. Indirectly insulting me and others doesn't help your case on that front.

Let me turn it back on you. By refusing to educate people on what you think they got wrong, you come across looking like just what you're worried about: someone who just wants to be right.

If your goal is to defend Rust, I would suggest you either teach for yourself, or share links to others teaching the thing you want to communicate but don't want to type out, or, if neither of those, then to simply keep your peace and let someone else do the responding. Speaking for myself as an on-and-off Rust learner, I've got to say that the single biggest frustration I've experienced with learning the language is wading through all the low effort gainsaying in order to find the nuggets of digestible, practical advice about how to effectively use the language for non-toy problems. It's not that I can't do so, per se. It's just that it's really hard, and perhaps even counterproductive, to work up the motivation to wade through all the snark and invective when my original purpose was to try and unwind at the end of the day.

I made an accurate statement. Anyone can take it or leave it.

If you want help learning the language I'd suggest the Discord or subreddit, people will be happy to assist.

In my experience, the vast majority of examples where that fails is because of two reasons: project evolution that doesn't spend time re-evaluting memory managemnt together with the new requirements on the data, or inexperienced C coders. So that goes to my last point in my original post, yes as an industry there are use cases where rust is better because of the provably safe memory management (let's forget unsafe for the moment). But as a language you _can_ safely model those situations in C esily. The problem is that the solution is not robust to change. If you don't agree with that it will be me who doesn't know how to take what you say seriously

Um, lifetimes are not a made up concept of rust to be in your way. It helps you understand issues that would be real and undetected in your C app.

Your C app would work by happy accident and you would not notice until later when data is corrupted in another part of your program. This is the rest of us wanted to leave C/C++.

Rust lifetimes are just the lifetimes of the memory, exactly the same as C. The only difference is you simply need to (sometimes) tell Rust where the memory for a reference comes from explicitly, where as in C you don't (but in C if you get it wrong your program will segfault, unlike Rust, or worse it might not...sometimes).

> Rust lifetimes are just the lifetimes of the memory, exactly the same as C.

Rust lifetimes are only the lifetimes of the memory that are provable by the type system. There are many valid lifetimes that are not provable. For example lifetimes that change at runtime, and self referencing lifetimes, or cyclic lifetimes. Newer versions of the borrow checker enable it to prove more lifetimes correct, but it will never be able to express all valid lifetimes of the actual memory.

This means some patterns the are completely valid cannot be expressed in safe Rust due to the limitations of the type system, but can be expressed in C.

And you can use unsafe.

Well yes, lifetimes also exist in C, but it is only in Rust that they are compiler checked

> I have encountered many situations where perfectly reasonable, zero copy, memory management that would be completely normal, fast and safe in C

So you think. It doesn't matter how smart you think you are, statistically speaking you're not smarter than a compiler.

I think you are overestimating the expressive power of lifetime annotations in rust, and how smart the borrow checker is

Anything you can express in C, you can in Rust. When it comes to pointer tricks you might have to use unsafe, but that is part of the language.

If only 50% of the community didn't think it was their job to scream at complete strangers for using that part of the language.

Agreed (unfortunately). There is too much of an obsession in avoiding unsafe at all costs in my opinion. When you consider all C/C++ is effectively written in an unsafe block then it seems a bit ludicrous to assume you would never ever use unsafe in tight, performant code.

Can we please not do this?

It's fine to give a different viewpoint, but it's surprisingly common that whenever someone says anything bad about Rust, a Rust user comes in to say that they just haven't used it enough.

It's like saying "If you don't like my favorite movie, you just haven't watched it enough."

It's not even the right category of criticism. The author talks about 'mathematical purity' which is something Rust sneers at. Spend just a little while with Rust and you can see that when the language is getting in your way, the driving direction it is pushing you in is towards code that will be maintainable. Which is still not about getting shit done, and is still a valid axis to prefer Go's rapid development cycle on, but if you cannot name the distinction then it is hard to believe you have spent enough time with the language to properly observe it.

I kinda agree, it's weird to me how people make a big deal about the borrow checker as if it's an evil spirit gatekeeping your code.

And if you wanna go fast instead of writing maintainable code you surely can with stuff like unwrap(), clone(), Copy.

In a way I think most people expect to pick up Rust more easily because they have expertise in other languages and are surprised when Rust feels like learning to code again, basically turning some ingrained assumptions upside down.

It really is not the kind of language where you can glaze over the introduction chapter and churn a TODO app in the same afternoon in my opinion.

>And if you wanna go fast instead of writing maintainable code you surely can with stuff like unwrap(), clone(), Copy.

That's a good approach to learning the language, but it breaks down as soon as async comes into the picture. It's basically impossible to be fluent writing async rust without a very healthy understanding of complex types, how the borrow checker works passing things across closures, etc.

> It's like saying "If you don't like my favorite movie, you just haven't watched it enough."

It took you average movie time to learn whole entirety of language? Wow!

And without sarcasm, yes, sometimes it is the case.

Most of the bugs Rust catches are memory related bugs and some data races in concurrent code. In any GC language the first is solved and there are concurrency frameworks available that prevent similar data race issues. TFA's author is comparing against Nim, a GC language. And in my experience of 10k LOC of Rust it's the same as the author's.

Also does every criticism of Rust have to have a prominent rebuttal? TFA buried it in the appendix and the article is about a lot more languages than Rust, but here we are talking about Rust again. We all have our favorites, we don't have to stick out for them everywhere. Some people don't like Rust and that's okay.

Seems like Rust is hitting peak popularity right now so there are tons of people out there feeling slightly insecure about their new language and needing to defend it every time someone picks a competitor.

> Also does every criticism of Rust have to have a prominent rebuttal?

Ha, sorry - I just really love Rust and want others to at least try it. I passed on it for _years_ because I thought like the OP (I used to code in Scala - I personally find THAT takes cognitive load to remember all the features. Rust feels small to me in comparison). Rust made me LOVE to code again and I just think there must be others out there who would feel the same if they just tried it.

> Some people don't like Rust and that's okay.

Agreed, I'm sure it isn't for everyone.

Maybe you should try a language where people get a lot of work done in the day to day ? E.g: Python, Go...

It seems crazy to me someone who code in Scala, now loves Rust. Brains are really something else :)

I've written extensively in about 10 languages including the two you mentioned.

The current project I'm writing is migrating from Python to Rust. Python is not appropriate for large projects IMO and this one I wrote and am now porting to Rust is no exception. I do love Python for things up to 1000 lines or so, but after that you really need to test every single line, which is just a PITA. Mypy and now others help, but the typing isn't strong enough (although I've heard good things about some newer static typing addons).

I have a love/hate relationship with Go, but after I found Rust I'll never touch it again. It simply isn't expressive enough which leads to code that is overly verbose. The lack of a decent enum, repeating nil pointer mistake, verbose and error prone error handling, the constant copy/paste (now semi fixed with generics). I do love that it strives to be a simple language, but strangely the Rust tooling is much easier to use, so I'm not convinced it hits the mark. I do love how fast it compiles, and that is the one thing I hate about Rust.

Hm. Ok. Tell it to my previous company running 12 million LoC of Python.

It was easier to make changes there than in the 500k loc c++ system I maintained later.

Language has nothing to do with success of large projects, it’s everything around it. The culture of the company, the cicd systems, the release system, the build system, packaging, documentation , rollback, dependencies.

And for large projects, you’re rolling a lot of those yourself.

> Hm. Ok. Tell it to my previous company running 12 million LoC of Python.

Just because it can be done, doesn't mean it should be done. Just my opinion.

> It was easier to make changes there than in the 500k loc c++ system I maintained later.

I don't consider C++ a good language in any way, shape, or form. Now had you claimed the same about OCaml, Kotlin, etc. I would have a harder time believing it.

> Language has nothing to do with success of large projects,

Of course it does, but they do not exist in isolation either - it is just one component. There are many factors that would play in.

> it’s everything around it. The culture of the company, the cicd systems, the release system, the build system, packaging, documentation , rollback, dependencies.

My point about python is that it literally _requires_ you to make up for language deficiencies (aka dynamic typing + unchecked exceptions) by testing insane amounts to even make it possible. The things that work against you at large scale, work for you at tiny scale (aka scripts).

Heheh company with 14 million LoC barely had tests :)

I don’t know what kind of companies you worked on, but let me tell you that the code that runs the world comes from an era before tests, and some of it is too complicated to even be tested.

Test it in production is the only way for a lot of it. Then you need observability and easy ways of rolling back. That’s about it. Regardless of the language.

Read the latest google book — code architects at google I think it’s called ? Has a couple of great chapters on testing at scale and how unittests are useless

Your argument vs OP that tried rust, is that they should try rust until they agree with you?