Live data from Hacker News

Rust--: Rust without the borrow checker

github.com

51–60 of 269 posts

Re: Rust--: Rust without the borrow checker

#51
post #29

To 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.

> At least C and C++ have a low barrier of entry and any beginner can write code.

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.

Re: Rust--: Rust without the borrow checker

#52
post #3

Are the compile times noticeably faster?

Probably not, because it seems like it still checks for errors but just suppresses them.

Even so, the borrow checker repeatedly profiles as an insignificant part of compile times, so wouldn’t make a difference.

Re: Rust--: Rust without the borrow checker

#53

I’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?

I don't think so, I don't think Rust's borrow checker is free of false negatives.

Re: Rust--: Rust without the borrow checker

#54
post #49

Earlier quoted context omitted.

If 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 mil…

People don't want garbage. But in any case, they don't want straightjackets like the borrow checker. Hence, they use GC'd languages like Go whenever they can.

Straightjackets can be very useful.

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).

Re: Rust--: Rust without the borrow checker

#55
post #11

Tangentially 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…

Why 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.

Yeah, you're right, I'm misremembering something here. Thanks for the correction.

Re: Rust--: Rust without the borrow checker

#56
post #41
post #6

[flagged]

Honestly, 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.”

There 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.

Re: Rust--: Rust without the borrow checker

#57

Earlier quoted context omitted.

What the point, though? You will get compiling code, but later you would need to reachitecture code to avoid violating rust rules.

Sometimes, 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.

Can'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?

Re: Rust--: Rust without the borrow checker

#59

I’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?

The 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.

Re: Rust--: Rust without the borrow checker

#60

Earlier quoted context omitted.

How does "zero dynamic allocation" work in practice for something like a text editor IE. vscode or other apps that let users open arbitrary files?

It’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 th…

What 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?

Post reply on HN