4 ms·

> I'm implementing a language that's basically F#/OCaml. So it makes sense that it's easier to implement in F#/OCaml. This is the key point. When your target a

by mamcx 6y ago

> I'm implementing a language that's basically F#/OCaml. So it makes sense that it's easier to implement in F#/OCaml. This is the key point. When your target and host language match in semantics is easier to be done in the host. You se how much gymnastics is necessary to implement near all langs on C. --- I done a lot of F# before move to Rust, and frankly, F# is great and Rust take a time to "click". I'm doing a lang on it (https://tablam.org https://tablam.org) and the truth is that Rust make things harder. Some of the points of the author are not that "bad" and with some time it will see that are non the real issues, but the fact is that anyone, specially (IMHO) if have done a lot of other langs (not named C or pascal) will have a miserable time the first try. Eventually, you Jump the wall of complexity and a lot of stuff click.. but then hit the REAL showstoppers (that are different depending according to what you do), and lets by real: Are truly hard. (maybe: But doing a lang, you hit this stuff more easily than "regular" coding. Doing a erp backend Rust is super productive to me) --- 2 things that make harder this stuff: Rc/Arc make complicated how mutate things. You need to wrap again with RefCell. I wish exist a super-charged RcRefCell that is "blessed" by the rust team as is with Rc, so the correct idioms to deal with this become widespread. Also, the trait system and the restrictions of object safety somehow make harder to mimic a OO system, that in part could make a lot easier to deal with lang implementation. Plus, I wish I can take alias everywhere, so i can cut the noise in syntax...

zozbot234 6y ago
> I wish exist a super-charged RcRefCell that is "blessed" by the rust team as is with Rc The syntax for that is Rc<RefCell<…>> and yes, this is clearly intended. The idea is that Rc is limited to managing multiple owners, while the RefCell part deals with shared mutability.
- steveklabnik 6y ago
  Long ago, we did have those as one type: https://doc.rust-lang.org/0.5/std/arc.html#struct-mutexarc https://doc.rust-lang.org/0.5/std/arc.html#struct-mutexarc But yes, as you say, we decided to split them up, because it is easy to combine them, and you may want to combine other pieces in different ways. Rc<T> on its own is good in many cases, you may want Arc<RwLock<T>> instead of Arc<Mutex<T>>, etc.

by mamcx 6y ago

zozbot234 6y ago

> I wish exist a super-charged RcRefCell that is "blessed" by the rust team as is with Rc The syntax for that is Rc<RefCell<…>> and yes, this is clearly intended. The idea is that Rc is limited to managing multiple owners, while the RefCell part deals with shared mutability.

steveklabnik 6y ago
Long ago, we did have those as one type: https://doc.rust-lang.org/0.5/std/arc.html#struct-mutexarc https://doc.rust-lang.org/0.5/std/arc.html#struct-mutexarc But yes, as you say, we decided to split them up, because it is easy to combine them, and you may want to combine other pieces in different ways. Rc<T> on its own is good in many cases, you may want Arc<RwLock<T>> instead of Arc<Mutex<T>>, etc.