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.
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.
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.
> In addition to meeting the Open Source Definition, the following standards apply to new licenses:
> (...) The license does not have terms that structurally put the licensor in a more favored position than any licensee.
https://opensource.org/licenses/review-process
That's a funfact I learned from IP lawyer when discussing possibility of open-source but otherwise LLVM-extempt license. If there is extemption (even in LLM) such license is most likely OSI-incompatible.I think fighting the borrow checker is more like a rite of passage. Rust is not my favorite language but the borrow checker is great.
Evidently millions of people want broken garbage, Herb Sutter even wrote a piece celebrating how many more C++ programmers and projects there were last year, churning out yet more broken garbage, it's a metaphor for 2025 I guess.
Hence, they use GC'd languages like Go whenever they can.
Haskell (and OCaml etc) give you both straightjackets and a garbage collector. Straightjackets and GC are very compatible.
Compared to C, which has neither straightjackets nor a GC (at least not by default).
Except Rust's straightjacket is so tight it obstructs blood circulation to the brain.
> Straightjackets and GC are very compatible.
Of course, if the straightjacket induces vertigo it should be taken off. Doctors say straightjackets should be used sparingly.
(Yes, I agree that Rust is missing an automatic GC.)
Only if you’re insane.
Just don't accidentally step on any of these landmines and we'll all get along great.
This is a binary assumption that you can understand to evaluate to "true" in the absence of a borrow checker. If it is "false" it halts the compiler
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.
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.
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.
† 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.
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.
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 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.
https://www.reddit.com/r/rust/comments/1q0kvn1/corroded_upda...
As a follow on to the corroded meme crate:
https://github.com/buyukakyuz/corroded
> What Is This
> The rust compiler thinks it knows better than you. It won't let you have two pointers to the same thing. It treats you like a mass of incompetence that can't be trusted with a pointer.
> We fix that.
fn main() {
let a = String::from("hello");
let b = a;
println!("{a}"); // Works! Prints: hello
}
This is not “I have correct code but Rust can’t tell it’s correct.” This is “wow, this code is intentionally outrageously wrong, obviously dereferences a pointer that is invalid, and happens to work anyway.”In rust you don’t have a garbage collector and you don’t manually deallocate - if the compiler is not certain of who drops memory and when, what happens with those ambiguous drops ?
In other words, are the silenced errors guaranteed to be memory leaks/use after frees?
boxed•2h ago
poly2it•2h ago