Hacker News Reader

Comment by paulgb | Hacker News Reader

I don't get it, where's the bloat here? By using consistent rules across the language, Rust is requiring developers to keep less in their head. The author acknowledges this:

> Newer users find Rust easier to use and more consistent; they don’t have to learn the “edges” of where one thing works and where it doesn’t.

E.g. currently, Rust users have to know that if they want to use async on a trait, they need to add a dependency to the async_trait crate. Soon they won't.

View on HN

I have primarily worked on kernels written in C during my career, but I read through the official Rust book and wrote a small microkernel using Rust and my opinion is that Rust is already everything I hate about C++. It's already a huge language with a large upfront learning curve and there's no hope of mastering it as it's already grown so large that it could never fit in one person's head. Instead of focusing on solving my task I'm often thinking about how to deal with the language itself - a hallmark of large languages that promise the world if you just takes days learning about higher kinded type systems.

C has innumerable problems, but at its root it's a simple language that is easy to learn, and it's been fabulously successful because it's small and *doesn't* try to abstract too much over the architecture you're working on. My feeling is that Rust is being pushed by people who write application level code because they heard that C was bad and programmers are simply enthralled by overcomplicated programming languages because it gives them something to read about.

I agree that Rust is a large language, but I think you're overstating the complexity: it's been my experience that you don't need to know all (or even most) of the "clever" stuff to write large, performant Rust programs.

It's generally true that you can spin engineers up quickly on C, because it looks like a simple language. But that's because C translates static program properties into dynamic ones, and expects engineers to spend years of their careers chasing down the same handful of bug classes that Rust eliminates outright. In other words: C externalizes the learning curve (and makes engineers pay for it in blood and tears).

> C has innumerable problems, but at its root it's a simple language that is easy to learn, and it's been fabulously successful because it's small and doesn't try to abstract too much over the architecture you're working on.

Except for the C abstract machine, which bears no particular resemblance to 99.9% of the machines that C programs run on. Every kernel that I'm aware of is stuffed with nonstandard code and nasty hacks to keep optimizing compilers from correctly (per C abstract semantics) optimizing out code.

> I agree that Rust is a large language, but I think you're overstating the complexity: it's been my experience that you don't need to know all (or even most) of the "clever" stuff to write large, performant Rust programs.

The same could equally well be said for, say, scala. In my experience though, you always pay one way or another for the unneeded and unwanted features in a language. Unreasonable compile times that kill joy and productivity are just one of the ways.

I've heard this argument many times from Rust enthusiasts, most of whom do not work in C, C++, or even write system level software. Of the kernels that I have worked on, the Linux kernel core is very high quality C (even if many of the drivers are not), and other large parts of the stack like grub and systemd are also written in C and yet the sky isn't falling for users around the globe (and on other planets).

The Linux kernel has a constant stream of fairly severe, exploitable bugs caused by memory safety errors, not to mention non-exploitable bugs that lead to system instability or even data loss.

Just a few months back there was a bug that allowed any completely unprivileged user to elevate straight to root using a combination of unprivileged user namespaces and cgroups. Other than RCE or severe data loss, I would say this is one of the most severe forms of bugs possible in a kernel. For some period of time the kernel's basic security features were completely ineffective, and this is possibly one of the most widely used kernels in the world!

Severe security related bugs are really common with our OS's and user space software, and we just pretend that it's not a problem. When your kernel can't even offer basic security isolation between users in a reliable manner, when visiting a malformed website with your browser results in arbitrary code execution, or when a malformed message sent to you phone can completely own it, I would say there is a serious problem.

I can't speak for that group. I've been doing systems programming in C for about a decade now, and C++ for about half a decade; that includes both kernelspace programming and compiler development.

I'm not claiming that the Linux kernel core isn't high quality (or is, for that matter). I'm claiming that the kernel maintainers increasingly have to resort to all kinds of extensions and tricks to keep optimizing compilers from simply deleting their code, because nothing about C's semantics reflect the "bare metal."

> the Linux kernel core is very high quality C

The Linux kernel core is the product of decades of effort by thousands of people, many of them world-class experts in the relevant domains. Very, very few software projects receive anything close to that.

No one is claiming that writing safe C code is impossible; the problem is that writing unsafe C code is easy.

And the Linux kernel is introducing Rust code [0] due to the fact that even Linus Torvalds acknowledges that Rust solves issues that would be prevalent in C code.

[0] https://www.zdnet.com/article/linus-torvalds-rust-will-go-in...

Hi, I work in C professionally

A couple years ago I rewrote thousands of lines of Javascript into Rust (game engine & corresponding game server): https://www.reddit.com/r/rust/comments/k3jy5g/i_rewrote_10k_...

Overall I don't think Rust is a silver bullet, but it works effectively as a high level manual memory management language. Whereas when I had to work on C++ code I was running into messes where lifetime issues were undefined behavior instead of compiler errors

I'm curious why you think it's too big to master. There's certainly a lot to the language, but it's design means that these various facets are largely contained to their area of effect. I'd be confident in the assertion that most rust developers don't need to understand much more than the basics of the type system, traits, lifetimes, and the surface levels of async.

The biggest benefit to the language is precisely that all the Lego pieces fit together and you simply don't need to worry about (in Lego parlance) "illegal moves". Whenever I write C or C++, I'm constantly worrying about whether or not I'm doing something incorrectly and potentially writing dangerous code. In rust, this mostly disappears and you can focus on the actual problem domain you're working in rather than computer science problems.

> I'm curious why you think it's too big to master.

Many of us do find Rust very hard to get to grips with, however much we're informed by Rust advocates that it isn't! I don't know if there's any readily available way to be objective about this? I think all we have is attestation. Here's Chris Keathley (of some Elixir fame):

> I've written a non-trivial amount of Rust code (50-100k lines) .. and I feel like I barely understand Rust as a language

I don't think that's an uncommon perspective.

It's entirely reasonable to have trouble getting to grips with Rust, as ownership and borrowing are quite different paradigms compared to the usual mainstream languages that people tend to know. But there's no way to write "50k lines" of Rust without saying that you understand the language, so I'm baffled by what the author is trying to imply there. If you don't understand the language, then you won't even make it to 1k lines.

I didn't find anything tricky about the ownership model. The last two languages I learned were Clojure then Elixir, both of which had far more concepts novel to me (with no experience in Lisps nor functional languages), yet neither gave me the trouble Rust has.

Frankly your response is typical of the smugness I find with Rust advocates. You 'know' Rust isn't complex (perhaps because of your own experience). When people say they find it so, you consider it your role to inform them about how they are mistaken about their own experience.

Reply on news.ycombinator.com