Rust Unpopular Opinion | Hacker News Reader

Rust Unpopular Opinion

35 pointskrischal35 comments

The best part of rust is not coding, it's debugging.

You get about 30 or something number of errors in large project. And you debug, one by one, and one by one. It goes down to 30, 29, 25, 24 .. and with a little patience you get it down to 4, 3, 2, and a error. Sometime you can even increase errors, because there is error around error, but it generally goes down just as quick.

Then you correct the last bug, and it then shows `Finished dev in ## seconds`. And, most probably, your code works just as you expected. No memory bugs, no side stuffs. Sure, there can be logical errors, and it can be corrected. But no hard to know errors. The error message tells you how to correct your syntax error. It's a bit opinionated, but it's good and, at the end of day, it guides you to write a decent code. And finally with `cargo fmt`, and your code looks just as compact and pretty as flawlessly it works.

View on HN

For a really unpopular opinion:

I prefer modern C++20/23 to Rust.

For 98% of tasks Rust is incredible. But modeling those 2% of problems that don't fit neatly into Rusts domain, the level of "unsafe", "PhantomData", and advanced type-system hacks you need feels obscene when I can use some pointers in C++.

Rust also does not have a compelling platform/story baked into the std for low-level asynchronous programming.

High level Mutexes and locks are there, but you're in for a world of hurt if you want to do something like sharded/striped locking, where the actual data being protected isn't directly owned by the lock (see Tokio's "OwnedMutexGuard" for this, thanks to Alex Chi and Victor Yang for telling me about this)

Yes.

Any system like Rust will have corner cases where it is awful.

The simplest example is doubly linked lists, specifically, and any circular data structure in general.

They are hard in any language to get right, but for all its sweat and pain Rust is no help here. C++ is a better choice.

I will openly say I think Rust is an all-around better language. If you are building general-purpose systems software, or just want to write fast software, use Rust.

If you are fiddling with bits, doing low-level concurrency, writing a GC/Memory Manager etc, or have self-referential datastructures like graphs or trees, you're going to have an order of magnitude easier time writing it in C++. (Rust-experts excepted)

Also, the developer experience writing C++ is worse than Rust by miles. Though the tooling (fuzzing, LSP, debugging, sanitizers, etc) is stellar, likewise with Rust.

Try the Rust development experience in Visual Studio or Clion versus C++, specially for stuff like GUI, DirectX or parallel debugging.

CLion is quite good you're right. I think it's the best of any Jetbrains IDE

Visual Studio is also impressive, though I have a bit of bias against it from when it was so slow.

(I know it's not the case now. It has a great debugging experience, that I don't think can be rivalled anywhere else.)

I agree with this, but also sadly note structures like trees are sadly quite common, in the type of code I write anyway. It is a bit of a niggle I have with Rust.

> sadly note structures like trees are sadly quite common, in the type of code I write anyway. It is a bit of a niggle I have with Rust.

Trees are no problem with Rust

It is circular, rather than recursive, data structures that are troublesome

I had to use recursion to build a tree in AoC '22 day 7. I needed to have both a mutable stack of current tree nodes (`cwd` if you like) and the tree structure. Or equivalently a doubly-linked tree, where nodes point at their parent. It was a bit ugly.

In C++ you just write it.

I get why it's hard in Rust, just saying, it really does crop up.

Yes.

It is hard on garbage collection too, circular structures.

Except there is one thing C++ might never get, security culture.

It is already better than C, as WG21 at least acknowledges there are some security issues and has taken multiple approaches to try to fix some of the underlying issues.

However the way defaults are managed, versus the compiler provided frameworks from pre-C++98, are completely the opposite that security minded developers would wish for.

The NSA cybersecurity bill seems to finally have hit home that this needs to change, however it remains to be seen if those at ISO that care about it will be able ot steer the ship around with their paper proposals like P2657R1, P2723R0,P2687R0.

Bjarne keeps adocating the adoption of Core Guidelines and static analyzers improvements, which in a world where clang struggles to catch up, seems to have quite low priority in tooling improvements.

In a way I guess it depends how relevant many key C++ frameworks and workloads (HPC/HFT/games/LLVM/GCC/FPGA/GUI) will evolve and what Rust can manage to take over.

For an even more unpopular opinion:

I find the syntactic verbosity of Rust absolutely appalling:

fn fmt(&self, _: &mut Formatter<'_>) -> Result<(), std::fmt::Error> {}

Surely this monstrous code has advantages over C(++) but in no world would I voluntarily write code in this language if other options were viable. I don't get how people prefer this language outside of a very narrow application context where the lasts millisecond of optimization matters.

It's easier to read if you split it into tokens and qualifiers. The & is a reference. The '_ is a lifetime parameter. The things in the <>are types. So this is a function which doesn't mutate self and takes a mutable reference to a formatter with a sensible lifetime and returns a result which will contain either nothing (or a unit) or an error if things fail.

Thank you for posting this. I had to google and read up some things.

I think most of the gratuitous verbosity comes from qualifying smt::fmt::Error. If you import it, it becomes

    fn fmt(&self, _: &mut Formatter<'_>) -> Result<(), FmtError> {}

But the common practice is to have an alias Result<T> to mean Result<T, whateverErrorWeAreDealingWith>. This doesn't really maps well to doing impls in the Debug trait, since this trait uses an error that is generally different from the error defined by your own application, but with some care, it can be used. Then it becomes:

    fn fmt(&self, _: &mut Formatter<'_>) -> Result<()> {}

Okay, but what about the whole rest? it's syntactically heavy, but each part of it is very significant.

Take the <'_>. It means that the Formatter struct receives a lifetime parameter but you opted to explictly omit it. In previous Rust editions, you would keep it implicit

    fn fmt(&self, _: &mut Formatter) -> Result<()> {}

But this was confusing and ambiguous! People looked at it and sometimes didn't know there is a lifetime involved - until it showed up in compiler error messages!

Now, there's two elided lifetimes in this snippet: one in the &self and one in the &mut. Rust has clear rules for this case: your snippet means

    fn fmt<'a, b>(&'a self, _: &'b mut Formatter<'_>) -> ...

Once you learn the rules (and here are the rules https://doc.rust-lang.org/nomicon/lifetime-elision.html), this makes the syntax slightly lighter. It's not an issue like the other case because if you know the rule, it's not ambiguous.

The _ in place of the variable name is there just to not give a name to the formatter. It's actually a catch-all pattern (like one in the end of a match). If you wanted to give a name but disable the unused lint, you would write _formatter instead.

The rest, I can't really remove much sacrificing the semantics. The only superfluous thing I love is the ->, which is much better than the C convention of putting the return type before the function name (IMO).

The <> syntax itself for generic parameters sucks, and it's about the worst thing that Rust inherited from the C++ syntax. The :: also sucks, and it's also from C++ (the turbofish ::<> combines both, and it was Rust's brainchild. https://turbo.fish/ [0]) Actually most C++ influences on the Rust syntax is a disaster. I would much prefer to have a Haskell-inspired syntax for types, so that the type Result<A, Box<C>> would be written Result A (Box C)

[0] there were multiple attempts to remove the turbofish from the syntax. this thread has a discussion of it https://news.ycombinator.com/item?id=26019053 - also see https://www.reddit.com/r/ProgrammingLanguages/comments/fe3yg...

I've found that a lot of folks writing Rust don't seem to grok lifetimes, especially the rules around elided lifetimes.

I see a lot of manually-written elided lifetimes.

> The only superfluous thing I love is the ->, which is much better than the C convention of putting the return type before the function name (IMO).

For what it's worth, C++11 supports that syntax:

    auto thing(int a, bool b) -> string;

If the auto isn't the return value (supposedly string is).. then what does it means?

To be honest, my reasons for preferring Rust have little to do with any of this. Yes I think Rust is a nicer language, but it also does get in the way a bit more than C++.

The real reason is that C++ feels ancient and creaky. Packaging? Nope. Build system? Yeah, set it up yourself. Easy to use build tools? Erm no. Reasonable error messages with templates? Lol.

Macros and templates feel both central to the language and like hacks. Syntax is also borderline unreadable; double ampersands, lambdas all look like a cat walked across the keyboard.

I'm not hating on C++, I have many happy memories of using it, but Rust feels just so much user friendly.

I really wish C++ also had a standard package manager like cargo or npm

Like in many things in C++, you get to choose.

Conan, vcpkg, NuGet, Hunter, CMake Packages,...

Most of them even support binary dependencies, contrary to cargo (currently).

Except that isn't a feature from Rust, rather from ML linage of languages since it was designed in 1973.

It just happens that many never used any other ML inspired language, so they attribute those capabilities to Rust.

For more super debugging powers, try the Design by Contract features in the 'contracts' crate:

https://crates.io/crates/contracts

That is an awesome crate!

At this point data on Android bugs shows that Rust clearly won.

Also if we don't want government spying easily on all our devices (even open source ones), we all have to take safety seriously.

Partially, Android team still doesn't have any public roadmap to support Rust for writing apps.

Thus anyone that wants tooling support in NDK and AGDK at the same level as C and C++ have to do the whole integration themselves.

Android and Visual Studio plugins, project templates, mixed language debugging, APIs, JNI bindings generation, ...

No doubt this is eventually come, maybe something for Google IO this year.

> Sure, there can be logical errors, and it can be corrected.

Yeah, but the vast majority of my bugs in C projects were logical errors :-/

Logical errors outnumber memory errors at roughly 100:1

The problem is memory issues are extremely toxic. They hold the ability to completely derail the program and do just about anything.

This is a measurement error: the idea behind Rust is to make the ratio between logic and memory errors infinite, by eliminating memory errors as a bug class (to a vanishing degree, anyways).

Besides, logic errors in Rust don't cause memory errors as knock-on effects. Most of my logic errors in C and C++ codebases ultimately manifested as some form of unsound memory access.

It's quite easy to accidentally segfault a C++ program. IME so far it's much harder to accidentally segfault a Rust one.

Even unwrap et al are useful, because they show you explicitly where you assume something potentially unsafe is happening.

> Logical errors outnumber memory errors at roughly 100:1

Mēh! Possibly.

But you can catch logic errors with logic tests.

Catching memory errors is a different problem.

Is it though? Usually it's just using valgrind...

> Usually it's just using valgrind...

Just? Valgrind is hard work on large systems

Better to avoid the problem. Either via the Rust way, or with a garage collector

What you're talking about is more like lint checking than debugging. I thought you meant debugging a running application.

There’s nothing unpopular about this. In fact this is the most popular opinion on HN.

This is unpopular? XD

Wait until the frameworks spoil it

Reply on news.ycombinator.com