Hacker News Reader

Comment by ilovecaching | Hacker News Reader

This is why Rust will eventually become the next C++ - it's becoming just as bloated with type theory, a cumbersome syntax, and will eventually ignite a begrudging dislike by the people that have to find a subset of the language to make sense of just to write simple programs. Everything about this language is overcomplicated by language enthusiasts.

The best thing for Rust over the next few years is for it to fall to the wayside while saner approaches like Hare and safer C syntaxes take center stage.

View on HN

As someone who generally prefers high level languages (Ruby, Python, JS) I'm enjoying Rust because unlike C and Cpp, I don't really have to care about memory. I don't want to spend my time thinking about memory allocations and deallocations.

Rust lets me focus on logic like a high level language does and the compiler tells me whether what I'm doing is memory safe or not. I'm vaguely aware of copying/cloning values, but Rust is pretty performant out of the box and I don't end up doing it very often.

If you don't need to care about vm, you probably should be using a GC language. If you do, you certainly need to understand vm.

vm = virtual machine/memory?

I'm porting this Python library to Rust: https://github.com/Blizzard/s2protocol.

For the shitty, first pass prototype code I've written so far I've seen a ~30-40x speedup compared to the Python implementation and a ~2x speedup compared to a Go implementation written by someone else: https://github.com/icza/s2prot.

That is why I chose Rust over a GC language like Go (E: I also wanted to learn it ofc). It's a lot faster out of the box, even without me having a strong understanding of memory operations.

Virtual memory != Memory management, your abbreviations are confusing.

Sorry, I don't normally work outside of the kernel. To me vm is a common abbreviation with a well understood meaning.

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.

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.

It already is the next C++. It's a powerful language full of incredible abstractions but sadly that attracts incredibly smart developers who worship at the altar of complexity.

I enjoy rust for what it is, and I've had fun writing programs in it. You couldn't pay me to work with it in a professional capacity involving peers. I'll stick to Go, where my code reads and writes like everyone else's.

But Go can’t be used for all low level programming. Of course a GCed language is easier to read, it’s simpler at the cost of performance.

Rust complexity is more of a debate about low level programming below Go. Where only C/C++ and Rust exist. Can there be a simpler language in that space?

> Can there be a simpler language in that space?

Maybe not. The problem is that you have to have a language powerful enough to do all the things, even the things that haven't been thought of yet. That means, basically, that you have to be able to manipulate raw memory. You can't depend on a library or a language built-in, because you have to be able to write the library, and do things for which the builtin doesn't exist yet.

And then you have the problem of not blowing yourself up with that power. That comes with 1) all the danger of C, 2) all the complexity of C++, or 3) all the difficulty of the borrow checker in Rust. If a fourth language appears with the necessary power, it's going to have equivalent drawbacks.

Of course it can, there are companies shipping products written in bare metal Go.

https://www.withsecure.com/en/solutions/innovative-security-...

https://github.com/usbarmory/tamago

There are far more languages in that space than just C and Rust. Zig is one of the more recent examples, but e.g. Ada is also around, as is Delphi and many others.

That's why I don't think it's worth dropping modern C++ for it. Only major thing C++ was missing that I wanted is modules.

Yeah you have to have high enough agency to use a subset of the language, but so what?

I dont plan on having 300 interchangeable human NPCs smashing keys on it, like Go was designed for.

I can imagine a very similar argument being made for punch cards.

How hard is it to minimize inheritance, use containers in standard library, and use smart pointers though?

That's 90% of the difference between pre-c++11 and post-c++11 best practices. And a couple other "dont do this" rules.

Reply on news.ycombinator.com