Posted by ravenical 14 hours ago
I wish they made something simpler. At least C and C++ have a low barrier of entry and any beginner can write code.
I don't think the borrow checker forced rust to be such a complicated language.
This used to be even more true previously than today. Nowadays, there's stuff like vcpkg, and tons of resources, but I still wouldn't call it straightforward compared to something like nuget or cargo.
It tooke me more time to figure out CMake than entire other programming languages.
APT/dpkg/yast/rpm/pacman/... ?
Make is very simple, you don't even need a makefile. Just type "make main" for main.cpp and it works.
† Default means just that, neither Rust's own compiler nor the Linux kernel need the cargo tooling, but these projects both have actual toolsmiths to maintain their build infrastructure and your toy program does not. There should be a default which Just Works at this small scale.
In reality it matters what you already know, and whether you want to understand deeply or are just interested in enough surface understanding to write software. There's a reason C++ has an entire book about its many, many types of initialization for example.
C/C++ is great at giving that false sense of competence. Then suddenly you're getting a segfault, and you'll never determine why with beginner knowledge, since the crash-line and the mistake-line aren't even in the same zipcode (and or same Git changeset).
Rust forces you to not "skip" knowledge steps. If you have a gap in your knowledge/understanding the compiler will call you out immediately. C/C++ will happily let your dangerously bad code compile and kinda-run, until it doesn't.
I'm not anti-C/C++, I've actually written tons. I love C in particular. But saying that they're beginner-friendly feels wrong, a lot of people quit the language because "random stuff" starts to go wrong, and they lack the knowledge to determine why.
One of my formative memories learning C came after I wrote a function which accidentally returned a pointer to a variable on the stack. It took me about a week to track that bug down. I found it eventually - and then realised the compiler had been warning me about it the whole time. I'd just been ignoring the warnings "while I got my code working". Ugh. The rust borrow checker wouldn't let you even compile code like that.
If you're going to be working in a programming language for years or even decades, I think the extra complexity (and extra difficulty while learning) is an investment that will pay off. But I'd be very happy for rust to stay a niche language for systems software. C#, Go, Typescript and Swift seem like great choices for making webpages and apps.
I think we may safely assume that Rust's designers are smart people that have made every effort to keep Rust as simple as it can be, given its intended use.
Here's rust code:
fn main() {
println!("Hello, world");
}
#include <iostream>
int main() {
std::cout << "Hello World!" << std::endl;
return 0;
}
I feel torn with this sentiment.
On one hand, I totally agree. Rust's "foreign" ideas (borrowck, lifetimes, match expressions, traits, etc) make it harder to learn because there's a bunch of new concepts that nobody has really worked with before. Some of this stuff - lifetimes and borrows especially - really demand a lot of imagination on behalf of the programmer to be able to understand what's actually going on. The amount of thinking I do per shipped line of code seems higher for rust than it does for languages like Go, Typescript and C#. And sometimes C.
On the other hand, I learned C about 30 years ago. Not only have I forgotten how hard it was to learn, but I had the brain of a teenager at the time. And now I'm in my (early) 40s. I'm scared that some of the struggle I went through learning rust came because my brain is old now, and I've forgotten what its like to be out of my depth with a programming language. Learning rust requires shaking up some old neurons. And that's really good for us, but it sucks.
In reality, I think its a bit of both. I've been using rust a lot for about 3-4 years now. Its gotten way easier. But I still prototype a fair bit of algorithmic code in typescript first because I find TS makes it easier to iterate. That implies rust is actually more complex. But, some people pick rust as their first language and it seems to work out fine? I'm not sure.
> I don't think the borrow checker forced rust to be such a complicated language.
Which parts of rust seem complicated? I've found a lot of the things I struggled with at first got a lot easier with familiarity. I love traits and match expressions. I love rust's implementation of generics. I love most things about cargo and the module system. But also, some parts of rust annoy me a lot more now, a few years in.
I disagree with your comment. I think the main source of complexity in rust comes from lifetimes - which are required by the borrow checker. For example, its not obvious when you need to put lifetimes in explicitly and when you can elide them. When does the borrow checker understand my code? (Eg, can you mutably borrow two different elements in an array at the same time?). I also still don't really understand Higher-Rank Trait Bounds.
I also still find Pin really confusing. In general I think async and Futures in rust have some big design flaws. It also really bothers me that there's a class of data types that the compiler can generate and use, which are impossible to name in the language. And some of the rules around derive and traits are annoying and silly. Eg derive(Clone) on a generic struct adds the constraint T: Clone, which is straight out wrong. And rust needs a better answer to the orphan rule.
But in general, if you take out the borrow checker, I find rust to be simpler and easier to read than most C++. There's no headers. No exceptions. No wild template nonsense. And there's generally way less weird magic going on. Eg, Foo(bar); could mean about 8 different things in C++. Rust isn't like that. Rust is simple enough you can just read the standard library, even as a beginner, and its great. C++'s STL is a disaster to read.
Rust is definitely more complex than C. But you do get some lovely features for that extra cognitive overhead. Whether or not thats worth it is up to you. In general - and I've been saying this for years - I feel like the language I really want is rust 2. I can't wait for someone to take rust's best ideas and refine them into a simpler language.
But with Rust, you have to understand almost all of the language very intimately to be a productive programmer, and Rust is not that great at hiding complexity, as in fairly innocious decisions often have far-reaching consequences down the line.
I've seen absolute Rust noobs write production code in Rust, I have no idea where did you get that notion from. Most of the apps I've written or I've worked with don't even need to use explicit lifetimes at all. If you don't need absolute performance with almost none memory allocations, it's honestly not rocket science. Even more so if you're writing web backends. Then the code doesn't really differ that much from Go.
I completely understand your frustration about how common shallow-indignant comments are. But it doesn't help to post shallow-indignant or snarky comments of your own about it - it just produces even more of the same, or worse.
The way to combat shallow-indignant, predictable, tedious, etc., threads is to find something that you're genuinely curious and open about, and post from that place instead.
By “this” I mean “spend all their time fighting against the language/framework because they don’t like it, rather than just picking a different language.”
Eg legacy software, or because your boss tells you, or because of legal requirements, or because of library availability etc.
EDIT: That last sentence is a bit harsher than I intended. I’m trying to convey the importance of professionalism in our work and remembering the experience of working with people who couldn’t do this brought back some bad memories!
You couldn't pay me to work with them
Some programmers think and care a lot about software correctness in a kind of mathematical way. Others just want to ship features and enjoy their lives. Both approaches are fine. They just don't necessarily mix super well.
Some people like to tell you that diverse teams work better. Years ago I worked with someone who had a PhD in psychometrics. She said that's kind of a lie. If you actually look at the research it shows something more interesting. She said the research shows that having a diverse set of backgrounds makes a team perform better. But having a diverse set of values makes a team perform worse. It makes sense. If one person on the team wants to vibe code and someone else wants to make every line of code perfect, you're all in for a bad time.
In rust you have to learn and internalize lot of the non-intutive borrow checker reasoning to remain sane. If you remember to spend a fraction of that effort to remember the "unsafe" things you could end up doing in C, then I think most people would be fine.
But rust enforces it, which is good for a small fraction of all software that is being written. But "Rust for everything!?"..Give me a fucking break!
Nobody is arguing for that though? [1]
I love rust and use it all the time, but personally I think its the wrong choice for application development and web development. And together they make up almost all software jobs. Garbage collectors (like in C#, Java, JS, Go, etc) are fast enough, and they're way easier to work with.
I find system software really interesting. And I think rust is a great systems language! I'd use it in a heartbeat for databases, operating systems and web browsers. Places where correctness, security and performance matter more than creativity and feature velocity. But most people don't work on software like that. I think most programmers shouldn't bother with rust.
---
[1] At least, nobody sensible. I went to NodeCamp about a decade ago when everyone was jazzed on javascript and node. Someone told me - with stars in their eyes - about how amazing everything would be if the whole operating system was written in javascript. I told him that was stupid idea, but he wasn't having any of it. Rust has some of the same people now. Just give it a few years and they'll move on to something else.
Still, the main idea is despite the input files are arbitrarily large, you don’t need an entire file in memory because displays aren’t remotely large enough to render a megabyte of text. Technically, you can only load a visible portion of the input file, and stream from/to disk when user scrolls. Furthermore, if you own the file format, you can design it in a way which allowing editing without overwriting the entire file: mark deleted portions without moving subsequent content, write inserts to the end of files, maybe organize the file as a B+ tree, etc.
That’s how software like Word 97 supported editing of documents much larger than available memory. As you can imagine, the complexity of such file format, and the software handling them, was overwhelming. Which is why software developers stopped doing things like that as soon as computers gained enough memory to keep entire documents, and instead serialize them into sane formats like zipped XMLs in case of modern MS office.
In any case, what you are describing sounds like an ad-hoc re-implementation of virtual memory?
Use a reasonable upper estimate?
> ad-hoc re-implementation of virtual memory?
If you rely on actual virtual memory instead of specially designed file format, saving large files will become prohibitively slow. On each save you have to stream the entire document from page file to actual memory, serialize the document, produce the entire file, then replace. And then when resuming editing after the save, you probably have to load the visible portion back from disk.