10 ms·
Rust--: Rust without the borrow checker
- deleted 9mo ago[deleted]
- boxed 9mo agoA motivation section in the readme seems like it is needed.
- poly2it 9mo agohttps://github.com/buyukakyuz/corroded/issues/11#issuecomment-3700624666 https://github.com/buyukakyuz/corroded/issues/11#issuecommen...
- corrode2711 9mo agoYes, that was my motivation.
- bhaney 9mo agoAre the compile times noticeably faster?
- worldsavior 9mo agoProbably not, because it seems like it still checks for errors but just suppresses them.
- misnome 9mo agoEven so, the borrow checker repeatedly profiles as an insignificant part of compile times, so wouldn’t make a difference.
- throwawayffffas 9mo agoC++ with extra steps?
- corrode2711 9mo agoC++ with a package manager.
- dorianniemiec 9mo agoUh oh, this might look like a potentially memory-unsafe version of Rust...
- mkl95 9mo agoRust++ would be a nicer name then
- dorianniemiec 9mo agoRust++? :)
- thushanfernando 9mo agoBust?
- corrode2711 9mo agoBust++
- petcat 9mo ago[flagged]
- scott_w 9mo agoHonestly, I thought it was serious because I’ve seen people do things exactly like this, just in different languages. 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.”
- eru 9mo agoThere can be good reasons for choosing a language that you otherwise don't like. Eg legacy software, or because your boss tells you, or because of legal requirements, or because of library availability etc.
- scott_w 9mo agoThose are excellent reasons but then you shouldn’t fight the language, you should go with the language/framework conventions as much as possible. Trying to fight the language design will only lead to buggy, hard to understand code, so either suck it up or get a different job. 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!
- MangoToupe 9mo agoCertain people feel very emotional about the compilers and interpreters they use You couldn't pay me to work with them
- josephg 9mo agoDon't worry, they probably wouldn't want to work with you either. 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.
- fithisux 9mo agoThis should be called trust, because it does view the developer as evil.
- fithisux 9mo agoI meant "it does not view"
- gspr 9mo agoTangentially related: the opposite, Rust's borrow checker sans the compiler, is actually very useful. As far as I understand, the borrow checker is a significant part of the work of writing a Rust compiler. Therefore, having the official borrow checker available as a standalone program can make alternative compilers (e.g. for exotic hardware) feasible faster, because they won't need a borrow checker of their own from the get-go.
- tialaramex 9mo agoWhy would this matter? The borrowck is (a) not needed during bring-up because as its name suggests it is merely a check, so going without it just means you can write nonsense and then unbounded undefined behaviour results, but (b) written entirely in Rust so you can just compile it with the rest of this "exotic hardware" Rust compiler you've built.
- gspr 9mo agoYeah, you're right, I'm misremembering something here. Thanks for the correction.
- bananaflag 9mo agoI get your point, but still you haven't identified a use for the borrow checker sans the compiler.
- raluk 9mo agoWhat are protental issues with compiler, by just disabling borrow checker? If I recall correctly some compiler optimisations for rust can not be done in C/C++ because of restrictions implied by borrow checker.
- 0xdeafbeef 9mo agoRust can set restricts to all pointers, because 1 mut xor many shared refs rule. Borrow checker empowers this. https://en.wikipedia.org/wiki/Restrict https://en.wikipedia.org/wiki/Restrict
- imtringued 9mo agoThe crazy part about this is that (auto) vectorization in Rust looks something like this: iter.chunks(32).map(vectorized) Where the vectorized function checks if the chunk has length 32, if yes run the algorithm, else run the algorithm. The compiler knows that the chunk has a fixed size at compile time in the first block, which means it can now attempt to vectorize the algorithm with a SIMD size of 32. The else block handles the scalar case, where the chunk is smaller than 32.
- collinvandyck76 9mo agoHah I love things like this, where the compiler leaks out.
- vanviegen 9mo agoWithout the borrow checker, how should memory be managed? Just never deallocate?
- flohofwoe 9mo agoIt would be the same as in any language with manual memory management, you'd simply get a dangling pointer access. The 'move-by-default' semantics of Rust just makes this a lot trickier than in a 'copy-by-default' language though. It's actually interesting to me that the Rust borrow checker can 'simply' be disabled (e.g. no language- or stdlib-features really depending on the borrow checker pass) - not that it's very useful in practice though.
- nineteen999 9mo agoLove the "Note for LLMs" and the NSFW license.
- user3939382 9mo agoRust- is you use C with ring buffers. If you think you need dynamic memory allocation your program is underspecified.
- oskarbh7 9mo agoHow does "zero dynamic allocation" work in practice for something like a text editor IE. vscode or other apps that let users open arbitrary files?
- lpcvoid 9mo agoJust impose a maximum buffer size ;)
- Const-me 9mo agoIt’s technically possible to do, just very complicated and hard. Quite often, prohibitively so. 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.
- eru 9mo agoWhat if you don't know ahead of time how big that monitor is that you are displaying stuff on? In any case, what you are describing sounds like an ad-hoc re-implementation of virtual memory?
- throwawayffffas 9mo agoIt would be great if it only allowed multiple mutable borrows. That's the only one that always bugs me, for mostly innocuous stuff.
- threethirtytwo 9mo agoThis isn’t actually unsafe unless shared across threads right? Maybe the borrow checker needs to be more nuanced to differentiate this rather then outright banning it all together. It would increase the logic of the borrow checker by a lot though.
- aw1621107 9mo ago> This isn’t actually unsafe unless shared across threads right? Multiple mutable borrows do not need multiple threads to cause UB. Consider the following: fn main() { let mut v = vec![0, 1, 2]; let e = &mut v[0]; v.push(3); *e = 4; } rustc refuses to compile this code due to multiple mutable borrows of `v` [0]: error[E0499]: cannot borrow `v` as mutable more than once at a time --> <source>:4:5 | 3 | let e = &mut v[0]; | - first mutable borrow occurs here 4 | v.push(3); | ^ second mutable borrow occurs here 5 | *e = 4; | ------ first borrow later used here If rustc allowed multiple mutable borrows here, `v.push(3)` would cause the underlying vec to reallocate, which invalidates `e`, and so `*e = 4` would cause UB. [0]: https://rust.godbolt.org/z/bsxKTWG3K https://rust.godbolt.org/z/bsxKTWG3K
- xlii 9mo ago> 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.
- w4rh4wk5 9mo agoI am wondering whether this would actually be a helpful compile option in upstream rustc for quick prototyping. I don't want prod code to use this, but if I want to try things out during development, this could substantially shorten the dev cycle.
- 0xdeafbeef 9mo agoWhat the point, though? You will get compiling code, but later you would need to reachitecture code to avoid violating rust rules.
- withinboredom 9mo agoSometimes, you just need to know if an idea will even work or what it would look like. If you have to refactor half the codebase (true story for me once), it makes the change a much harder sell without showing some benefits. IE, it keeps you from discovering better optimizations because you have to pay the costs upfront.
- eru 9mo agoCan't you usually just throw some quick referenced counted cells in there, to make the borrow checker happy enough for a prototype without refactoring the whole code base?
- LoganDark 9mo agoIn Rust, it's a lot easier to refactor half the codebase than it would be in another language. Once you're done fighting the compiler, you're usually done! instead of NEVER being sure if you did enough testing.
- withinboredom 9mo agoI can’t tell if you missed the whole point of “exploratory”…
- 9mo ago
- ismailmaj 9mo agoundefined behavior on steroids be like:
- hacker_homie 9mo agoI wish I could make the borrow checker give warnings not errors. It would make exploration so much easier, so I don’t have to fight the borrow checker until I know how to build what I want.
- hoppp 9mo agoThen you have code full of warnings and undefined behavior? 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.
- dataflow 9mo agoThis can't possibly be guaranteed to work just by disabling the checker, can it? If Rust optimizes based on borrow-checker assumptions (which I understand it can and does) then wouldn't violating them be UB, unless you also mess with the compiler to disable those optimizations?
- tialaramex 9mo agoIf you write correct Rust code it'll work, the borrowck is just that, a check, if the teacher doesn't check your homework where you wrote that 10 + 5 = 15 it's still correct. If you write incorrect code where you break Rust's borrowing rules it'll have unbounded Undefined Behaviour, unlike the actual Rust where that'd be an error this thing will just give you broken garbage, exactly like a C++ compiler. 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.
- ozgrakkurt 9mo agoI have been using kde for years now without a single problem. Calling cpp garbage sounds wrong.
- LtWorf 9mo agoPeople who can't do something, sometimes assume nobody else possibly could.
- andrewshadura 9mo agoI don’t have a slightest idea why would anyone want this. Borrow checking is one of the greatest benefits of Rust.
- Someone1234 9mo agoIt is funny.
- jokoon 9mo agoTo me it feels like rust is barely readable sometimes. When I read some rust cost, I am often incapable to guess what it does, so it does not feel intuitive. 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.
- mentalgear 9mo agoI can just second that. Maybe someone (or some LLM) can write a nice superset of Rust that is more readable - so the barrier of entry drops significantly and we can all write better, more efficient and memory-safe code!
- torginus 9mo agoI feel exactly the same - C++ might be a much more complex and arcane language when you consider its entire feature set, and all the syntactic machinery (I figured out by looking at STL or Boost code, just how much of C++ I don't know or understand), you can choose to not engage with most of the language. Hell, even stuff like unique_ptr is optional when you're just starting out. 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.
- mrits 9mo agoI've shipped a lot of Rust software without the understanding or even attempting to learn a lot of the language. There is plenty of things in core libraries around traits that I have no idea how they work or really care.
- drogus 9mo ago> you have to understand almost all of the language very intimately to be a productive programmer, 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.
- ViewTrick1002 9mo agoFor everyone unaware, this repo is a meme: https://www.reddit.com/r/rust/comments/1q0kvn1/corroded_update_rust_now_i_removed_the_borrow/ https://www.reddit.com/r/rust/comments/1q0kvn1/corroded_upda... As a follow on to the corroded meme crate: https://github.com/buyukakyuz/corroded 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.
- amluto 9mo agoIt does seem like satire. The very first example is: 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.”
- 1718627440 9mo ago> this code is intentionally outrageously wrong Can you explain why? Why can't both a and b point at the same string object? Does `let b = a;` do something like a destructive move?
- gpm 9mo agoI'm not 100% sure the semantics here are nailed down - but I think there's no guarantee that `a` continues to exist after assignment to `b`. The value in it has been moved out of it after all... The memory which was used for the variable `a` can probably be re-used for something else, e.g. for some inlined variable used by `println!`... In normal rust `let a = b` where the variable is of a non-Copy type (including String) is "destructive" in the sense that you can no longer use b. The question about semantics in normal rust turns to "so if I have a raw-pointer to a hanging around and use unsafe code to copy the value out of it what do I get" and I'm not 100% sure... but I think the answer is probably it's a use after free and you get undefined behavior. The rust-- version is basically just this except you don't have to explicitly make that raw pointer to read the old memory.
- torben-friis 9mo agoI’m not picturing how it works. 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?
- eru 9mo agoI don't think so, I don't think Rust's borrow checker is free of false negatives.
- gliptic 9mo agoThe borrow checker doesn't decide when things are dropped. It only checks reference uses and doesn't generate any code. This will work exactly the same as long as your program doesn't violate any borrowing rules.
- torben-friis 9mo agoNo, I get that from an architectural perspective they are separate processes. The point is, unlike in other languages, the compiler is developed assuming the input has been borrow checked, right? So it is surprising to me that it doesn’t blow up somewhere when that invariant doesn’t hold.
- masklinn 9mo ago> So it is surprising to me that it doesn’t blow up somewhere when that invariant doesn’t hold. The final program may be broken in various manners because you don't respect the language's prescribed semantics, in about the same way they do in C and C++. From the compiler's perspective the borrow checker validates that rules it assumes are upheld are actually upheld. mrustc already compiles rust code without having a borrow checker (well IIRC recent-ish versions of mrustc have some borrow checking bits, but for the most part it still assumes that somebody else has done all the borrow checking).
- pornel 9mo ago
- tmtvl 9mo agoAmazing, this is like the bizarro version of what I'd want. Like someone said 'hey, there's this kinda crappy language with a really cool feature, let's not make a great language with that feature, but instead take the crappy language and remove the cool feature which is the only thing keeping it from being trash'. Okay, sure, tagged unions, closures, and hygienic macros are nice; but there are plenty of other languages with the first two and when your syntax is atrocious even the most hygienic macro is going to look like something that crawled out of the sewer at R'lyeh.
- p0w3n3d 9mo agoThere are easier ways of making segfault than writing a custom compiler.
- NooneAtAll3 9mo agoI'd prefer the opposite - borrow checker, but remove the useless "fn" and "let" keywords
- reverseblade2 9mo agoShould be named in rust we don't trust
- 0xMohan 9mo agoI'm assuming it's a meme project. In case it isn't, what's the point? Just trying to understand. Isn't rust's one of the main selling point is the barrow checker right? Also how's the memory is handled? I know it'll drop every thing once it's out of scope but it seems you can make copies as much as you want. Looking at the loop example, I feel like this introduces memory leaks & undefined behavior.
- joelthelion 9mo agoI would actually enjoy that for certain small projects. Rust without the borrow checker is a very elegant language. The borrow checker is great, of course, but it can be a pain to deal with. So, for small projects it would be nice to be able to disable it.
- estebank 9mo agoInstead of disabling the borrow checker what should be possible is to promote borrows to Rc/Arc as needed. I would want to restrict this mode to one where it can only work locally, never publishable to crates.io. It would be particularly useful when running tests, then instead of a compile error you can also get a runtime error with better information about the cases the borrow checker was actually encountering.
- corrode2711 9mo agoI'm the author of this repo. I see some really angry comments, some of them even personal. Obviously I didn't think that just by tinkering with a compiler, I'd get personally attacked, but anyway, fair enough. For those of you confused: yes, this started as a satirical project with the corroded lib. Then I thought "why not just remove the borrow checker?" without any real motivation. Then I just went ahead and did it. To my surprise, it was really simple and easy. I thought it would be heavily tangled into the rustc compiler, but once I figured out where the error emitter is, it was pretty straightforward. I'm not sure about my long-term goals, but besides the joke, I genuinely think for debugging and prototyping purposes, I'd like the borrow checker to shut up. I'm the kind of guy that prints everything while debugging and prototyping. Maybe you're using a debugger, okay, but I don't. I don't like debuggers. It's just more convenient for me. So what constantly happens is I run into issues like: does this implement Debug? Can I print this after it moved? The borrow checker won't let me access this because of some other borrow. Stuff like that. Another point is, as you guys are well aware, the borrow checker will reject some valid programs in order to never pass any invalid program. What if I'm sure about what I'm doing and I don't want that check to run? In the repo there's a doubly linked list example. Without the borrow checker it's fairly simple and easy to implement. With it, you know how complicated and ugly it gets. Anyway, have a good new year, and don't get angry over compilers, you know.
- whatshisface 9mo agoI think there is probably a way to do what you're doing with unsafe. You could write a library that copies handles and can dump potentially freed memory afterwards.
- g-mork 9mo agoSome kind of cargo plugin that transforms all references in the project into pointers and casts prior to feeding to rustc would probably be the best practice and highly maintainable route I'd go. like "cargo expand" but with a fancy catchier name that encourages new users to rely on it. "cargo autofix" might work
- jvanderbot 9mo ago
- indigoabstract 9mo agoMy controversial opinion: If Rust were to "borrow" something from the C/C++ spirit, then disabling the borrow checker should be available as a compiler option. As in, you're an adult: if you want it, you can have it, instead of "we know better".
- whatshisface 9mo agoIf you could disable the borrow checker globally, projects would do it, and it would become impossible to compile anything with it enabled. You can already disable it locally: the unsafe keyword is for that.
- gpm 9mo agoThe unsafe keyword doesn't disable the borrow checker... it lets you interact with different pointer types that aren't borrow checked, but if you're using the normal reference types in rust the same guardrails are still in place.
- klysm 9mo agoDoesn’t work - you need the borrow checker guarantees to implement downstream compilation steps. You can just turn off assumptions
- gpm 9mo ago> you need the borrow checker guarantees to implement downstream compilation steps. You don't technically. The borrow checker doesn't effect the semantics of the program (like, for example, type inference does) and the rest of the compiler doesn't need to (and in fact, doesn't) use its analysis to figure out how to compile the code. The downstream compiler does assume that the code followed the rules for accessing references - i.e. didn't violating aliasing rules. The borrow checker guarantees this, but it's fundamentally a conservative check. It rejects programs it can't guarantee are correct, and rice's theorem proves that there are always correct programs that it can't guarantee are correct. That said if you just treat rust-references like C-pointers you will run into issues. The aliasing rules for rust references are stricter. Also not fully agreed upon yet - the currently closest to accepted definition is in the "tree borrows" paper but it has yet to be adopted as the official one by the rust team.
- shmerl 9mo agoIsn't unsafe just for that? Why does it need a separate compiler?
- idontsee 9mo agoThe borrow checker still applies in unsafe { } blocks. What it means (iirc) is that you can do pointer/memory stuff that would otherwise not be allowed. But you still fully adhere to Rust semantics
- andrewaylett 9mo agoUnsafe isn't so unsafe that it disables the borrow checker! The two main things the compiler allows in an unsafe block but not elsewhere are calling other code marked "unsafe" and dereferencing raw pointers. The net result is that safe code running in a system that's not exhibiting undefined behaviour is defined to continue to not exhibit undefined behaviour, but the compiler is unable in general to prove that an unsafe block won't trigger undefined behaviour. You can side-step the borrow checker by using pointers instead of references, but using that power to construct an invalid reference is undefined behaviour.
- JoelJacobson 9mo agoRust without async maybe?
- juped 9mo agoThis would actually be good though!
- accelbred 9mo agoI've been thinking of writing a language with Rust's ergonomics but less of the memory safety stuff. I prefer using no dynamic allocations, in which case the only memory safety feature I need is leaking references to locals into outer scopes. As for the thread safety stuff, most of my stuff is single-threaded.
- giancarlostoro 9mo agoI've been wishing for Rust to become more ergonomic, what ergonomics does Rust currently have that other languages lack?
- Null-Set 9mo agoI love how everything is an expression with a value. And match expressions are quite nice, especially with the option type. I really miss those when working in javascript.
- zeroxfe 9mo agoIf Go had rust-style ADTs and pattern matching, and some parallel of "?" to short-circuit error handling, I'd be thrilled.
- accelbred 9mo agoFor me its everything being an expression, macro_rules, dyn, automatic conversions (the few that it does have), traits, and the ? operator.
- masklinn 9mo agoAffine types / destructive moves, type-level safety signal (sync/send), container-type locks. I really miss these when doing concurrent stuff in other languages.
- maxbond 9mo agoTo add to the sibling comments, a world-class LSP enabling you to get a great experience in any editor/IDE out of the box. This is not at all exclusive to Rust of course, most strongly typed languages have one at this point, but I've been working in Python lately and this is what I miss the most. (I'm using an LSP in Python, but it isn't as good at the best of times, and it seems like no matter how many times I fix it's configuration it's broken again the next day.)
- QuaternionsBhop 9mo agoFighting the borrow checker is something you do when you're learning Rust. After you learn how to design things that way in the first place, it's just there to keep you honest.
- tinco 9mo agoTo be fair, working on the Rust compiler is also something to do when you're learning Rust. I guess this person is killing two birds with one stone.
- sakisv 9mo agoAs someone who's only did a couple of small toy-projects in rust I was never annoyed by the borrow checker. I find it nothing but a small mental shift and I kinda like it. What I _do_ find annoying though and I cannot wrap my head around are lifetimes. Every time I think I understand it, I end up getting it wrong.
- Maxatar 9mo agoLifetimes are the input to the borrow checker, so it doesn't make much sense to say you have never been bothered by the borrow checker but you are bothered by lifetimes.
- ViewTrick1002 9mo agoDue to lifetime elision you can mostly skip lifetimes if you leave a bit of performance on the table.
- bluehex 9mo agoHow does lifetime elision affect performance? I thought the compiler just inferred lifetimes that you would have had to manually annotate. Naively, it seems to me that the performance should be identical.
- steveklabnik 9mo agoStrictly speaking, elision just adds lifetimes based on common patterns, so yes, it wouldn't directly affect performance. I believe your parent is implying that if you skip using a lifetime and do something else instead to make it easier, that may be less performant.
- adastra22 9mo agoI think his point is the lifetime you’d put there is identical to the lifetime that is inferred/elided. So there is literally no difference.
- seivan 9mo ago[dead]
- zemo 9mo agoway too many people in this thread are taking this project seriously
- deleted 9mo ago[deleted]
- lamontcg 9mo agoThe more I write code in other languages where I think hard about ownership ("does this method ultimately grab the object and throw a ref onto some long-lived data structure somewhere? Then it owns it, so I better clone it") the more robust my code in other languages generally gets. Same with mutation. Generally better to make a copy of something and then mess with it and throw it away than to try to mutate-then-unmutate or something like that, even though it might in principle be nanoseconds faster. Eliminate loads of spooky-action-a-distance bugs where things are getting mutated in one spot and used in another spot, when there should have been a copy in there somewhere.
- dmitrygr 9mo ago> Generally better to make a copy of something > Eliminate loads of spooky-action-a-distance bugs This line of thinking so sickens me. Many things are not easy when done right. That is no excuse to avoid understanding how to do them right. Sure, making endless copies is easier. But this is why machines now need 16GB of ram and four cores to run the calculator.
- LexiMax 9mo ago> But this is why machines now need 16GB of ram and four cores to run the calculator. This has more to do with the fact that the web stack has become the de-facto app development platform, and thus we inherit the bloat and optimization oversights of that platform. You're not going to make a 16GB calculator just because you personally prefer copies over shared ownership in a language that gives you the tools to avoid bloat in a myriad of ways.
- mistivia 9mo agoI don't want a Rust language without a borrow checker. I want a C language with a Borrow Checker. Rust's complexity is already approaching C++, and removing the Borrow Checker would turn it into a similar disaster. Austral looks like a good option to me, but it's not mature enough yet, and the Pascal-like syntax is also difficult to get used to.