Remix.run Logo
▲ faresahmed a day ago

I beg to differ. It's not that Rust is completely different from Lisp. PL writers get so caught up with their 'killer feature' which in the case of Rust is the borrow checker, that they completely abandon the other 50% which is the environment.

If we stopped treating the compiler as a one-shot program, we could theoretically shorten this edit-build-test loop by 99%.

▲shikck200 a day ago | parent | next [-]

Rust's killer features is not "the borrow checker". That idea was just stolen from Cyclone. Rust is basically a semi ml kind of language in the c++ space. I dont see many "killer features" in rust outside the saner type system.

Its basically a better language for software you write in C at the cost of horrible compile times.

▲brabel 16 hours ago | parent [-]

The killer feature is definitely memory safety in a systems programming language. That was pretty much thought impossible before Rust came along, and even today there is essentially no competition offering both memory safety and C performance, which requires no GC really.

▲LoganDark a day ago | parent | prev | next [-]

The borrow checker is an example of a certain kind of reasoning that Rust benefits from. There's a reason a Lisp can be inspected and rewritten as the process runs, and it's the same thing that makes Rust difficult to rewrite in the same way. Not sure the exact term for it, but it's very easy to have profound nonlocal effects, for example with TAIT (type alias impl trait).

▲wahern a day ago | parent | next [-]

The borrow checker doesn't rely on interprocedural analysis. The function prototype provides all the information needed to maintain lifetime invariants across functions, so given static typing already then interprocedural borrow checking is effectively zero cost at compile time. (Cf. Intraprocedural, non-lexical borrow checking.) So borrow checking is no impediment to dynamically replacing function definitions. And it would be less of a headache for intraprocedural REPL but-for non-lexical semantics. But in a REPL you could always use an interpreter for running a function currently being edited, then compile it down once complete. REPLs are a headache for languages like Rust because of static typing generally, generics, trait semantics, etc.

▲pjmlp 21 hours ago | parent | prev [-]

The reason is tooling matters, you can also do the same in C++, tools do exist.

▲Ar-Curunir a day ago | parent | prev [-]

rustc is not really a one-shot program! Incremental computation is a big part of rustc !