Hacker News Reader

Comment by andrew_v4 | Hacker News Reader

I think there is a big ideological element to this. As a Rust outsider, I feel like it's the computer science embodiment of the current political discourse. There is something about the "one true cause" mentality, and the need to co-opt projects with other goals and steer them towards the cause.

Honestly, it is a really weird experience to have around a programming language, and to me is offputting for something that otherwise could have some very interesting merits.

I expect people wont agree with me, and I'm not arguing against the technical merits of the language, I'm just saying that it stands out because of the ideological following it has, and that is cause for concern if ideology is a big reason people try and push to integrate it in something as important as linux.

View on HN

Some of us are mentally scarred from decades of dealing with weak type systems, undefined behavior, and general inability to be sure of what's going on in gargantuan C++ codebases.

Rust was more or less specifically designed to appeal to people like us. Throw a rope to a drowning person and they'll grab onto it hard.

Rust won't make legacy code and legacy coders go away. In fact, as time goes on the amount of crappy legacy Rust code and low-skilled legacy Rust coders will only grow.

So Rust is not a solution.

> In fact, as time goes on the amount of crappy legacy Rust code and low-skilled legacy Rust coders will only grow

But it will make those codebases a lot easier to deal with because the Rust compiler enforces correctness in a myriad of ways that other languages don't. I would much, much rather deal with a legacy Rust codebase than a legacy C++ one.

This isn't true. Or, rather, there are also a myriad of ways that C++ enforces correctness that Rust doesn't.

Legacy codebases are smelly not because of a lack of tools for enforcing correctness. They're smelly because a) programming is hard, and b) a boatload of things are more important than correctness, in the real world.

> I would much, much rather deal with a legacy Rust codebase than a legacy C++

Obviously, because right now legacy Rust codebases are only 5 years old, while legacy C++ codebases are 30+ years old.

But in 20 years it will make no difference. The Rust of 2031 that will need to accommodate 30 years of legacy backwards compatibility will be no prettier than C++ today.

> there are also a myriad of ways that C++ enforces correctness that Rust doesn't.

There are? Like what?

> But in 20 years it will make no difference. The Rust of 2031 that will need to accommodate 30 years of legacy backwards compatibility will be no prettier than C++ today.

I don't really believe this. There are 20 year old Java codebases, and yes they can be a mess and hell to work with, but they're not nearl as bad as C++ ones. And Rust is stricter than Java.

> There are? Like what?

Exceptions, for example.

> There are 20 year old Java codebases, and yes they can be a mess and hell to work with, but they're not nearl as bad as C++ ones.

That's because Java doesn't attempt to solve difficult problems.

Exceptions are terrible for correctness. They introduce hidden control flow paths that developers forget about and fail to handle correctly. (Also they break the "pay for what you use" principle, so C++ is split into two ecosystems, one which uses exceptions and one which doesn't.)

Exceptions are better than magical return values to indicate errors, that's true, but Rust Results achieve the same thing without the downsides of exceptions.

> That's because Java doesn't attempt to solve difficult problems.

Java isn't my favourite language, but that's just silly. GraalVM will do as a counterexample.

> Exceptions are terrible for correctness.

Sometimes they are, and sometimes they are not.

> They introduce hidden control flow paths that developers forget about and fail to handle correctly.

The problem that exceptions solve involve control flow paths that aren't supposed to be handled. Exceptions are not for handling recoverable errors, they are for graceful aborts in a complex, layered and modular program. (E.g., any multi-threaded server, for example.)

> The problem that exceptions solve involve control flow paths that aren't supposed to be handled. Exceptions are not for handling recoverable errors, they are for graceful aborts in a complex, layered and modular program. (E.g., any multi-threaded server, for example.)

For control flow paths that are considered irrecoverable (ie. "this can never happen" branches), Rust has panic!(), which defaults to unwinding the stack, calling Drop implementations (destructors) along the way.

panic!() unwinding only kills the thread it occurs in and Rust's thread-related APIs are designed around preventing data that's been left in an inconsistent state from being observable in other threads without explicitly acknowledging that you're dealing with something like a mutex that's set its "poisoned" flag.

For control flow paths that are considered recoverable, Result<T, E> is basically a way to get checked exceptions which work naturally with higher order functions and have a more concise "call the defined conversion to the specified error return type if necessary, and re-throw" syntax.

If you implement the From/Into interface to define how to convert the error type you received into the error type you're returning, the ? operator will do an "unwrap the Ok value or convert and do an early return of the Err value" in a single character.

A lot of people use the thiserror crate to define their custom error types, which has helpers to makeimplementing the From/Into interface trivial... possibly as trivial as annotating an enum variant with #[from], depending on what you want out of it.

Also, this is from 2005 and chose a "considered harmful" title, but this article makes some good points:

http://www.lighterra.com/papers/exceptionsharmful/

If you restrict exceptions to that case, then Rust has exceptions (panic/catch_unwind). So I'm not sure what your point is.

Fortunately I am mostly able to avoid working on legacy C++ code these days (rr being the exception, and it's only 70K lines).

Rust code accumulates some cruft over time, but Rust's type system and safety guarantees put a floor on how crappy the code can be. The first Rust code I ever wrote is still part of my project five years later; it's less than perfect, but it's free of undefined behavior now just as it was then. The data structure parsers I wrote four years ago look a bit ugly to me now, but are free of exploitable security bugs, and always were. Etc.

> undefined behavior

What does that even mean in the absence of a formal standard and competing compiler implementations? (Hint: nothing.)

If you refuse to define anything then you automatically make the "undefinedness" problem go away. (But not the pain it causes.)

> Rust's type system and safety guarantees put a floor on how crappy the code can be

No. The floor on crappiness is defined by the problem domain. Powerful features allow for powerful takes on crappiness.

Unless you want Rust to stay a teaching language forever, you must necessarily introduce abusable features. (See Python for a real-time slow-motion elaboration of this train wreck if you don't believe me.)

> What does that even mean in the absence of a formal standard and competing compiler implementations? (Hint: nothing.)

Undefined behaviour is stuff that you compiler's optimizers have been promised can never occur, so they are allowed to transform your code based on that assumption.

Here's a post I made on Reddit in 2019 with a list of resources on what undefined behaviour is:

https://www.reddit.com/r/rust/comments/dpxswt/rust_2020_lets...

...and here's the link to an example of what invoking undefined behaviour can do in C++:

https://gcc.godbolt.org/z/0ubnbS

...and here's an explanation of why it does what it does:

https://kristerw.blogspot.com/2017/09/why-undefined-behavior...

(TL;DR: It injects a call to EraseAll because calling Do while it's still null is undefined behaviour, and Do is a static, so the optimizer determines that the only possible answer within the rules it was given is that code outside that compilation unit will have called NeverCalled to set Do = EraseAll before invoking main().)

> What does that even mean in the absence of a formal standard and competing compiler implementations?

It means that when the language designers are asked "what is the behavior of this code (that compiles and doesn't use 'unsafe')?" they never throw up their hands and say "it's undefined behaviour, you must not write that code" (as the C++ definition often says).

They may say "oops, we're not sure what it should do, we need to clarify the language definition and write some tests to ensure the compiler does that". (This happens in C++ too.)

> Powerful features allow for powerful takes on crappiness.

I don't know what this means.

> Unless you want Rust to stay a teaching language forever

A lot of companies big and small are using Rust in production so this is not a compelling premise.

"Undefined behavior" in a C++ context is a legalese feature of the ISO standard. The standard defines, very precisely, the behavior of a compliant C++ compiler. In places where behavior cannot be specified (for logical or practical reasons), the behavior is marked as "undefined".

In absence of a standard effectively every language construct is 'undefined behavior'.

Again, look at Python for a vivid example of this. (We were discussing just this is a neighboring thread: https://news.ycombinator.com/item?id=26826158)

I have zero reason to believe that Rust won't meet Python's fate.

The Rust people don't have a standard and don't understand why they need one; in fact, their lack of standards is somehow touted as a benefit. Apparently, people think that if there is no standard for "defined" and "undefined" behavior that everything is "defined" by default.

(They're absolutely wrong, of course; it's actually the opposite.)

What you seem to be describing is "unspecified behaviour" or "implementation defined behaviour". If your program contains undefined behaviour the compiler makes no guarantees about how your program will behave.

For more see: https://blog.regehr.org/archives/213 and https://raphlinus.github.io/programming/rust/2018/08/17/unde... .

If there is one implementation as the definition then by default all behaviour is defined by the implementation, and hence parent is correct.

No. If we accept your argument then this would be correct:

> In absence of a standard effectively every language construct is 'implementation defined behaviour'.

But the parent said:

> In absence of a standard effectively every language construct is 'undefined behavior'.

Undefined behaviour != implementation defined behaviour. Both of these things exist in C and are separate. You can rely on implementation defined behaviour giving some consistent result on a given, compiler and hardware. You cannot rely on the behaviour of your program if you hit undefined behaviour.

I didn't state 'implementation defined behavior' which encompasses more than the Rust implementation. The Rust implementation defines the behavior, for example signed int overflow.

The "Rust Book" says signed integer overflow to be two's complement in release builds and panic in debug builds: https://doc.rust-lang.org/book/ch03-02-data-types.html

That's clear enough for programmers to rely on. It is nonsense to argue that this is equivalent to C's "the compiler may do anything it wants" just because the "Rust Book" is not called the "Rust Standard" or not "formal" enough.

this magical thinking about standards documents is one of the primary incentives to not have one

It doesn't no, but if I advocate for the language enough and get it used enough, I can guarantee for the entire rest of my career I can maybe avoid ever having to write any more new projects in said languages. I can just avoid jobs where such languages are still used commonly.

Wait ten more years and Rust will become one of these 'said languages'. (Maybe even faster; the Rust people make it their principle to never learn from others' mistakes. There is no way they won't repeat them.)

You're just making stuff up. Most aspects of Rust's design are based on lessons learned from mistakes and good ideas in C++ and other languages. There was a conscious effort to avoid inventing more new things than necessary.

Is it an ideology or is it just a growing consensus that Rust is really as good as everyone says it is? While I can see how it might look ideological, it doesn’t “feel” ideological to me at least. It feels like a few years ago we hit critical mass and crossed the point where enough people feel like Rust is never going away, that people began to really rely on it, and once they showed this work to other people those people liked what they saw and decided to give it a try and Rust is growing organically on the back of “doing the right things” and just generally being “a good language” for so many more things than people are used to.

Yep.

I think Bryan Cantrill's talk from 2018 encapsulates things pretty well:

https://www.youtube.com/watch?v=LjFM8vw3pbU

Bryan is a hardcore C guy, and can write safe and reliable C code. But he has reached the limits of what C can offer in terms of composability and abstraction.

Like Linus, he wants and needs the kind of high performance and dependable behavior for systems programming that isn't possible with a garbage-collected language.

He also wrote a couple of blog posts called "Falling in love with Rust" and "Rust after the honeymoon":

http://dtrace.org/blogs/bmc/2018/09/18/falling-in-love-with-...

http://dtrace.org/blogs/bmc/2020/10/11/rust-after-the-honeym...

This is exactly my perception too.

Sometimes ideologies actually point in the right direction. The hard part is to recognize the gems amid the firehose of truly bad ones.

FWIW, I think the memory safety-first ideology of Rust is worth spreading.

Agreed. Which is why I prefer garbage collected languages. Rustaceans, however, harbor an irrational fear of garbage collection pauses, hence "memory safety-first ideology" built on garbage collection is heresy. The one true path to memory safety nirvana is through the holy borrows checker. :)

I came to Rust for things like sum types, lack of unexpected null values, monadic error handling (Result<T, E>), and the borrow checker's ability to enable the typestate pattern.

(https://cliffle.com/blog/rust-typestate/ for more on what the typestate pattern is but the TL;DR: is "verifying correct traversal of a state machine at compile time". For example, making it a compile-time error to try to set an HTTP header after you've started streaming the body.)

Before Rust, I'd spent 15 years with Python as my preferred language, and I had experience with TypeScript, CoffeeScript, JavaScript, PHP, Bourne Shell, and the "used very little or very long ago, so I forgot" kind of experience with Lua, XSLT, Perl, C, C++, Visual Basic, QBasic, and DOS/Windows Batch Files.

For me, it's purely about Rust reducing the amount of time I have to spend writing Python unit tests to get the level of confidence I want in my codebases without having to put up with the quirks of a pure functional language like Haskell that doesn't put high value on long-term API stability. (And yes, I do use MyPy and type annotations heavily.)

It's also a big boost to the value proposition that, with no garbage collector of its own, it's easy to integrate Rust modules into my PyQt GUIs or Django+Celery web apps using rust-cpython or PyO3. Trying to hand off objects between multiple garbage collectors in the same address space without something like "serialize the whole thing, hand over ownership of the bag of bytes, then deserialize it" is a recipe for pain.

Also, I'd suggest reading the "What makes Rust work" part of https://boats.gitlab.io/blog/post/notes-on-a-smaller-rust/ for an explanation of why garbage collection doesn't solve all the problems the borrow checker does.

I also have extensive experience of every language you mention and I have coded a fair bit of Rust too. I have over 20 years of experience in Python, C, C++, ELisp, Java, JavaScript, etc. Rust forces you to spend time and effort thinking about something that is automatic in high-level languages, namely collection of garbage. It's silly to claim that forcing developers to spend more time on bookkeeping causes fewer bugs.

Testing is orthogonal to typing, and I believe that those who claim that the latter can make up for the former simply do not understand how to test software. Correct typing is the foundation for a correct program, but the lack of type errors absolutely do not indicate a lack of bugs. Logic errors that are not caused by type errors are far more common, far more dangerous, and are not caught by type checkers.

> It's also a big boost to the value proposition that, with no garbage collector of its own, it's easy to integrate Rust modules into my PyQt GUIs or Django+Celery web apps using rust-cpython or PyO3. Trying to hand off objects between multiple garbage collectors in the same address space without something like "serialize the whole thing, hand over ownership of the bag of bytes, then deserialize it" is a recipe for pain.

I've written a binding for CPython in Factor. There is some plumbing work for sure, but no, it is not that complicated. You manage objects created by the foreign memory manager using special tokens. The difficult part is callbacks; host language calling CPython which calls back to the host language. rust-cpython's documentation doesn't mention callbacks at all so I guess it doesn't support it.

> I also have extensive experience of every language you mention and I have coded a fair bit of Rust too. I have over 20 years of experience in Python, C, C++, ELisp, Java, JavaScript, etc. Rust forces you to spend time and effort thinking about something that is automatic in high-level languages, namely collection of garbage. It's silly to claim that forcing developers to spend more time on bookkeeping causes fewer bugs.

Your mileage may vary but, on average, I find the time lost to bookkeeping is dwarfed by the time saved on not having to use testing to verify invariants which are upheld by the type system.

Granted, my coding style in Python was already quite similar to what Rust lends itself well to.

...plus, I just find it more relaxing to code in a language where I can delegate more of that to the compiler's type-checker.

> rust-cpython's documentation doesn't mention callbacks at all so I guess it doesn't support it.

First, rust-cpython is the older, less advanced binding. PyO3 forked off from it to explore more advanced API designs that, at the time, required API-unstable features only available in the nightly Rust but PyO3 now runs on stable Rust.

Second, I haven't tried closures with rust-cpython yet but, for functions, the py_fn! macro is how you wrap a Rust function into something you can inject into a namespace in the Python runtime.

As for calling Python functions from Rust in rust-cpython, you call the run or eval methods on the object which indicates that you've taken the GIL.

I suppose, if closures aren't supported, you could work around it by using methods on a py_class!-wrapped Rust object instead.

Third, I avoid C++ these days and limit my modern use of C to retrocomputing projects. It's just not worth the mental effort to write C in my projects, so I stick to binding things in ways where I get a memory-safe, type-safe binding and someone else can be responsible for stressing out over the correctness of the binding generator.

> Your mileage may vary but, on average, I find the time lost to bookkeeping is dwarfed by the time saved on not having to use testing to verify invariants which are upheld by the type system.

Memory management is orthogonal to type checking. I agree with you that static type checking has advantages but that is not what I meant by bookkeeping. The bookkeeping is Rust's borrow checker, explicit memory management in languages like C, or even weak references in some languages. This is time lost which wouldn't have been lost had the programmer choosen to use a language with tracing garbage collection.

In fact, you can think of automatic garbage collection as the language upholding certain invariants about memory that the programmer otherwise would be forced to ensure themself.

Thus a Java programmer has to think less about memory handling than a Rust programmer. Less to think about means less bugs. You may argue that it is worth it because Rust is faster than Java. I have not seen benchmarks that proves that but, even so, I can count on one hand the number of times Java's gc has caused significant problems even in performance sensitive code.

> Second, I haven't tried closures with rust-cpython yet but, for functions, the py_fn! macro is how you wrap a Rust function into something you can inject into a namespace in the Python runtime.

Right, it's an engineering problem so I'm sure it's solvable in Rust. After all, it was solvable in Factor which is a gc:ed language. My point was that I doubt Rust's lack of gc makes it easier to embed CPython.

...and I'm saying that Rust is the only language where the benefit of using it for its type system has, for me and so far, outweighed the downsides of having to think about memory management.

Java? Pain in the ass with all those non-inferred type signatures and comparatively poor POSIX API integration. Also, I've yet to encounter a Java GUI, AWT, Swing, SWT, or otherwise, that wasn't buggy and sluggish under X11, and the startup time is, in my experience, even worse than the Python-based CLI utilities I'm often migrating to Rust to get improved startup time. (Also, checked exceptions don't compose well with higher-order functions. Monadic error handling does.)

C#? Not as bad as Java, but still doesn't have a value proposition that would make me switch away from Python.

C or C++? No. I use Rust for getting a stronger type system on top of something that's still memory-safe, not its performance. (Aside from the aforementioned "If Rust is offering, sure I'll take faster startup for my CLI tools AND monadic error handling AND explicit nullability".)

Vala? I forgot to mention that I played around with it and it's got all the ills you'd expect of a niche compile-to-C language.

TypeScript on Node.js? Worse than Python+MyPy in pretty much every way that matters to me except for having native sum types.

Haskell? Sorry. You'd have to pay me to code in a pure functional language, even without my dislike for its syntax and the ecosystem's philosophy of not being afraid to break APIs to advance the state of the art.

etc. etc. etc.

Still, as I've said before, I tended to already use Python for stuff that's well-suited to Rust. For example, so far, I've yet to need an Rc or Arc aside from the ones actix-web embeds in its data containers.

...and if I did, I certainly would want something along the lines of the borrow checker double-checking that I'm not introducing data races in threaded code, and a system akin to Rust's for compiler safety checks on non-memory resources managed through RAII.

...plus, it's shamefully rare to find things that match Serde for declarative serialization and deserialization, let alone exceed it.

That said, I'm a "right tool for the job" kind of guy and I still use Python for anything that involves SQL for want of a library like Django ORM or SQLAlchemy+Alembic which abstracts over the difference between SQLite and PostgreSQL DDL, doesn't use the database or a raw SQL file as the authoritative source of truth for the schema, and has a migrations system which auto-generates draft migrations by diffing the authoritative schema against the database.

Rust' memory safety feature includes "fearless concurrency".

Popular GC languages like Java or Go are not able to prevent a class of data race bugs that Rust prevents at compile time. Languages like Haskell of course handle it much better, but are for a multitude of reasons not popularly used in production.

And as the sibling comment points out, GC languages are not applicable everywhere. This discussion is in the context of the first not-C language being added to the Linux kernel. Can you imagine a GC language being similarly considered?

So yes, the borrow checker is amazing. That feeling of satisfaction and confidence when the program finally compiles after a round of serious coding or refactoring is unparalleled among the mainstream languages I've tried so far.

> Rust' memory safety feature includes "fearless concurrency".

Can you give me an example?

Well the set of all programs where garbage collectors can be used is smaller than the set of all programs where manual memory management can be used (either done by the compiler or manually by the programmer). This doesn't counter your point completely, but it bears thinking about.

Reply on news.ycombinator.com