Hacker News Reader

Comment by arcticbull | Hacker News Reader

> You're smarter than Rust. I'm not kidding!

You're probably not. That's kind of the thing. Rather, it's not that you're not smarter, it's just that you're not used to doing things properly, and Rust forces you to do things properly.

"Leave me alone, I know what I'm doing" says beginner juggling chainsaws on a unicycle.

Ultimately it comes down to this: when you don't write down all the information a compiler needs to generate an artifact, you're relying on hidden, un-stated assumptions. Such assumptions are subject to change over time. Relying on them isn't smart, it's dumb. It makes you feel smart. Just check the CVE list.

View on HN

These zero information statements and intellectually dishonest marketing is what keeps rust a fringe language.

> it's just that you're not used to doing things properly, and Rust forces you to do things properly.

Many patterns that rustc refuses aren't inherently wrong. They are because 1) you have to aid lifetime inference and memory management unlike GC languages 2) All safe patterns can't be verified by compiler, especially if threads are involved.

The cult like mentality of rust spammers on hackernews is making many people sceptic about it. Rust is actually well designed language for what it does. But stop pretending rust is God.

> Many patterns that rustc refuses aren't inherently wrong. They are because 1) you have to aid lifetime inference and memory management unlike GC languages 2) All safe patterns can't be verified by compiler, especially if threads are involved.

It's not about the patterns being wrong, it's about the patterns being verifiable and having a compiler that's on your side, not on the side of watching the world burn. The difference between C's laissez-faire approach, where no new warnings are added and anything's whatever you want it to be vs. a subset of provably correct things you can opt out of at your discretion.

Yes, it's not going to catch all edge cases, yes it's not perfect, however the idea people are behind is that it represents a fundamental change from "I'm sure the smart engineer knows what they're doing" to "hold on now, let's assume they don't, or will forget in 6 months, or some new person is going to have zero context." That model maps much better to the reality we have vs. the one we wish we had.

My opinion is hardly culty, I write ObjC at my day job at $BIGCO, I've done plenty of Swift, I've written plenty of embedded C, plenty of C++, implemented a ton of stuff in VHDL. Rust is my go-to for personal projects. It's genuinely better. Not perfect, better. And better's what I'm looking for.

Ive always wondered something: comparing to languages like Swift, is Rust really better if it takes so much cognitive overhead and architectural backflips to work around the borrow checker's limitations? Couldnt we be spending that time adding features, or optimizing the parts of the program that the profiler shows us are inefficient?

Using Rust seems like it would make sense for an extremely low-level performance-sensitive application, but do people use it for higher level things? If they do, why?

I think after a while writing the language, you're able to reason about your object memory with little friction from the compiler.

On the Rust-written projects that I work on, I rarely have significant compiler errors that impede on my efficiency in adding new features.

After a while, you know that you're mutably borrowing something, or that you're crossing a thread boundary and are carrying something not thread-safe along.

Maybe like other low-level languages there's a large learning cost, but it gets better after a while.

People definitely use it for higher-level things, and it's nice there as well - not the same level of comfort as a garbage-collected language, but still very nice.

When writing code that isn't that performance-sensitive, cloning is often an option (and gets you past a lot of grief with lifetimes), so is reference counting, etc.

Rust's set of rules just means you can never, for example, accidentally hold a reference to a value that's been freed - it'll error out, and then you can pick whether you meant to borrow it, to share ownership with reference counting, or to clone it.

That's a very good question and deserves its own thread.

Personally, I remember an interview of Keith Haring just before he passed away; he wasn't sleeping much to put as much of his ideas out as quickly as he could, he was about to die. He said something like he'd rather spend the time creating then perfecting his art. I don't know exactly what his words were but what he said made a lot of sense to me.

The popularity of C++ keeps growing for some reason and Swift offers a great dev experience!

On top of that, the layoffs in the Servo team is quite telling about how profitable the work they've put was.

I would pick Rust if I had the choice and libraries were available.

Personally, I've found that the borrow checker for the most part doesn't get in the way. But part of the reason for that is because I've used Rust enough to know what the borrow checker expects, so I would just design things in a way that get accepted in the first place without having to think about it.

Someone new to the language won't have that prior knowledge, and will be more likely to run into the borrow checker and get frustrated because of it.

So with that in mind, I don't really find the cognitive overhead to be high when writing Rust. I also find that I like having the control over what can mutate what, and knowing that information by looking at the function signatures or variable definition. Also, Rust has all of the features I liked in Haskell when I tried it, while putting them into a package that is more familiar and comfortable to me.

Not to get in the way of a good time but - your conversation with opposing viewpoints perfectly illustrates the conflict I'm trying to describe in the article.

Rust will catch mistakes you would've let through, but it'll only agree to verify a subset of all valid programs.

> It's not about the patterns being wrong, it's about the patterns being verifiable and having a compiler that's on your side, not on the side of watching the world burn.

Yeah, but not all programs genuinely need to be multithreaded [0] that too with memory sharing, and even in a program very few data is shared. And a lot of patterns can't be verified by compiler to be amenable for static memory management. That's a tradeoff.

I am not telling rust's cognitive overhead makes it unsuitable for everything. It definitely has a place.

But unlike what a lot of people on HN tend to say, rust is not the perfect language for everything.

Languages like OCaml deserved a significant portion of hype that rust gets now. But there is no mozilla and no HackerNews spamming taskforce behind OCaml. On the positive side, all 5 companies using OCaml pay well ;)

[1] As a user, I don't want your code to exhaust all my cores, unless it is a batch job. I'd rather urge to choose better algorithms and data structures for the job and many times parallelism is just unnecessary.

In my case if I were to use Rust for a personal project, that would be a clear case of thinking inside the box. I think this is because I use C++ a lot and Rust is more of the same, except with fewer libraries & domain support but safer and more restrictive.

For something where one has the freedom to pick anything they want, I'd take advantage and use something more user-friendly and with even less restrictions like Python or Swift. Although for heavy lifting I may still reach for C++ because of the massive ecosystem.

Languages like Rust or Ada with their heavy reliance on specific "annotations" to ensure safety are designed for professional teams that must fulfill certain quality attributes.

Another example from Rust community, without reading the article commenting that Rust is always correct without any bugs or error and programmer is stupid.

This attitude continuously drives me away from learning Rust, didn’t find such attitude in Haskell or Lisp community which really took computer science and art of programming forward unlike Rust, which is similar to other competing niche languages.

Sometimes I get the impression from rust advocate articles on HN that they are snobs. Not here; no way. This was well written, cheeky, thorough, and gave me a solid sneak peak at doing rust from a c/c++/go/python/Java background. The exacting standards of stopping data races at compile time is an exacting task. I think I followed most everything here, although I wondered if the crossbeam inclusion should be in language not library code ... But I don't know enough to press further. Solving problems in libraries not language probably is better.

Rust is one of few if only languages I am aware of that hit hard on data safety without a gc. That'll make it quite different to the programmer.

I'm happy you enjoyed the article! I seem to remember scoped threads were part of the standard library at some point, but they were eventually proved unsound and removed.

I'm too lazy to go find a reference right now but it shouldn't be overly hard.

To be clear, that isn't what I meant, though I can't really edit my comment for clarity. Some things don't manifest the way you intend when converting from thoughts to text.

The original writer is trying to make it appealing for beginners; there are rules, you can learn, you are smart!

He's very positive and encouraging, which shows how much dedication he puts on his teachings.

Relax

Oh, sorry for the confusion, I wasn't criticizing, I really enjoyed the article. I'm working with someone new to Rust at the moment and I'm passing it along to them, too.

That's fine, happens with all of us! Just that we need to be positive, in the end... we are all trying to figure it out, be it Rust...or CSS ;)

Actually this is not a matter of smartness and paying attention. Real world projects expanding over years and decades behave like complex systems and it can be guaranteed that they will have correctness issues.

Furthermore there's always a tension between speed and safety in C and C++ programs which make them particularly prone to these errors.

In fact there are probably many people who are competent enough to write safe C++ code (C's a lot harder), but they code in environments where this is unlikely to happen.

Reply on news.ycombinator.com