Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This is really interesting, I felt that at first, but not later.

I think Rust may be a trap.

The 'feeling of satisfaction' of making it work according to those strict rules, I think might be a kind of intellectual heroin for developers.

I believe we may be vastly overestimating the value of that supposed 'correctness' - and also don't contemplate that it's only a specific kind of correctness.

Developers are the kind of people that will naturally hone in on solving problems and building things, and our intuition may not be remotely attuned to necessarily creating value. We'll build some 'perfect thing' long before we build some 'useful thing'.

I've become very skeptical of rust for this reason, it's so addictive to a certain personality type that I wonder if there is true reasoning behind the need for hyper strictness.

I don't think we need Rust actually, I think we just needed a 'clean' version of C++ with some nicer things around pointers and that would have been fine.

Edit: Should say I'm not against Rust, it's super cool, and likely has applications. I'm just skeptical of our reaction to it. I think it's 'borrow checker v1.0' and future languages may improve on that.



> I don't think we need Rust actually, I think we just needed a 'clean' version of C++ with some nicer things around pointers and that would have been fine.

The C++ community has tried this approach, and the outcome (viz. the C++ Core Guidelines) while definitely useful was far less "clean" than Rust itself. You're definitely right that some developers overestimate the need for complex solutions, but this failure mode seems rather more common in the C++ community and it's a bit weird to criticize Rust for it.


Funny, I find that 'QT standard C++' with their idioms and core lib to be really quite clean and useful, accidentally it has become my goto variation of C++.


FWIW 90% of my hobby programming is "intellectual heroin". I use Python at work. Let me have my fun with lifetimes and types at home.

But I also agree with the other posters that this is a bit missing the point about what type and memory safety are supposed to achieve.

In all seriousness, if type safety feels like a burden and not an aid, then either you're using the wrong language for the application or the wrong language for the developer.

Don't forget that Rust exists to solve a problem. And that problem for the most part is not web development.


Perhaps it matters where you are coming from? We are using Rust to replace C on embedded. It is a breath of fresh air for that. C++ will work for that, but is not a breath of fresh air. We are shipping better code much faster than the equivalent C.


Yes and no.

You can write a small script or tool in any language, probably even assembly if you have the experience.

Bigger applications, developed by multiple people, and longer-term-maintenance are where it gets interesting.

Then, when you suddenly have to refactor and migrate ten thousands of lines of code, the difference that "strict rules" make becomes very visible.

How Rust will do in this regards only time will tell.


As an author of tens of thousands lines of Rust code, I can answer (instead of time): ease of refactoring (especially huge codebases) is one of the main selling points of Rust. Everything helps you to refactor code safely and quickly: compiler, IDE, tests. You can rename/move/change signatures without ANY fear, even if you are touching “ancient” code used in a lot of places. Even if something is not covered by tests, compiler will catch.


Not to invalidate anything you said, but I think Rust is still too immature yet for a full evaluation.

It needs another lifecycle of the language ("Rust 2") and the same for the wide used libraries before it can be compared to languages like C++, Java in a more meaningful way.


> making it work according to those strict rules

It's not about that. Whole your comment is based on this false statement .




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: