The other end of the spectrum is something like gamedev: you write code that pretty explicitly has an end-date, and the actual shape of the program can change drastically during development (because it's a creative thing) so you very much don't want to slowly build up rigidity over time.
The borrowchecker is what I like the least about Rust
41–50 of 459 posts
Re: The borrowchecker is what I like the least about Rust
#42Earlier quoted context omitted.
This is also somewhat backed up by the fact that OCaml (to my understanding) is basically GC Rust without a borrow checker, and yet it’s basically a hobby language.
Hobby language? Plenty of commercial and important software has been written in OCaml. Hell, the early versions of the Rust compiler were written in OCaml...
Also I would argue the rust compiler started as a hobby project
Re: The borrowchecker is what I like the least about Rust
#43I don't use Rust much, but I agree with the thrust of the article. However, I do think that the borrowchecker is the only reason Rust actually caught on. In my opinion, it's really hard for a new language to succeed unless you can point to something and say "You literally can't do this in your language" Without something like that, I think it just would have been impossible for Rust to gain enough momentum, and also…
This is also somewhat backed up by the fact that OCaml (to my understanding) is basically GC Rust without a borrow checker, and yet it’s basically a hobby language.
Also, OCaml had trouble with multithreading for quite some time, which was a limiting factor for many applications.
Facebook made a large effort to thrust OCaml into the limelight, and even wrote a nice alternative frontend (Reason). Sadly, it did not stick.
Re: The borrowchecker is what I like the least about Rust
#44I've recently wondered if it's possible to extract a subset of Rust without references and borrow checking by using macros (and a custom stdlib). In principle, the language already has raw pointers with the same expressive power as in C, and unlike references they don't have aliasing restrictions. That is, so long as you only use pointers to access data, this should be fine (in the sense of, it's as safe as doing the…
I've similarly thought about building a language that compiles to Rust, but handles everything around references and borrowing and abstracts that away from the user. Then you get a language where you don't have to think about memory at all, but the resulting code "should" still be fairly fast because Rust is fast (kind of ending up in the same place as Go). I haven't written a ton of Rust so maybe my assumptions of w…
Re: The borrowchecker is what I like the least about Rust
#45Earlier quoted context omitted.
The whole point is that `Id` doesn't have a destructor (it's purely stack-allocated); that is, conceptually it _could_ be `Copy`. A more precise way to phrase what he's getting at would be something like "all types that _can_ implement `Copy` should do so automatically unless you opt out", which is not a crazy thing to want, but also not very important (the ergonomic effect of this papercut is pretty close to zero).
Auto-deriving Copy would also mean that there needs to be an escape-hatch: eg. Vec would auto-derive Copy.
This program fails to compile:
#[derive(Clone, Copy)]
struct S;
impl Drop for S {
fn drop(&mut self) {}
}
fn main() {}Re: The borrowchecker is what I like the least about Rust
#46> In that sense, Rust enables escapism: When writing Rust, you get to solve lots of 'problems' - not real problems, mind you, but fun problems. This is a real problem across the entire industry, and Rust is a particularly egregious example because you get to justify playing with the fun stimulating puzzle machine because safety —you don't want unsafe code, do you? Meanwhile there's very little consideration to whethe…
Typescript has escape hatches so you can just say "I don't care, or don't know." With Rust, you're battling a compiler that has a very restrictive model, that you can't shut up. You will end up performing major refactors to implement what seem like trivial additions.
Re: The borrowchecker is what I like the least about Rust
#47Earlier quoted context omitted.
Have you tried to assure yourself that this or that piece of software (your primary text editor for example) doesn't need to be memory safe because it won't ever receive as input any data that might have been crafted by an attacker? In my experience, doing that is harder than satisfying the borrow checker.
Yes, and you can choose to use any language with a garbage collector and get the same benefit. The list of memory safe languages at your disposal is endless and they come in every flavor you can imagine.
Uh, no thanks.
> and get the same benefit.
Not quite.
Re: The borrowchecker is what I like the least about Rust
#48Earlier quoted context omitted.
This is also somewhat backed up by the fact that OCaml (to my understanding) is basically GC Rust without a borrow checker, and yet it’s basically a hobby language.
Rather, an academia language. Also, OCaml had trouble with multithreading for quite some time, which was a limiting factor for many applications. Facebook made a large effort to thrust OCaml into the limelight, and even wrote a nice alternative frontend (Reason). Sadly, it did not stick.
Old but funny comparison: http://adam.chlipala.net/mlcomp/
Re: The borrowchecker is what I like the least about Rust
#49I've recently wondered if it's possible to extract a subset of Rust without references and borrow checking by using macros (and a custom stdlib). In principle, the language already has raw pointers with the same expressive power as in C, and unlike references they don't have aliasing restrictions. That is, so long as you only use pointers to access data, this should be fine (in the sense of, it's as safe as doing the…
I've similarly thought about building a language that compiles to Rust, but handles everything around references and borrowing and abstracts that away from the user. Then you get a language where you don't have to think about memory at all, but the resulting code "should" still be fairly fast because Rust is fast (kind of ending up in the same place as Go). I haven't written a ton of Rust so maybe my assumptions of w…
Re: The borrowchecker is what I like the least about Rust
#50Both have rust-like flavor and neither has a borrow checker.